83. Kube-proxy - 노드 내부의 네트워크 라우팅 및 서비스 로드밸런싱 통신 규칙(iptables/IPVS) 설정

핵심 인사이트 (3줄 요약)

본질: Kube-proxy는 쿠버네티스 클러스터의 모든 워커 노드(Worker Node)에 하나씩 상주(DaemonSet)하는 네트워크 프록시 에이전트로, 파드(Pod) 간 통신과 외부 트래픽을 목적지 파드로 정확히 전달하기 위한 네트워크 라우팅 규칙을 관리한다.

가치: 파드(Pod)는 생성과 삭제를 반복하며 IP 주소가 끊임없이 변하지만, Kube-proxy가 변하지 않는 가상의 IP인 '서비스(Service)' 객체의 트래픽을 가로채어 현재 살아있는 실제 파드들의 IP로 로드밸런싱(분산)해 주어, 개발자가 IP 변경에 신경 쓰지 않게 완벽한 네트워크 추상화를 달성한다.

융합: 초창기에는 스스로 트래픽을 복사해 나르는 무거운 프록시 모드(Userspace)였으나, 현대 Kube-proxy는 직접 통신을 중계하지 않고 리눅스 커널의 네트워크 통제 모듈인 iptables나 고성능 해싱 모듈인 IPVS에 라우팅 룰셋만 심어두고 빠지는 가벼운 '설정자(Configurator)' 역할로 융합 진화하여 클러스터 트래픽의 병목을 없앴다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: Kube-proxy는 쿠버네티스(K8s) 네트워크의 핵심 배관공이다. 마스터 노드(API Server)로부터 "결제 서비스(Service A)를 띄웠고, 여기에 파드 3개(IP 1.1, 1.2, 1.3)가 붙어있다"는 정보를 실시간으로 전달받아, 노드 안으로 들어오는 트래픽이 결제 서비스 IP(Virtual IP)를 찾으면 파드 3개 중 하나로 랜덤하게 포워딩되도록 노드의 네트워크 커널 스위치를 조작한다.
필요성: 쿠버네티스의 파드(컨테이너)는 영원하지 않다(Ephemeral). 언제든 죽고 다시 살아나며 그때마다 IP 주소가 새로 부여된다. 만약 프론트엔드 파드가 백엔드 파드의 IP를 하드코딩해서 통신하고 있다면 백엔드가 죽고 새로 태어날 때마다 프론트엔드는 통신 끊김(404)을 겪게 된다. Kube-proxy는 이 유동적인 파드 IP들 앞에 고정된 단일 진입점(Service VIP)을 세워주고, 뒷단 파드가 죽든 말든 최신 상태표를 계속 추적해 길을 뚫어줌으로써 마이크로서비스(MSA) 통신의 완벽한 디커플링(Decoupling)을 가능하게 한다.
💡 비유: Kube-proxy는 건물 로비에 있는 "초고속 무전기 교환원"과 같다. 외부에서 손님이 "영업부서(Service)로 연결해 주세요"라고 하면, 교환원은 오늘 출근해서 이리저리 자리를 옮겨 다니는 김대리, 이대리, 박대리(실제 Pod IP들)의 현재 위치를 정확히 파악하고 있다가, 지금 제일 안 바쁜 사람의 내선 번호로 전화를 쏙 넘겨준다(로드밸런싱). 직원이 매일 바뀌어도 손님은 '영업부서'라는 간판 번호 하나만 알면 된다.
📢 섹션 요약 비유: 수시로 주소가 바뀌는 푸드트럭들(파드)을 찾아다닐 필요 없이, 단골손님들은 항상 같은 골목(서비스 VIP)으로 가기만 하면, Kube-proxy라는 안내 요원이 그날 문 연 푸드트럭으로 알아서 길을 안내하고 트래픽 꼬깔콘(iptables)을 깔아주는 완벽한 교통 정리 시스템입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

Kube-proxy의 클러스터 내 동작 아키텍처

