[k8s] Service Proxy

#Kubernetes

쿠버에서 CNI가 Pod 간의 통신을 매개하는 역할을 한다면, Service Proxy는 리소스를 내부나 외부 인터넷으로 개방하는 역할을 한다. 더 정확히 말하면 L4에서 Service의 IP 노출을 담당한다.

k8s의 세부 스택들이 으레 그렇듯이, 이것도 단일 구현체가 아니라 여러가지 선택지가 있다.
어떤 구현체들이 있고, 어떤 식으로 각자 동작하는지를 정리해본다.

기본 논리

Service의 기본적인 논리는 다음 그림과 같다.

Service로 들어온 요청을 Pod로 변환해주는 것이다.
이 과정은 L4, TCP/UDP 수준에서 이루어진다.

예를 들어 위 그림처럼 A 서비스가 192.168.0.100로 개방되어있고, A Service에는 B라는 Pod가 10.0.0.2 IP로 붙어있는 상태에서 192.168.0.100로 요청이 들어온다면, kube-proxy는 그걸 가로채서 10.0.0.2 pod로 넘긴다.
이걸 어떤 커널 기능을 써서 네트워크 트래픽을 매개할지는 구현체마다 다르다.

kube-proxy

kube-proxy는 매우 널리 사용되며, 많은 쿠버 배포판에서 기본값으로 사용되는 Service Proxy다.

이건 동작 방식이 크게 3가지가 있다. iptables과 IPVS, nftables 등이다.
단순하고 작은 사용사례에서는 iptables로 충분하지만, 복잡한 사용사례가 필요하다면 다른 모드나 calico 같은 다른 proxy의 사용이 권장된다.

kube-proxy: iptables mode

이건 중소규모의 사용사례에 적합한 프록시 모드고, 상당수의 배포판에서 기본값이다. 리눅스 커널의 iptables에 의존하는 직관적인 구조를 갖고 있다.

Service를 만들거나 변경하면, kube-proxy는 그걸 감시하다가 거기에 맞는 iptable NAT rule을 생성한다. 그러면 커널의 netfilter가 알아서 패킷을 매칭시켜 통과시키는 것이다.

이 방식의 장점은, 커널 기능에 의존하는 것이라 매우 안정적이고 작은 규모에서는 성능도 나쁘지 않다는 것이다.
iptable 명령들을 사용하면 디버깅이나 문제해결도 간편하게 할 수 있다.

단점은 확장에 매우 불리하다는 것이다. rule 추가/삭제와 패킷 전송 양쪽에 병목이 생긴다.
Service나 Pod가 많아진다면 그만큼 iptable rule이 늘어나는건데, 개수에 비례해서 rule 추가 성능이나 패킷 전송 시간이 느려진다. 패킷을 처리할때마다 커널의 netfilter가 rule 개수만큼 O(N) 루프를 돌려야 하기 때문이다.

게다가 rule을 추가하고 삭제하는 것도 작지 않은 부하다.
rule을 1개 추가한다고 해서, 진짜 단순하게 1개만 추가하고 끝이 아니다.
Global Lock을 건 다음에 기존 ruleset을 다운로드하고, 인메모리에서 수정한 뒤에 그걸 커널에 전체 업로드하는 방식이다. 업로드가 끝나면 그제서야 Global Lock을 푼다. Lock으로 인한 블로킹이 심하다.

그래서 Service가 수백/수천 단위를 넘어서는 대규모 사용사례의 경우에는 적합하지 않다.

kube-proxy: IPVS mode (deprecated)

IPVS (IP Virtual Server) 모드는 iptables 모드의 확장성 한계를 개선하고자 나온 방식이다.
이 IPVS도 사실 리눅스 커널에 내장된 로드밸런싱용 커널 기능이다. 자체 구현은 아니다.

이 방식이 해결하고자 했던 것은 iptables의 라우팅 방식이 배열 기반의 O(N) 복잡도라는 것이었다.
하지만 IPVS를 사용하면 트래픽의 로드밸런싱을 해시테이블 기반으로 저장하고 관리한다. 그래서 이론적으로는 O(1)의 복잡도를 가진다.

근데 그렇다고 해서 iptables을 완전히 버린 것은 아니었다. 패킷 필터링과 SNAT 같은 보조적인 부분에는 여전히 iptables을 섞어썼다.

하지만 IPVS + iptables + ipset의 복잡한 아키텍처로 인해 유지보수 부담이 컸고, 새로운 네트워킹 기능과의 통합이 어려워져서, k8s v1.35(2025.12)부터 deprecated 되었다.
이후에는 nftables를 비롯한 eBPF 기반 솔루션으로의 전환이 권장된다.

kube-proxy: nftables mode

nftables는 kube-proxy에서 차세대로 밀어주고 있는 프록시 모드다.
높은 성능과 확장성, 기술 통합을 장점으로 내세운다.

이것도 생짜 구현은 아니고, nftable이라는 리눅스 커널 기능에 의존한다.

iptable에서 가장 심각했던 문제는, 라우팅 rule을 추가할때마다 Lock을 건 채로 전체 rule을 다운받고 수정한 전체 ruleset을 업로드하는 방식이었다는 것이다.
그래서 nftables에서는 incremantal한 rule update를 제공하기 때문에, 이런 문제가 거의 없다. 아무리 많아도 rule의 추가나 삭제는 O(1)로 큰 부하가 걸리지 않는다.

패킷 전송시의 rule lookup도 해시테이블 조회라서, O(1)으로 빠르다. IPVS와 거의 비슷하다.

Calico eBPF

calico를 eBPF 기반으로 구성할 경우, kube-proxy의 역할을 대체할 수 있다.
사용 규모가 크거나 기존에 Calico를 메인을 쓸 경우에 권장할만한 옵션이 된다.

이건 BPF에 라우팅 rule들을 저장해놓고, eBPF 프로그램을 통해 패킷 전달을 처리하는 방식을 취한다.
rule의 추가/삭제와 조회 모두 O(1) 복잡도의 성능을 발휘하는데다, 커널 공간에서 직접 패킷 처리가 이루어지므로 유저-커널 간 컨텍스트 스위칭 없이 오버헤드를 최소화할 수 있다.

Ingress Controller?

envoy, traefik, nginx 같은 로드밸런서 기반의 Ingress Controller들도 Service를 열어주는 역할을 하긴 하지만, 이건 엄밀히 말하면 Service Proxy가 아니다.

L7 기반의 프록시 시스템이고, 실제로 요청이 들어오면 내부적으로는 kube-proxy 같은 L4 서비스 프록시를 한번 더 거쳐서 동작한다. 트래픽 전송을 자체적으로 책임지는 것은 아니란 것이다.

참조
https://kubernetes.io/ko/docs/reference/command-line-tools-reference/kube-proxy/
https://kubernetes.io/ko/docs/concepts/services-networking/service/
https://medium.com/@adityap23/why-kubernetes-deprecated-ipvs-the-shift-to-nftables-explained-d03450efb8ce
https://docs.redhat.com/ko/documentation/red_hat_enterprise_linux/8/html/securing_networks/getting-started-with-nftables_securing-networks