👋 kube-proxy와 작별하고 Cilium을 맞이해야 하는 이유

https://github.com/cilium/hubble

 

쿠버네티스(Kubernetes) 환경에서 네트워크는 시스템의 혈관과도 같습니다. 컨테이너들이 서로 원활하게 통신하고, 외부 요청을 올바른 서비스로 전달하는 모든 과정이 네트워크에 의존하기 때문이죠. 이때 아주 중요한 역할을 하는 컴포넌트가 바로 kube-proxy입니다. 하지만 최근 클라우드 네이티브 환경이 발전하면서 kube-proxy의 한계가 드러났고, Cilium이라는 강력한 대안이 주목받고 있습니다.

이번 글에서는 Cilium이 왜, 그리고 어떻게 kube-proxy의 역할을 완벽하게 대체하며 더 나은 쿠버네티스 네트워킹 환경을 만드는지 상세히 알아보겠습니다.

1. 기존 방식의 한계: kube-proxy는 어떻게 일했나?

먼저 kube-proxy가 어떤 일을 하는지 이해해야 합니다. kube-proxy의 핵심 임무는 쿠버네티스의 '서비스(Service)' 개념을 실제 네트워크 트래픽으로 연결해주는 것입니다. 특정 서비스로 들어온 요청을, 그 서비스에 속한 실제 파드(Pod)들에게 분산(Load Balancing)하는 역할을 하죠.

kube-proxy는 이 임무를 수행하기 위해 주로 두 가지 방식에 의존합니다.

iptables 모드

• 동작 방식: 쿠버네티스 클러스터의 모든 서비스와 엔드포인트(파드 IP)에 대한 정보를 커널의 iptables 규칙으로 변환하여 저장합니다. 패킷이 들어올 때마다 이 긴 규칙 목록을 순차적으로 탐색하여 목적지를 찾아냅니다.
• 문제점: 클러스터 규모가 커져 서비스와 파드의 수가 수천, 수만 개로 늘어나면 iptables 규칙의 수도 기하급수적으로 증가합니다. 이는 심각한 성능 저하를 유발합니다. 모든 패킷이 거대한 규칙 체인을 통과해야 하므로 네트워크 지연 시간(latency)이 늘어나는 것은 당연한 결과입니다.

IPVS (IP Virtual Server) 모드

• 동작 방식: iptables의 성능 문제를 해결하기 위해 등장했습니다. IPVS는 커널 내에서 해시 테이블을 사용하여 서비스 요청을 훨씬 빠르게 처리합니다. 규칙을 순차적으로 검색하는 대신, 해시 테이블을 통해 바로 목적지를 찾으므로 대규모 환경에서 iptables보다 훨씬 효율적입니다.
• 문제점: IPVS가 성능은 개선했지만, 여전히 커널의 Netfilter 프레임워크에 의존하며, 복잡한 트래픽 정책을 적용하거나 세밀한 모니터링을 하는 데는 한계가 있었습니다.

결론적으로 kube-proxy는 대규모 최신 클라우드 환경이 요구하는 성능, 확장성, 그리고 가시성 측면에서 뚜렷한 한계를 보였습니다.

---

2. 새로운 혁신: Cilium과 eBPF의 등장

Cilium은 CNI(Container Network Interface) 플러그인의 한 종류이지만, 단순한 네트워크 연결을 넘어 보안, 관찰 가능성까지 제공하는 강력한 솔루션입니다. Cilium의 핵심 기술은 바로 eBPF(extended Berkeley Packet Filter)입니다.

eBPF란? 🤹 eBPF는 리눅스 커널의 코드를 직접 수정하지 않고도, 샌드박스 환경에서 커널의 동작을 프로그래밍하고 확장할 수 있게 해주는 혁신적인 기술입니다. 네트워크 패킷 처리, 시스템 콜 감시 등 커널의 깊숙한 곳에서 일어나는 이벤트를 가로채 원하는 로직을 실행할 수 있습니다. 비유하자면, 커널에 안전한 '플러그인'을 설치하는 것과 같습니다.

Cilium은 이 eBPF를 활용하여 kube-proxy의 기능을 완전히 대체하고 뛰어넘습니다.

---