Kube-proxy는 데이터 흐름의 주체가 아니라, 길을 만들어주는 제어판(Control Plane) 연장선에 가깝다.

  ┌───────────────────────────────────────────────────────────────────┐
  │                 Kube-proxy 네트워크 로드밸런싱 구조                 │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │    [마스터 노드]                                                    │
  │     API Server ◀── (Service 및 Endpoints 변경 이력 관리)           │
  │         │                                                         │
  │    (Watch/수신)                                                   │
  │         ▼                                                         │
  │  ===============================================================  │
  │  [워커 노드 (Worker Node)]                                          │
  │                                                                   │
  │   1. [Kube-proxy Daemon]                                          │
  │       - API Server를 감시하다가 새 파드(IP)가 뜨면 감지.                 │
  │       - "아! 결제 서비스(10.0.0.1)의 뒷단에 파드가 3개로 늘었구나!"       │
  │           │                                                       │
  │       (규칙 설정/업데이트)                                            │
  │           ▼                                                       │
  │   2. [리눅스 커널 네트워크 계층 (iptables 또는 IPVS)] ◀ 진짜 일하는 놈 │
  │       - 규칙 A: 목적지 IP가 10.0.0.1(Service VIP)인 패킷이 들어오면,    │
  │                 33% 확률로 -> Pod-1 (192.168.1.1)로 DNAT 해라!     │
  │                 33% 확률로 -> Pod-2 (192.168.1.2)로 DNAT 해라!     │
  │                 33% 확률로 -> Pod-3 (192.168.1.3)로 DNAT 해라!     │
  │                                                                   │
  │   3. [트래픽 흐름]                                                   │
  │      외부 사용자/다른 파드 ────▶ [커널 규칙 적용] ────▶ 실제 Pod 1, 2, 3 │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] Kube-proxy 아키텍처의 핵심은 "자신이 패킷을 직접 받아 나르지 않는다"는 점이다. Kube-proxy는 API Server를 주시(Watch)하며 서비스(Service)와 엔드포인트(Endpoints: 실제 파드 IP 목록) 상태의 변화를 추적한다. 변화가 생기면, 즉각 노드 운영체제(리눅스 커널)의 심장부인 iptables나 IPVS 모듈에 접속해 "목적지 주소 변환(DNAT) 규칙"을 심어놓고 쿨하게 빠진다. 이후 들어오는 막대한 트래픽은 Kube-proxy라는 프로세스를 거치지 않고 OS 커널 단에서 번개처럼 빠르게 파드들로 라우팅된다.

Kube-proxy의 3가지 동작 모드 진화 (Modes)

초창기 모델의 성능 병목을 극복하기 위해 Kube-proxy는 점차 커널 영역 깊숙이 라우팅 책임을 위임(Offloading)하는 방향으로 진화했다.

모드 (Mode)	통신 중계 주체 (누가 패킷을 옮기나?)	작동 방식 및 특징	성능 및 한계	비유
Userspace (초기형)	Kube-proxy 자체 (사용자 영역)	모든 패킷이 커널을 통과해 Kube-proxy 프로세스로 올라온 뒤 목적지 파드로 재전송됨 (프록시 서버).	가장 느림. 병목 극심. (현재는 사실상 폐기됨)	사장님이 직접 우체국에 가서 편지를 받아와서 사원들에게 일일이 나눠줌.
iptables (현재 기본값)	리눅스 커널 Netfilter	Kube-proxy는 커널(iptables)에 룰만 심음. 패킷은 커널 안에서 확률적(Random)으로 파드에 뿌려짐.	준수함. 단, 파드가 1만 개 이상 커지면 순차(순차 탐색) 룰 검색에 의한 지연 발생.	사장님은 각 부서 우편함에 '이름표(룰)'만 붙여두고, 우체부가 직접 넣게 함.
IPVS (대규모 최적화)	리눅스 커널 LVS (고성능 로드밸런서)	iptables 룰 방식 대신 해시(Hash) 테이블을 사용하여 O(1)의 속도로 룰을 탐색하고 정교한 밸런싱(RR, LC 등) 알고리즘 제공.	가장 빠름. 대규모(Mega) 클러스터에서 극강의 퍼포먼스 발휘.	우체국 기계가 바코드를 스캔해 빛의 속도로 편지를 목적지 랙으로 자동 분류.

📢 섹션 요약 비유: Kube-proxy는 진화할수록 일선에서 물러났습니다. 처음엔 자기가 직접 교통경찰 노릇을 하며 땀 흘려 차를 안내(Userspace)했지만, 이제는 교차로에 초고성능 자동 신호등과 카메라(iptables/IPVS)만 몰래 설치해 두고 관제실에서 버튼만 누르는 스마트한 지휘관으로 거듭났습니다.

Ⅲ. 융합 비교 및 다각도 분석

Kube-proxy 로드밸런싱 vs 인그레스 (Ingress) / 외부 로드밸런서(L4)

초보자들이 가장 헷갈려하는 쿠버네티스의 트래픽 분산 레이어 구분이다. 이들은 대체재가 아니라 서로 계층을 이루는 보완재다.

