[네떡스터디🔥kans] Cilium CNI 알아보기 - Netkit

CloudNet@ 가시다님이 진행하는 쿠버네티스 네트워크 스터디 KANS 3기 내용을 정리한 글입니다.

<먼저 읽어보면 좋은 글>

2024.10.27 - [K8S/🔥 network study🔥] - [네떡스터디🔥kans] Cilium CNI 알아보기 - TCX

 

Cilium은 Kubernetes와 같은 클라우드 네이티브 환경에서 네트워크 보안과 성능을 강화하기 위해 설계된 네트워크 및 보안 솔루션입니다. 최근 Cilium은 더 높은 네트워크 성능을 위해 netkit이라는 새로운 장치를 도입했는데요. 이번 글에서는 netkit이 어떤 방식으로 성능을 최적화하고, 기존 네트워크 장치와는 무엇이 다른지 살펴보겠습니다. 참고 영상 관련 문서

 

Netkit이란?

 

Netkit은 Cilium이 Kubernetes 환경에서 Pod 간의 네트워크 트래픽을 더 효율적이고 안전하게 처리하기 위해 도입한 프로그래머블 가상 네트워크 장치입니다. 기존에는 Pod 간의 통신을 위해 veth(가상 이더넷) 장치를 사용했지만, Netkit은 이 역할을 대체하며 BPF(eBPF)와의 높은 연동성을 통해 더 빠르고 효율적인 네트워크 처리를 가능하게 합니다.

 

기존의 네트워크 네임스페이스에서는 Pod 간의 통신이 veth(가상 이더넷) 장치를 통해 이루어졌습니다. 하지만 veth 장치는 네임스페이스 전환 시 오버헤드를 발생시켜 애플리케이션의 네트워크 성능 저하를 초래할 수 있습니다. 이를 개선하기 위해 Cilium은 커널에 최적화된 netkit 장치를 도입했습니다.

 

Netkit의 목표는 애플리케이션이 마치 호스트 네임스페이스에 직접 존재하는 것과 유사한 성능을 제공하는 것입니다. 이를 통해 네임스페이스 전환 시 데이터 경로에서 발생하는 오버헤드를 최소화하여, 네임스페이스가 없는 환경에서처럼 높은 스루풋과 낮은 지연 시간을 제공합니다.

 

기존 veth 기반 통신 구조

기존 Kubernetes 네트워크 환경에서 veth(Virtual Ethernet Pair)는 Pod와 호스트 네임스페이스 간의 트래픽을 연결하는 주요 수단이었습니다.

veth의 구조

veth는 두 개의 가상 네트워크 인터페이스로 구성된 쌍입니다. 이 중 하나는 Pod의 네트워크 네임스페이스에, 다른 하나는 호스트 네임스페이스의 네트워크 브리지(cbr0 등) 또는 루프백 인터페이스에 연결됩니다. 이 방식을 통해 각 Pod는 호스트 네트워크를 통해 외부와 통신할 수 있으며, 모든 네트워크 트래픽은 veth 장치를 통해 전달됩니다.

veth의 동작 방식

Pod 내에서 발생한 네트워크 트래픽은 veth 쌍을 통해 호스트 네임스페이스로 전달됩니다. 이후 이 트래픽은 호스트 네임스페이스의 네트워크 스택을 거쳐 외부 네트워크 또는 다른 Pod로 전달됩니다.

veth의 한계

호스트 네트워크 스택 경유로 인한 성능 저하

Pod 간 트래픽이 veth 장치를 통해 호스트 네임스페이스로 이동할 때, 이 패킷은 호스트의 전체 네트워크 스택(IP 포워딩, 라우팅, 방화벽, 큐잉 등)을 거치게 됩니다. 각 단계에서 발생하는 컨텍스트 전환과 추가적인 처리 오버헤드로 인해 성능이 저하될 수 있으며, 특히 대규모 트래픽이 발생하는 환경에서는 성능 문제가 더욱 두드러질 수 있습니다.

네트워크 정책 적용의 유연성 부족

veth는 패킷을 단순히 전달하는 역할을 하기 때문에, eBPF를 사용해 네트워크 정책을 실시간으로 유연하게 적용하는 데 한계가 있습니다. BPF는 커널 수준에서 패킷 필터링, 로깅, 트래픽 제어를 가능하게 해 주지만, veth 자체는 이러한 정책을 적용할 구조가 아닙니다. 결과적으로 세밀한 보안 정책이나 트래픽 제어가 필요한 환경에서는 한계가 발생할 수 있습니다.

