쿠버네티스의 앤드포인트
쿠버네티스(Kubernetes)에서 “엔드포인트(Endpoint)”는 크게 두 가지 관점에서 이해할 수 있음.
1. Kubernetes 리소스로서의 Endpoints(오브젝트)
2. Service가 내부적으로 관리하는 Endpoints(서비스와 파드(Pod) 간 연결 정보)
둘 다 공통적으로 “Service가 라우팅해야 하는 실제 대상(주로 파드)의 IP 및 포트 정보”를 담고 있다는 점에서는 유사하지만, 쿠버네티스 API 상에서 관리되는 방법이나 동작 방식에 차이가 있음.
Endpoints 오브젝트 - 정의
Endpoints는 Kubernetes가 각 Service에 연결된 파드들의 네트워크 위치(주로 IP와 Port)를 추적하기 위해 생성하는 리소스임.
쿠버네티스에서 Service 오브젝트를 생성하면, 해당 서비스가 매칭하는 “파드” 정보를 기반으로 자동으로 “Endpoints” 오브젝트를 생성.
예를 들어, my-service 라는 서비스를 생성하면, API 서버에는 Endpoints 리소스 중에서도 my-service라는 이름을 가진 오브젝트가 자동으로 생성됨.
Endpoints 오브젝트 - 생성 및 동작 방식
1. Service 오브젝트 생성
사용자가 Service를 정의해서 kubectl apply 등으로 쿠버네티스 클러스터에 배포함.
2. Selector로 파드 검색
Service 오브젝트가 갖고 있는 selector 라벨(예: app: my-app)에 부합하는 파드를 쿠버네티스가 검색함.
3. Endpoints 오브젝트 자동 생성
쿠버네티스 컨트롤 플레인(특히 Endpoints Controller)에서 위에서 검색된 파드들의 IP, 포트를 모아 Endpoints 리소스를 생성(또는 업데이트)함.
Endpoints 오브젝트의 subsets 필드 내에 실제 파드의 IP 주소, 포트 목록이 담김.
4. Endpoints 리소스 조회
사용자는 kubectl get endpoints my-service -o yaml 등의 명령어로 엔드포인트 정보를 확인할 수 있음.
이 정보가 실제로 Service를 통해 트래픽이 전달될 대상이 됨.
Endpoints 오브젝트 - 구성 요소 및 예시
다음 예시 YAML은 my-service라는 이름을 가진 Endpoints 리소스를 간략히 나타낸 것임.
실제로는 쿠버네티스가 자동으로 작성하고 갱신함.
apiVersion: v1
kind: Endpoints
metadata:
name: my-service
subsets:
- addresses:
- ip: 10.244.0.12
- ip: 10.244.0.15
ports:
- name: http
port: 80
protocol: TCP
addresses: 실제 파드들의 IP가 나열됨.
ports: 해당 파드가 노출하는 컨테이너 포트를 기술 (여기서는 80/TCP)
Endpoints 오브젝트 - 리소스의 활용
보통 사용자가 직접 수정하는 경우는 드물며, Kubernetes Service Controller가 자동으로 관리함.
다만, 선택적으로 Headless Service(ClusterIP가 없는 서비스)처럼 IP 클러스터 내부 DNS를 통해 파드 IP를 직접 노출해야 하는 경우, Endpoints를 직접 관리하거나, 별도의 라이프사이클 훅 등을 통해 동적으로 조정하기도 함.
Service 동작 메커니즘에서의 엔드포인트 - 서비스와 엔드포인트
서비스(Service)는 쿠버네티스 내에서 “파드에 대한 접근을 일관되게 제공하기 위한 추상화”임.
“엔드포인트”는 서비스가 실제 파드로 트래픽을 라우팅하기 위해 내부적으로 관리하는 아이템임.
쿠버네티스 네트워크 프록시(kube-proxy)나 DNS 구성 등이 이를 참조하여 최종 파드 주소로 연결해 줌.
이때 Service의 Endpoints 리소스가 바로 연결 대상 파드의 IP와 포트를 담고 있음.
kube-proxy가 Endpoints 정보를 기반으로 iptables, IPVS, eBPF 등을 사용해 트래픽 라우팅 규칙을 설정함.
Service 동작 메커니즘에서의 엔드포인트 - 관리 방식
1. kube-proxy
노드별로 실행되며, API 서버로부터 Service와 Endpoints 정보를 워치(watch)하여 iptables(혹은 IPVS) 규칙을 업데이트함.
2. DNS
쿠버네티스 클러스터 내부 DNS(예: CoreDNS)가 Service의 클러스터IP, 혹은 Headless Service의 엔드포인트 정보를 기반으로 클라이언트에게 DNS 레코드를 응답함.
Service 동작 메커니즘에서의 엔드포인트 - Headless Service와 엔드포인트
Headless Service는 ClusterIP를 할당받지 않고, DNS가 파드들의 IP 목록을 직접 응답하게 하는 특별한 유형의 서비스임.
예를 들면, spec.clusterIP: None.
이 경우 Service는 LoadBalancer 기능 없이 파드들의 IP를 그대로 노출하며, 이 또한 Endpoints 오브젝트로 관리됨.
StatefulSet 등과 함께 사용할 때, 각 파드별 고유 DNS를 매핑하여 서비스 디스커버리(서비스 발견)를 유연하게 할 수 있음.
전문가 수준에서 고려해야 할 요소 - 성능 및 확장성
1. 엔드포인트 개수 증가
쿠버네티스의 엔드포인트 오브젝트는 파드가 많아질수록 한 Service에 연결된 엔드포인트 수도 많아짐.
이때 kube-proxy(특히 iptables 모드) 규칙이 매우 많아지면 성능에 영향을 줌.
API 서버와의 통신 지연이 늘어날 수 있음.
IPVS 혹은 eBPF 기반 모드를 사용하면 iptables 기반 보다 더 나은 성능과 확장성을 얻을 수 있음.
2. Endpointslice
쿠버네티스 1.17+부터는 Endpointslice라는 리소스를 통해 Endpoints 정보를 “샤딩(Sharding)” 형태로 관리할 수 있음.
파드가 매우 많은 대규모 환경에서 Endpoints 오브젝트 하나가 너무 커지는 것을 방지해 네트워크 성능과 API 서버 부하를 줄일 수 있음.
kube-proxy도 EndpointSlice를 지원하여, 확장성에 유리하게 동작할 수 있음.
전문가 수준에서 고려해야 할 요소 - 보안 및 트래픽 제어
1. NetworkPolicy
파드 레벨에서 네트워크 트래픽을 제어하기 위해서는 NetworkPolicy를 설정함.
엔드포인트 자체에 대한 접근을 막거나 허용하는 것이 아니라, 파드나 네임스페이스 레벨에서 인그레스·이그레스 정책을 구성해 접근을 제한함.
2. TLS/SSL 및 mTLS
애플리케이션 레벨에서 TLS 종단(termination) 혹은 mTLS를 적용하려면, 결국 파드/컨테이너가 통신하는 실제 엔드포인트에 인증서를 설치해야 함.
쿠버네티스 서비스(엔드포인트)와 직접적으로 TLS를 구성하기보다는, Ingress Controller, 서비스 메시(Service Mesh) 등 상위 레벨에서 엔드포인트의 트래픽을 처리하며 TLS를 종단하거나 중계하는 방식을 고려해야 함.
전문가 수준에서 고려해야 할 요소 - DevOps 및 운영 관점
1. 고가용성(HA)와 롤링 업데이트
엔드포인트가 연결하는 파드가 롤링 업데이트되거나, PodDisruptionBudget 등을 통해 재배치(re-scheduling)될 때 엔드포인트가 동적으로 갱신됨.
Service는 자동으로 새 파드 주소를 Endpoints에 등록하고, 기존 파드를 제거하여 무중단 배포(또는 최소 다운타임)를 실현.
2. 디버깅
“서비스에는 파드가 잘 연결되어 있는데 실제로 트래픽이 오가지 않는다”와 같은 문제가 발생할 수 있음.
이 경우 Endpoints 리소스를 확인하여 올바른 IP, 포트를 갖는지 확인해야 함.
또한 kube-proxy(iptables/ipvs) 설정을 점검하거나, CNI 플러그인(예: Caico, Weave Net)의 라우팅 설정이 올바른지 확인해야 함.
정리
쿠버네티스에서 “엔드포인트”는 Service와 실제 파드(컨테이너) 간의 연결 정보를 나타내는 핵심 요소임.
Endpoints 오브젝트는 자동으로 생성 및 갱신됨.
이를 기반으로 kube-proxy나 DNS가 트래픽 라우팅을 수행함.
대규모 환경에서 확장성 및 성능을 위해 EndpointSlice로 분산관리하며, IPVS나 eBPF 기반 kube-proxy 모드로 전환해 더 나은 성능을 구현할 수 있음.
운영 환경에서는 엔드포인트와 관련된 보안, 트래픽 제어(네트워크 정책, TLS/SSL), 롤링 업데이트 시 엔드포인트 갱신 전략 등을 고려해야 안정적인 서비스를 제공할 수 있음.
쿠버네티스에서 엔드포인트를 제대로 이해하면, Service가 제공하는 추상화 뒤에서 실제로 어떤 IP/포트로 트래픽이 전달되는지 파악할 수 있고, 장애나 설정 오류 발생 시 어디서부터 문제를 추적해야 할지 명확해짐.
이를 기반으로 서비스 디스커버리, 스케일링, 고가용성 등의 기능을 더욱 안정적이고 효율적으로 운영할 수 있음.
'Operating System > Kubernetes' 카테고리의 다른 글
[Kubernetes] OAuth 개념 (0) | 2025.01.02 |
---|---|
[Kubernetes] 롤링 업데이트 개념 (0) | 2025.01.01 |
[Kubernetes] 리소스 종류 (0) | 2024.12.29 |
[Kubernetes] 쿠버네티스의 Secret 및 ConfigMap (0) | 2024.12.29 |
[Kubernetes] EKS 생성시 자동으로 생성되는 노드의 라벨 (0) | 2024.12.29 |