3. Cilium이 kube-proxy를 대체하는 결정적 이유

Cilium이 kube-proxy를 대체했을 때 얻을 수 있는 장점은 명확합니다.

🚀 1. 압도적인 성능과 확장성

Cilium은 iptables나 IPVS를 전혀 사용하지 않습니다. 대신, 네트워크 인터페이스에 eBPF 프로그램을 직접 연결합니다.

• 직접 경로 라우팅(Direct Path Routing): 서비스로 들어온 패킷은 eBPF 프로그램에 의해 즉시 목적지 파드로 직접 전달됩니다. 복잡한 iptables 체인을 거치거나 Netfilter 훅을 통과할 필요가 없어 네트워크 지연 시간이 크게 감소합니다.
• 효율적인 로드 밸런싱: Cilium은 eBPF 맵(map)이라는 효율적인 키-값 저장소를 사용하여 서비스와 파드 정보를 관리합니다. 이를 통해 매우 빠르고 효율적인 로드 밸런싱이 가능하며, 클러스터 규모가 커져도 성능 저하가 거의 없습니다.

🔭 2. 강력한 가시성과 트러블슈팅

kube-proxy 환경에서는 네트워크 문제의 원인을 파악하기가 매우 어렵습니다. "패킷이 어디선가 사라졌는데, 그게 iptables 규칙 때문인지 다른 문제인지" 알기 힘든 경우가 많았죠.

Cilium은 eBPF를 통해 커널 수준에서 모든 네트워크 흐름을 관찰할 수 있습니다.

• Hubble: Cilium은 Hubble이라는 내장된 관찰 가능성 도구를 제공합니다. Hubble을 통해 서비스 간의 통신 흐름, DNS 요청, 네트워크 정책에 의해 차단된 트래픽 등을 실시간으로 시각화하고 추적할 수 있습니다. 이는 디버깅과 트러블슈팅의 난이도를 혁신적으로 낮춰줍니다.

🛡️ 3. 강화된 보안 기능

Cilium은 네트워크 연결(CNI)과 보안 정책(Network Policy) 적용을 eBPF를 통해 하나로 통합했습니다.

• L3/L4 및 L7 정책 적용: IP 주소와 포트(L3/L4) 기반의 정책뿐만 아니라, HTTP 메서드(GET, POST)나 Kafka 토픽 같은 애플리케이션 레이어(L7) 수준의 세밀한 보안 정책을 적용할 수 있습니다. 예를 들어, 'A 서비스는 B 서비스의 /read API는 호출할 수 있지만, /write API는 호출할 수 없다'와 같은 정책을 사이드카 프록시 없이 구현할 수 있습니다.

🔗 4. 효율적인 서비스 메시 (Service Mesh)

기존의 서비스 메시는 Istio처럼 각 파드에 사이드카 프록시(Envoy 등)를 추가하여 구현하는 방식이 일반적이었습니다. 이는 추가적인 리소스 소모와 관리 복잡성을 야기했습니다.

Cilium은 eBPF를 활용하여 사이드카 없이(Sidecar-less) 서비스 메시의 핵심 기능(로드 밸런싱, 관찰 가능성, 보안)을 구현할 수 있어 훨씬 가볍고 효율적인 서비스 메시 아키텍처를 구성할 수 있습니다.

---

결론: 네트워킹의 패러다임 전환

정리하자면, Cilium이 kube-proxy를 대체하는 것은 단순히 하나의 컴포넌트를 바꾸는 것을 넘어, 쿠버네티스 네트워킹의 패러다임을 전환하는 것입니다.

• kube-proxy는 iptables/IPVS라는 기존 커널 기능에 의존하는 방식이었습니다.
• Cilium은 eBPF라는 기술로 커널 자체를 프로그래밍하여 더 지능적이고 효율적으로 네트워크를 제어하는 방식입니다.

성능, 확장성, 가시성, 보안 등 모든 면에서 Cilium은 kube-proxy를 뛰어넘는 가치를 제공합니다. 대규모의 복잡한 마이크로서비스 환경을 운영하고 있다면, kube-proxy를 Cilium으로 교체하는 것은 더 이상 선택이 아닌 필수가 되어가고 있습니다.