양방향 트래픽 제어의 한계

XDP와 같은 기술은 주로 인바운드 트래픽(외부에서 들어오는 트래픽)에만 적용되며, 아웃바운드 트래픽(Pod에서 외부로 나가는 트래픽) 제어는 제한적입니다. veth 기반 통신에서는 아웃바운드 트래픽에 세밀한 정책 적용이 어려워, 네트워크 정책을 적용할 때 성능 손실이 발생할 수 있습니다.

Netkit을 활용한 새로운 통신 구조

Netkit이란

Netkit은 Kubernetes 환경에서 Pod 간 네트워크 연결을 효율적으로 관리하기 위해 도입된 새로운 네트워크 통신 방식입니다. 기존의 veth 기반 구조가 가진 성능 문제와 관리의 한계를 극복하기 위해 개발되었으며, 특히 BPF와의 높은 연동성을 바탕으로 더욱 효율적이고 유연한 네트워크 정책을 제공합니다. Netkit은 primary와 peer로 구성된 구조를 통해 Pod와 호스트 간의 네트워크 통신을 간소화하고 성능을 최적화합니다.

Netkit의 구조

Netkit은 다음과 같은 주요 구성 요소로 이루어져 있습니다

Primary (호스트 네임스페이스에 존재)

BPF 프로그램을 관리하고 모든 네트워크 정책 설정을 담당하여 정책 관리를 일관성있게 유지함

Peer (파드의 네임스페이스에 존재)

primary 장치에서 설정한 네트워크 정책을 그대로 따라가게 되어있다. Peer 장치 자체에서는 BPF 프로그램을 수정하거나 접근할 수 없으며, 모든 정책 설정은 primary 장치에서 이루어지기 때문에 보안성을 강화한다.

Netkit의 동작 방식

Netkit은 primary와 peer 장치의 상호작용을 통해 Pod 간 트래픽을 효율적으로 관리합니다.

 

정책 설정 및 적용

모든 네트워크 정책은 primary 장치에서 설정되며, 이를 통해 중앙에서 모든 정책을 통합 관리할 수 있습니다. 설정된 정책은 primary 장치에서 peer 장치로 전달되며, Pod 내부의 peer 장치는 이 정책을 따릅니다

xmit routine과의 연동

Netkit은 xmit routine을 통해 트래픽이 호스트 네트워크 스택을 거치지 않고도 처리되도록 합니다. xmit routine은 네트워크 패킷이 실제로 네트워크 인터페이스를 통해 전송되기 전의 단계에서 실행되는 함수로, Netkit은 이 루틴에 BPF 프로그램을 연결하여 트래픽을 빠르게 처리합니다. 이를 통해 트래픽을 호스트 네임스페이스에서 전송하기 전, L3 레벨에서 바로 정책을 적용하고 패킷을 제어할 수 있습니다.

양방향 트래픽 처리

Netkit은 인바운드(ingress) 트래픽뿐 아니라 아웃바운드(egress) 트래픽도 효율적으로 처리합니다. 이는 기존의 XDP가 인바운드 트래픽에만 적용되는 것과 달리, Netkit은 Pod에서 외부로 나가는 트래픽에도 네트워크 정책을 실시간으로 적용할 수 있음을 의미합니다. 이로 인해 Netkit은 Kubernetes 환경에서 보다 복잡한 네트워크 정책을 적용할 수 있으며, 네트워크 스택을 깊이 거치지 않으면서도 유연한 정책 관리를 가능하게 합니다.

비교해보기

직접 설치해보기

• 최소 요구사항 커널 6.8 이상
• Direct 라우팅 혹은 터널링
• eBPF 호스트 라우팅 (Cilium이 pod 레벨에서 iptables를 우회해 패킷을 처리하는 기능)

cilium install --namespace kube-system \
  --set routingMode=native \
  --set bpf.datapathMode=netkit \ # <-- datapath의 모드를 netkit으로 변경
  --set bpf.masquerade=true \
  --set kubeProxyReplacement=true \
  --set ipv4NativeRoutingCIDR=<pod cidr> # <-- 공식문서랑 다르게 여기를 추가안해주면 동작안함.

우선 잘 적용이 되었습니다.

cilium agent에 들어가서 상태를 확인해도 제대로 나오는 것을 확인할 수 있습니다.

 

bpftool net 명령어로 확인해봤을 때 tcx가 붙은것도 보입니다.

 

인터페이스 정보를 확인해봤을 때에는 netkit으로 구성된것도 확인해볼 수 있습니다.