Kubernetes 기초 - Service(3)

1. 서비스 개념
2. 서비스 타입
3. 서비스 사용하기
4. 헤드리스 서비스             ←  오늘 볼 내용
5. kube-proxy             ←  오늘 볼 내용

---

4. 헤드리스(Headless) 서비스

헤드리스 서비스(Headless Service)는 쿠버네티스에서 제공하는 서비스 유형 중 하나로, 일반적인 클러스터IP 서비스와는 달리 Cluster IP를 부여하지 않는다.

헤드리스 서비스는 주로 파드의 이름이 보존되는 StatefulSet과 함께 사용되며, 각각의 Pod에 고유한 DNS 이름을 부여하여 서비스를 구성한다.

• ClusterIP가 없는 서비스로 단일 진입점이 필요 없을 때 사용
• Service와 연결된 Pod의 Endpoint로 DNS 레코드가 생성됨(coreDNS에서 확인 가능)
• Pod들의 Endpoint에 DNS resolving Service 지원

각 파드의 도메인 레코드 예시

[파드의 IP(구분자 -)].[Namespace].pod.cluster.local

ex)
10-11-123-222.default.pod.cluster.local

 

 

 

무슨 소리인지 잘 모르겠지만 실습해보면 쉽게 이해할 수 있다.

헤드리스 서비스는 clusterIP가 None으로 지정되어 있다.

헤드리스라고 해서 kind를 따로 적는 것이 아니라 clusterIP가 None이면 그게 헤드리스 서비스다.

 

 

실습

 

headless-nginx.yaml

# headless-nginx.yaml
apiVersion: v1
kind: Service
metadata:
  name: headless-service
spec:
  type: ClusterIP
  clusterIP: None
  selector:
    app: webui
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

 

 

지난 포스터와 동일하게 deploy-nginx.yaml 파일로 실습할 것이다.

deploy-nginx.yaml 실행

 

 

위 yaml파일을 실행하면 다음과 같이 표시된다.

ClusterIP가 None이다.

describe 명령

 

실제로 IP는 존재하지 않지만 Endpoint로 세 개의 파드가 묶여있는 것을 확인할 수 있다.

 

 

각각의 파드들이 고유의 DNS 레코드 정보가 coreDNS에 등록되어 DNS resolving 서비스가 가능한 것을 직접 확인해보자.

먼저 curl 명령을 쓸 수 있는 파드를 하나 생성해서 확인해보자.

# testpod라는 이름의 centos파드 생성과 동시에 접속
kubectl run testpod -it --image=centos:7 /bin/bash

# 나의 DNS서버(coreDNS) IP 확인
cat /etc/resolv.conf

# 파드의 DNS 레코드로 접근 시도
curl 10-11-166-159.default.pod.cluster.local

coreDNS의 IP

도메인 레코드로 접근

 

도메인 이름으로 접근을 시도하면 IP로 접근했을 때와 동일하게 nginx의 HTML코드가 출력된다.

이와 같이 파드들은 각각의 고유의 DNS 레코드를 갖게 되었고 이는 coreDNS가 관리하며 resolving 서비스를 제공한다.

 

왜 굳이 불편하게 이렇게 쓰는가 싶겠지만 다 이유가 있는 법이다.

실제로 헤드리스 서비스는 데이터베이스나 메시징 시스템과 같이 각 Pod에 고유한 식별자가 필요한 경우에 유용하게 사용된다.

 

 

 

 

---

5. kube-proxy

iptables 프록시에 대한 서비스 개요 다이어그램 https://kubernetes.io/ko/docs/reference/networking/virtual-ips/

 

kube-proxy는 Kubernetes 클러스터에서 네트워크 프록시 및 로드 밸런싱을 담당하는 구성 요소 중 하나다.

kube-proxy는 여러 가지 역할을 수행하여 클러스터 내부에서 서비스 디스커버리 및 로드 밸런싱을 지원한다.

• Kubernetes Service의 backend 구현
  • 클러스터 내부에서 서비스에 대한 가상 IP(Cluster IP)를 생성하고 유지한다.
  • 서비스가 관리하는 파드의 엔드포인트(IP 주소 및 포트) 목록을 추적하고 유지한다.
• Endpoint 연결을 위한 iptables 구성
  • kube-proxy는 iptables 규칙을 사용하여 각 서비스의 가상 IP를 해당 서비스에 속한 파드의 실제 IP로 매핑한다.
  • 이를 통해 클러스터 내부에서 서비스에 접근할 때 kube-proxy가 실제 파드로 트래픽을 전달한다.
• NodePort로의 접근과 Pod 연결을 구현(iptables 구성)
  • kube-proxy는 NodePort 서비스에 대해 Node의 특정 포트를 할당하고, 해당 포트로 들어오는 트래픽을 서비스의 Cluster IP로 전달한다.
  • iptables 규칙을 통해 NodePort로 들어오는 트래픽이 각 서비스의 Endpoint로 전달된다.
  • 로드 밸런싱이 필요한 경우, kube-proxy가 적절한 로드 밸런싱을 수행하여 여러 파드로 트래픽을 분산다.

 

확인

 

실제 kube-proxy가 무슨 일을 하는지 보자.

그 전에 clusterip-nginx.yaml 파일을 실행 후 확인해야 결과가 나온다.

# kube-proxy가 하는 일
# Node1에서 실행
iptables -t nat -S | grep 80

iptables rule

 

 

요약하면 iptables를 만들고, 관리하고, 포트에서 listen하여 클라이언트의 접속을 잡아주는 것이 kube-proxy가 하는 일이다.

 

 

 

kube-proxy mode

• userspace
  • 클라이언트의 서비스 요청을 iptables를 거쳐 kube-proxy가 받아서 연결
  • kubernetes 초기 버전에 잠깐 사용
• iptables
  • default kubenetes network mode
  • kube-proxy는 service API 요청 시 iptables rule이 생성
  • 클라이언트 연결은 kube-proxy가 받아서 iptables 룰을 통해 연결
• IPVS
  • 리눅스 커널이 지원하는 L4 로드밸런싱 기술을 이용
  • 별도의 ipvs 지원 모듈을 설정한 후 적용가능
  • 지원 알고리즘
    • rr(round-robin)
    • lc(least connection)
    • dh(destination hashing)
    • sh(source hashing)
    • sed(shortest expected delay)
    • nq(never queue)

 

 

자세한 내용은 아래 공식 문서를 참조

https://kubernetes.io/ko/docs/reference/networking/virtual-ips/

가상 IP 및 서비스 프록시

 

 

 

---

 

 

아래 영상을 참고했습니다.

https://youtube.com/playlist?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&si=hbPclcPuc-6lTNdE

[따배쿠] 쿠버네티스 시리즈