서비스 프록시

쿠버네티스의 서비스가 트래픽을 올바른 파드(Pod)로 전달하도록 중간에서 라우팅·포워딩을 해주는 구성 요소

요청으로 온 cluster IP를 실제 Pod IP와 연결해준다.

 

대표적으로 kube-proxy가 있으며 3가지 방식으로 움직인다.

 

iptables - 서비스의 가상 IP와 포트를 커널레벨의 iptables 규칙으로 등록 후 패킷을 해당 서비스의 파드로 NAT

 

IPVS - 리눅스 커널의 IPVS 모듈을 이용 - 대규모 작업에 효과적

 

userspace - kube-proxy 프로세스가 직접 소켓을 포워딩하는 형식(현재는 거의 안쓰임)

 

 

iptables 방식

# ClusterIP로 들어온 패킷을 서비스 체인으로 이동
-A KUBE-SERVICES -d 10.96.0.1/32 -p tcp --dport 80 \
  -j KUBE-SVC-XXXXXXX

# 서비스 체인 → 엔드포인트 체인 (라운드 로빈)
-A KUBE-SVC-XXXXXXX -m statistic --mode random --probability 0.333333 \
  -j KUBE-SEP-AAAAAAA
-A KUBE-SVC-XXXXXXX -j KUBE-SEP-BBBBBBB
...

# 엔드포인트 체인에서 DNAT 수행
-A KUBE-SEP-AAAAAAA -j DNAT --to-destination 10.244.1.5:80

 

• 커널수준에서 처리하기에 빠른 편이고, 의존성이 적다는 장점이 있다.
• 서비스나 파드수가 늘어날수록 규칙이 더 복잡해지기 때문에 업그레이드 시 성능저하의 위험이 있다.

 

 

 

 

IPVS 방식

 

• 원리: Linux 커널의 IPVS (IP Virtual Server) 모듈을 사용
• IPVS는 iptables보다 더 전문적인 L4 로드밸런싱 엔진
• kube-proxy가 ipvsadm 명령을 통해 서비스와 엔드포인트를 커널에 등록
• 커널 내부에서 해시 테이블로 매핑 → 검색과 라우팅 속도가 훨씬 빠름

 

TCP  10.96.0.1:80 rr
  -> 10.244.1.5:80  Masq    1  0  0
  -> 10.244.2.8:80  Masq    1  0  0
  -> 10.244.3.12:80 Masq    1  0  0

• 커널 레벨 해시 기반 → 규칙이 많아져도 빠름
• 다양한 LB 알고리즘 지원 (rr, lc, sh 등)
• iptables보다 업데이트 시 부하 적음

• IPVS 모듈이 커널에 로드되어 있어야 함 (추가 설정 필요할 수도 있음)