비교 항목	클라우드 외부 L4 (AWS ELB)	인그레스 (Ingress Controller, L7)	Kube-proxy (Service, L4)
설치 위치	K8s 클러스터 밖 (망 입구)	클러스터 안 (진입점 관문 역할)	클러스터 안의 모든 워커 노드
분산 타겟	외부 인터넷 → 각 K8s 노드(Node) 들로 분산	노드 → URL/경로 기준으로 각 서비스로 분산	서비스 VIP → 진짜 파드(Pod IP) 들로 최종 쪼개서 분산
처리 계층 (OSI)	L4 (IP, Port 기반)	L7 (HTTP, URL, 헤더, 도메인 기반)	L4 (IP, Port 기반)
역할 요약	"우리 회사로 들어오는 큰 대문"	"도메인과 /api 경로를 보고 부서 층수 안내"	"부서 안에 들어온 서류를 직원(Pod) 책상에 뿌리기"

즉, 외부 트래픽이 클러스터로 들어오면 외부 ELB -> 인그레스 -> Kube-proxy(Service 룰) -> 실제 Pod 라는 수문장 체인(Chain)을 거쳐 최종 목적지에 도달하게 된다.

📢 섹션 요약 비유: 백화점을 비유하자면, 외부 ELB는 건물 정문의 회전문이고, 인그레스는 "1층은 화장품, 2층은 의류"라고 쓰인 엘리베이터 안내판이며, Kube-proxy는 2층 의류 매장에 도착한 손님을 비어있는 특정 점원(파드) 앞으로 정확히 모셔다주는 층별 매니저입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 마이크로서비스 파드 증가에 따른 네트워크 레이턴시 지연 (iptables의 한계): 대규모 커머스 시스템에서 세일 기간 파드를 수천 개로 오토스케일링(HPA)시켰다. 그러자 갑자기 클러스터 내 서비스 간 통신(API 호출) 속도가 뚝 떨어졌다.
- 기술사적 판단: 이는 Kube-proxy가 기본값인 iptables 모드로 작동할 때 발생하는 선형 탐색(O(N)) 병목 현상이다. iptables는 룰(파드 개수)이 많아질수록 패킷이 위에서부터 아래로 룰을 하나씩 대조하며 읽어 내려가므로 CPU 부하와 지연이 폭증한다. 아키텍트는 5,000개 이상 서비스 룰이 발생하는 클러스터라면, Kube-proxy의 설정(ConfigMap)을 변경하여 해시 기반의 O(1) 탐색을 보장하는 IPVS 모드로 전면 전환해야 네트워크 성능 붕괴를 막을 수 있다.
시나리오 — 클라이언트의 진짜 IP(Source IP) 유실 현상 극복: 외부 사용자가 K8s 서비스(NodePort)를 통해 들어올 때, 백엔드 애플리케이션 로그에 찍히는 접속자 IP가 진짜 고객 IP가 아니라 K8s 노드의 내부 IP로 찍히는 현상이 발생하여, 마케팅팀의 사용자 접속 지역(Geo) 분석이 불가능해졌다.
- 기술사적 판단: Kube-proxy는 패킷을 다른 노드에 있는 파드로 포워딩(라우팅)할 때 리턴 경로를 보장하기 위해 패킷의 출발지 IP를 자신의 노드 IP로 덮어쓰는 SNAT (Source Network Address Translation) 를 수행하기 때문이다. 이 문제를 해결하려면 서비스 객체의 externalTrafficPolicy: Local 속성을 적용하여, 트래픽을 받은 노드 안에 있는 파드에게만 패킷을 전달하게 강제함으로써 SNAT를 우회하고 진짜 Source IP를 보존하는 아키텍처 설계를 적용해야 한다. (단, 이 경우 노드 간 트래픽 불균형이 발생할 수 있는 트레이드오프를 감수해야 한다.)

클러스터 네트워크 진단 체크리스트

데몬셋(DaemonSet) 상태: kubectl get ds -n kube-system을 쳐서 Kube-proxy가 새로 추가된 노드 위에도 빠짐없이 떠서(Running) 룰셋을 받고 있는지 모니터링하는가?
CNI(Container Network Interface) 파편화: Kube-proxy는 라우팅 룰은 만들지만 실제 패킷을 캡슐화해 날려주는 Calico, Flannel 같은 CNI 플러그인과 찰떡같이 호환되어야 한다. CNI와 IPVS 모드가 충돌 없이 구성되었는지 클러스터 초기 구축 시 검증(BMT)했는가?
📢 섹션 요약 비유: 동네 식당(작은 클러스터)에서는 사장님이 주문서(iptables 룰)를 벽에 주르륵 붙여놓고 위에서부터 읽으며 요리해도 되지만, 거대 호텔 뷔페(수만 파드)에서는 바코드 스캐너(IPVS)로 0.1초 만에 주문을 분류해야만 주방이 멈추지 않는다는 것이 아키텍트의 성능 최적화 지혜입니다.

