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