Kubernetes kube-proxy: iptables vs IPVS
- K8S에서 Service를 만들면, 클러스터 내부 Pod는
ClusterIP를 통해 접근 가능- 이때 트래픽을 실제 Pod로 보내주는 역할을 하는 게
kube-proxy
- 이때 트래픽을 실제 Pod로 보내주는 역할을 하는 게
- kube-proxy는 iptables 모드와 IPVS 모드 두가지 모드 중 하나로 동작 가능
iptables 모드
K8S 초창기부터 기본으로 사용된 방식
- 동작 원리
- service/endpoint 정보를 iptables 규칙에 직접 기록
- 커널이 NAT 체인을 따라가면서 Pod로 트래픽을 전송
- 장점
- 별도 모듈 설치 없이 바로 사용 가능
- 오래 쓰여온 만큼 안정적이고, 문제 생겼을 때
iptables -t nat -L -n으로 바로 확인 가능
- 단점
- 엔드포인트 수가 많아지면 규칙도 폭발적으로 늘어나 성능 저하가 생길 수 있음
- 규칙을 갱신할 때 전체 체인을 다시 써야 해서 순간 부하 발생
IPVS 모드
리눅스 커널의 IPVS 기능을 사용
- 동작 원리
ip_vs모듈을 이용해 L4 로드밸런서처럼 동작- kube-proxy는 service/endpoint를 커널에 등록만 해두고, 실제 트래픽 처리는 커널이 빠르게 처리
- 장점
- 수천~수만 엔드포인트까지 안정적으로 처리 가능
- 엔드포인트 변경 시 필요한 부분만 업데이트 → 부하 적음
- 라운드로빈, 세션 해시 등 다양한 로드밸런싱 알고리즘 지원
- 단점
- 커널 모듈(
ip_vs)과 유틸리티(ipvsadm,ipset) 설치 필요 - iptables에 비해 디버깅이 낯설 수 있음 (
ipvsadm -Ln확인 필요)
- 커널 모듈(
선택 기준
- iptables 모드
- 수십~수백 노드, 수천 개 엔드포인트 수준
- 운영 단순성, 문제 대응 속도 중시
- IPVS 모드
- 수천 노드 이상, 서비스 엔드포인트 수가 수만 단위
- 대규모 SaaS 환경, 트래픽이 매우 많은 서비스
- 고급 로드밸런싱(세션 어피니티 등) 필요한 경우
kubespray는 기본적으로 IPVS로 동작