Ⅴ. 기대효과 및 결론

기대효과

완벽한 네트워크 추상화 (Abstraction): 개발자(애플리케이션)는 뒷단 데이터베이스 파드의 IP가 하루에 백 번 바뀌어도 알 필요가 없다. 고정된 클러스터 내부 도메인(예: db-svc.default.svc.cluster.local) 하나만 호출하면 Kube-proxy가 마법처럼 살아있는 파드로 트래픽을 토스해 준다.
무중단 인프라 롤링 업데이트: 파드의 버전을 1.0에서 2.0으로 롤링 배포할 때, Kube-proxy가 iptables 룰을 눈 깜짝할 새에 1.0 컨테이너에서 2.0 컨테이너 IP로 바꿔 꽂아주어 사용자 입장에선 단 1초의 서버 끊김(Downtime)도 느끼지 못하게 한다.

미래 전망 (eBPF와 Cilium의 등장)

Kube-proxy의 iptables나 IPVS는 수십 년 된 레거시 리눅스 커널 기술을 K8s에 억지로 짜맞춰 쓰는 것에 가깝다. 최근 클라우드 네이티브 생태계에서는 이 무거운 Kube-proxy 프로세스 자체를 아예 클러스터에서 뽑아버리고 (Kube-proxy replacement), 리눅스 커널 안에서 직접 초고속으로 프로그래밍이 가능한 eBPF (Extended Berkeley Packet Filter) 기술을 기반으로 한 Cilium 같은 차세대 CNI로 통신 패러다임을 전면 대체하는 혁명이 진행 중이다.

결론

Kube-proxy는 보이지 않는 곳에서 쿠버네티스의 "선언적 상태(Desired State) 유지"라는 위대한 철학을 네트워킹 계층에서 완성해 내는 묵묵한 톱니바퀴다. "파드 IP는 변하지만, 서비스 IP는 변하지 않는다"는 이 극도의 단순함 뒤에는, 워커 노드마다 찰거머리처럼 들러붙어 수천 개의 iptables 룰을 초 단위로 지우고 새로 쓰기를 반복하는 Kube-proxy의 처절한 땀방울이 숨어 있다. 차세대 클라우드 인프라 아키텍트는 kubectl 명령어로 파드를 띄우는 겉모습에 만족하지 않고, 패킷이 리눅스 커널 레벨에서 어떻게 쪼개지고 NAT 변환되어 목표물에 꽂히는지 Kube-proxy의 심연을 이해할 수 있어야 치명적인 네트워크 장애를 디버깅할 수 있다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
서비스 (Service / ClusterIP, NodePort)	Kube-proxy가 보호하고 트래픽을 분산해 주는 가상의 고정 IP(VIP)이자 쿠버네티스 핵심 오브젝트이다.
엔드포인트 (Endpoints)	Kube-proxy가 라우팅 룰을 만들 때 목적지로 삼는 '현재 살아있는 파드(Pod)들의 실제 IP 주소 목록' 묶음이다.
iptables / Netfilter	리눅스 커널에 내장된 강력한 방화벽 및 패킷 조작 프레임워크로, Kube-proxy가 서비스 트래픽을 가로채 파드로 포워딩(DNAT)하는 물리적 수단이다.
IPVS (IP Virtual Server)	iptables의 순차 탐색 병목을 해결하기 위해 Kube-proxy 고급 모드에 도입된 LVS 기반의 초고속 해시 로드밸런싱 리눅스 모듈이다.
CNI (Container Network Interface)	Kube-proxy가 길(룰)을 터주면, 서로 다른 노드 간에 실제 파드 패킷을 캡슐화(VXLAN, BGP)하여 배달해 주는 짝꿍 플러그인(Calico, Flannel 등)이다.

👶 어린이를 위한 3줄 비유 설명

쿠버네티스 아파트에는 택배기사(사용자 트래픽)가 찾아오는데, 문제는 아파트 주민들(파드)이 매일매일 이사하고 방 번호를 바꿔서 택배를 주기 힘들다는 거예요.
이때 건물 로비 층층마다 상주하는 Kube-proxy라는 초능력 경비원이 등장해요. 경비원은 아파트 방송(API 서버)을 귀 쫑긋 듣고 있다가, 오늘 철수가 301호에 있다는 걸 즉시 파악하죠.
택배기사가 "철수한테 주세요" 하고 박스(패킷)를 던지면, 경비원이 눈보다 빠른 손놀림(iptables)으로 박스 겉면의 주소를 301호로 쓱 덮어써서 슝 날려준답니다!