[Kubernetes/Networking] 트래픽이 Pod까지 도달하는 여정 : ClusterIP, NodePort, LoadBalancer, Ingress

About this offer

쿠버네티스(Kubernetes)를 처음 배울 때 가장 혼란스러운 영역 중 하나가 바로 네트워크 아키텍처 입니다. 클러스터 내부에서 Pod는 계속 생겼다 사라지며 IP가 매번 바뀌는데, 외부 사용자는 도대체 어떤 경로를 거쳐 내 애플리케이션에 접속하게 되는 걸까요? 이번 글에서는 쿠버네티스 네트워크의 기본 단위인 Service(ClusterIP, NodePort, LoadBalancer)의 차이점부터 L7 트래픽 라우팅을 담당하는 Ingress , 그리고 커널 라벨에서 패킷을 라우팅하는 kube-proxy 의 동작 원리까지 단계별로 완벽하게 파헤쳐 봅니다. 1. Pod IP의 한계와 Service 리소스의 필요성 쿠버네티스에서 Pod는 생성되고 소멸될 때마다 새로운 IP 주소를 부여받는 휘발성(Ephemeral) 자원 입니다. 만약 프론트엔드 Pod가 백엔드 Pod의 IP를 직접 참조하여 통신한다면, 백엔드 Pod가 재시작될 때마다 프론트엔드 설정도 매번 수정해야 하는 대참사가 일어납니다. [Problem] Pod A (10.244.1.5) ─── Direct Call ───> Pod B (10.244.2.10) [Crash & Restart!] Pod B (10.244.2.11) ➔ Connection Failure! 이 문제를 해결하기 위해 쿠버네티스는 Service 라는 추상화 레이어를 제공합니다. Service는 Pod 집합 앞에 고정된 가상 IP(Virtual IP, VIP)를 두고, 자신에게 들어오는 요청을 뒤에 있는 Pod(Endpoints)들에게 균등하게 로드밸런싱 해 줍니다. 2. 쿠버네티스 서비스(Service)의 3가지 핵심 타입 트래픽을 어느 범위까지 노출할 것인가에 따라 Service 타입은 크게 3가지로 나뉩니다. [ LoadBalancer ] │ (External Cloud IP) ▼ [ NodePort ] │ (NodeIP:30000~32767) ▼ [ ClusterIP ] │ (Internal Virtual IP) ▼ [ Pods ] 1 ClusterIP (기본값 - 클러스터 내부 전용) 동작 : 클러스터 내부에서만 접근 가능한 가상 IP(VIP)를 할당받습니다. 특징 : 외부 인터넷에서는 이 IP로 직접 접근할 수 없습니다. 유스케이스 : 외부 노출이 필요 없는 데이터베이스(DB), 내부 백엔드 마이크로서비스 간 통신에 사용됩니다. 2 NodePort (노드 포트 오픈) 동작 : ClusterIP를 기본적으로 포함하면서, 모든 워커 노드의 물리적 포트(기본 범위 : 30000~32767)를 엽니다. 특징 : http://<Node-IP>:<NodePort> 로 접속하면 클러스터 외부에서도 노드의 포트를 통해 Service 및 Pod로 트래픽이 포워딩됩니다. 단점 : 포트 번호가 30000번대로 제한되고, 노드의 IP가 변경되면 클라이언트 설정도 바꿔야 해서 프로덕션 환경의 정식 서비스 노출용으로는 거의 쓰이지 않습니다. 3 LoadBalancer (클라우드 파서 연동) 동작 : NodePort 기능을 확장하여, AWS(ALB/NLB), GCP, Azure 같은 클라우드 프로바이더의 외부 로드밸런서(External Load Balancer)를 자동으로 생성하고 연결합니다. 특징 : 클라우드 인프라가 할당한 공인 IP(Public IP)를 받아 정식 도메인과 연결할 수 있습니다. 단점 : Servie를 만들 때마다 클라우드 로드밸런서가 1개씩 새로 생성되므로 인프라 비용이 크게 증가 합니다. 3. L7 영역의 구원자 : Ingress와 Ingress Controller 만약 마이크로서비스가 20개 있다면, LoadBalancer 타입의 서비스를 20개 만들어 클라우드 비용을 20배로 내야 할까요? 그리고 [http://example.com/users](http://example.com/users) 와 [http://example.com/orders](http://example.com/orders) 처럼 URL Path별로 트래픽을 분기 하거나 SSL/TLS 암호화(HTTPS)를 종단 하려면 어떻게 해야 할까요? 이 문제를 해결하기 위해 Ingress 가 등장했습니다. [ External Client ] │ (HTTPS / Domain: example.com) ▼ [ Ingress Controller ] (Nginx / Traefik 등) ├── /users ──> [ Service A (ClusterIP) ] ──> [ User Pods ] └── /orders ──> [ Service B (ClusterIP) ] ──> [ Order Pods ] Ingress (규칙 선언) : L7 레벨에서 어떤 도메인/Path 요청을 어떤 내부 Service로 보낼지 정의하는 설정 명세서(YAML)입니다. Ingress Controller (실제 구동체) : Ingress 명세를 읽어서 실제 프록시 서버(Nginx, Traefik, HAProxy 등) 설정을 동적으로 업데이트하고 트래픽을 라우팅하는 실행 주체 입니다. 💡 핵심 이점 : 단 1개의 외부 로드밸런서(Ingress Controller)만 띄워두고, 내부의 수많은 ClusterIP 서비스들로 L7 도메인 기반 분기 처리와 SSL 인증서 관리를 일괄 처리할 수 있어 비용과 복잡성이 대폭 줄어듭니다. 4. 패킷은 실제로 어떻게 전달되는가? kube-proxy의 역할 그렇다면 Service의 가상 IP(VIP)로 들어온 패킷은 실제로 어떻게 목적지 Pod의 Real IP로 전달될까요? 그 비밀은 각 워커 노드마다 데몬셋(DaemonSet)으로 떠 있는 kube-proxy 에 있습니다. kube-proxy 는 크게 2가지 모드로 동작합니다. 1) iptables 모드 (기본 방식) kube-proxy 가 API 서버를 관찰하다가 Service나 Endpoint가 생기면, Linux 커널의 iptables 규칙을 업데이트합니다. 패킷이 노드로 들어오면, 커널 공간에서 iptables 규칙에 의해 DNAT(Destination NAT)가 수행되어 Service VIP가 실제 Pod IP로 변환됩니다. 한계 : 서비스와 Pod 수가 수천 개 이상으로 늘어나면 iptables 규칙이 비대해지면서 패킷 검색 속도가 증가해 성능 저하가 발생합니다. 2) IPVS (IP Virtual Server) 모드 (대규모 환경) Linux 커널의 L4 로드밸런싱 기능인 IPVS 를 활용합니다. 데이터를 해시 테이블(Hash Table) 구조로 관리하므로 Pod 수가 아무리 늘어나도 O(1)의 일정한 시간 복잡도 로 패킷을 라우팅합니다. 다양한 로드밸런싱 알고리즘(Round-robin, Least Connection, Source Hashing 등)을 지원합니다. 💡 권장 패턴 프로덕션 환경에서는 단 1개의 Ingress Controller(LoadBalancer 타입)를 외부에 노출시키고, 클러스터 내부의 모든 애플리케이션 서비스는 ClusterIP 타입 으로 구성한 뒤 Ingress 규칙으로 연결하는 것이 보안 및 비용 면에서 가장 우수한 표준 아키텍처입니다.