eBPF와 함께하는 Cilium 핸즈온: Pod부터 Service 통신까지

요약

안녕하세요! 악분입니다.

 

이 글은 Cilium을 처음 접하는 사용자를 위한 핸즈온입니다. 핸즈온이란 직접 실습하면서 동작원리를 이해하고 디버깅하는 과정을 말합니다. Cilium 설치부터 Pod 통신, Service 통신, Observability까지 예제를 준비했습니다. 특히 eBPF를 기반으로 한 Cilium의 네트워크 작동 원리와 IPAM, 라우팅, 터널 모드를 이해할 수 있도록 예제를 만들었습니다.

 

eBPF에 대한 내용은 이전 저의 블로그를 참고하면 좋습니다.

- eBPF 링크: https://malwareanalysis.tistory.com/885

공식문서로 이해하는 eBPF 입문

 

 

목차

• Cilium 핸즈온
• Cilium 설치
• 예제 1: 공식 문서 Quickstart Star Wars 데모 배포
• 예제 2: IPAM(IP Address Management)
• 예제 3: Pod와 Host 네트워크 인터페이스 설정
• 예제 4: eBPF 프로그램 조회
• 예제 5: 동일 node 내 Pod 간 통신
• 예제 6: 다른 node에 있는 Pod 간 통신
• 예제 7: 쿠버네티스 Service 통신 확인
• 예제 8: Observability

 

Cilium 설치

Cilium 실습을 위해 쿠버네티스와 Cilium을 설치해야 합니다. 쿠버네티스는 kind cluster를 사용했습니다. 그리고 Cilium은 Cilium CLI를 사용했습니다.

• 설치문서 github 링크: https://github.com/choisungwook/portfolio/blob/master/kubernetes/cilium/install

 

예제 1: 공식 문서 Quickstart Star Wars 데모 배포

Cilium은 Star Wars 데모를 제공합니다. 이 글은 Star Wars 데모를 사용하여 Cilium의 주요 기능을 테스트합니다

- 참고자료: https://docs.cilium.io/en/stable/gettingstarted/demo/

 

• 데모 앱 배포

kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/1.18.5/examples/minikube/http-sw-app.yaml

• Pod, Service 확인

kubectl get pod,svc

 

예제 2: IPAM(IP Address Management)

Cilium은 IPAM 기능을 제공하여 Pod의 IP 주소를 관리합니다.

$ kubectl get pod -owide
$ kubectl get ciliumendpoints

 

Cilium의 기본 IPAM 모드는 Cilium CLI로 조회할 수 있습니다.

cilium config view | grep ^ipam

 

Cilium CLI로 설치 시 기본적으로 쿠버네티스 host-scope 모드를 사용합니다. 이 모드에서 Cilium은 각 node에 할당된 Pod CIDR을 참조하여 Pod에 IP를 할당합니다.

kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDR}{"\n"}{end}'

 

예제 3: Pod와 Host 네트워크 인터페이스 설정

Pod가 생성되면 통신을 위해 veth(Virtual Ethernet) 네트워크 인터페이스가 생성됩니다. Cilium 환경에서는 이 veth 인터페이스의 이름이 lxc로 시작합니다. ip addr show 명령어를 사용하면, 아래 그림과 같이 Pod와 host에 각각 연결된 veth 네트워크 인터페이스를 확인할 수 있습니다.

# Pod 안에서 확인
kubectl exec xwing -- ip addr show | tail -6

# host에서 확인
ip addr show | grep if{xx}

 

예제 4: eBPF 프로그램 조회

lxc 네트워크 인터페이스에는 Pod로부터 패킷을 수신할 때 실행되는 eBPF 프로그램이 연결되어 있습니다. 이 eBPF 프로그램의 이름은 cil_from_container입니다.

kubectl exec {cilium daemonset pod} -n kube-system -- bpftool net show dev {lxc interface}

 

예제 5: 동일 node 내 Pod 간 통신

동일한 node에 있는 Pod끼리 통신이 정상적으로 이루어지는지 확인합니다.

# 1. deathstar Pod IP 조회
$ kubectl get pod -owide
NAME                         IP ...
deathstar-86f85ffb4d-d4db4   10.244.1.130

# 2. xwing Pod -> deathstar Pod 통신
kubectl exec xwing -- curl -s -XPOST 10.244.1.130/v1/request-landing

 

앞서 예제 4에서 확인한 eBPF 프로그램이 Pod 간의 통신을 담당합니다. eBPF 프로그램이 패킷을 어디로 보낼지 결정하는 과정을 라우팅(Routing)이라고 합니다.

 

라우팅 규칙은 eBPF map을 통해 관리됩니다. eBPF map은 eBPF 프로그램의 데이터를 저장하는 커널 저장공간입니다. 용도에 따라 여러 종류의 map이 있으며, eBPF 프로그램은 특정 상황에 맞는 map을 참조하여 동작합니다.

 

ipcache map은 목적지 Pod가 출발지 Pod와 동일한 node에 있는지 확인하고, 관련된 네트워크 policy를 검사하는 역할을 합니다. xwing Pod에서 deathstar Pod로 통신하는 시나리오를 예로 들면, 두 Pod가 동일한 node에 위치하므로 ipcache list에서 tunnel endpoint가 0.0.0.0으로 표시됩니다.

kubectl exec {cilium daemonset pod} -n kube-system -- cilium bpf ipcache list

 

ipcache map을 통해 출발지와 목적지 Pod가 같은 node에 있음을 확인하면, 다음으로 endpoint map을 조회합니다. 이 map에는 패킷을 전달(redirect)해야 할 네트워크 인터페이스 정보가 담겨 있습니다. 커널 버전이나 Cilium 모드 설정에 따라 패킷을 전달할 네트워크 인터페이스가 달라질 수 있습니다.

 

아래 그림에서는 eBPF 프로그램이 deathstar Pod의 네트워크 인터페이스로 패킷을 직접 전달합니다.

kubectl exec {cilium daemonset pod} -n kube-system -- cilium bpf endpoint list

 

예제 6: 다른 node에 있는 Pod 간 통신

앞선 예제 5에서는 동일한 node 내의 Pod 간 통신을 다루었습니다. 이번에는 서로 다른 node에 위치한 Pod 간의 통신이 어떻게 이루어지는지 살펴보겠습니다. 통신 방식은 Cilium에 설정된 라우팅 모드에 따라 달라집니다. 이 예제에서는 VXLAN 프로토콜을 사용하는 터널 모드(tunnel mode)를 기준으로 설명합니다. 라우팅 설정은 cilium-config ConfigMap에서 확인할 수 있습니다.

kubectl get cm -n kube-system cilium-config -o yaml | grep -E "tunnel|routing-mode"

 

터널 모드는 서로 다른 node의 Pod 간 통신 시 오버레이(Overlay) 네트워크를 사용합니다. 일반적으로 Pod는 자신의 node를 벗어나 다른 node의 Pod와 통신할 때 node의 IP를 통해야 합니다. 하지만 이 경우 Pod의 IP 정보가 유실되어 통신이 실패할 수 있습니다. 오버레이 통신은 기존 IP 헤더 외에 추가적인 헤더를 덧붙여(캡슐화) node와 Pod의 IP 정보를 모두 포함시키는 방식으로 이 문제를 해결합니다.

 

오버레이 네트워크는 원본 패킷에 Pod IP와 MAC 주소 등이 포함된 새로운 헤더(Inner Header)를 추가하여 캡슐화합니다. 패킷을 수신한 node는 이 헤더를 제거하는 디캡슐화(Decapsulation) 과정을 통해 내부 헤더를 분석하고, 최종 목적지인 Pod로 패킷을 전달합니다. Cilium은 이 모든 과정을 eBPF를 통해 효율적으로 처리합니다.

 

Cilium은 cilium_vxlan이라는 네트워크 인터페이스와 여기에 연결된 eBPF 프로그램을 사용하여 캡슐화, 디캡슐화, 그리고 라우팅을 수행합니다.

# interface에 연결된 eBPF 프로그램 확인
kubectl exec {cilium daemonset pod} -n kube-system -- bpftool net list dev {interface}

 

cilium_vxlan 네트워크 인터페이스에서 패킷을 덤프하면 Cilium이 생성한 IP 헤더와 VXLAN 헤더를 확인할 수 있습니다.

 

예제 7: 쿠버네티스 Service 통신 확인

쿠버네티스 Service 통신 원리는 앞서 설명한 Pod 간 통신과 매우 유사합니다. Service 통신 역시 eBPF를 기반으로 동작하기 때문입니다. 몇 가지 eBPF 프로그램과 map이 추가되는 것 외에는 기본적인 매커니즘에 큰 차이가 없습니다.

• 쿠버네티스 Service를 이용한 Pod 통신 예시

$ kubectl exec xwing -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing
Ship landed

 

이때는 lb4_services, lb4_backends 등의 eBPF map이 사용되며, 쿠버네티스 Service가 가리키는 Pod IP가 eBPF map에 저장됩니다. eBPF 프로그램은 이 map을 참고하여 라우팅을 수행합니다.

kubectl exec {cilium daemonset pod} -n kube-system -- cilium bpf lb list

 

라우팅 과정에서 목적지 IP는 쿠버네티스 Service IP에서 실제 엔드포인트인 Pod IP로 DNAT(Destination Network Address Translation)됩니다. 또한, 정상적인 응답을 위해 커넥션 트래킹(Connection Tracking) 정보가 필요한데, 이 정보 역시 eBPF map에 저장되어 관리됩니다.

kubectl exec {cilium daemonset pod} -n kube-system -- cilium bpf ct list global

 

Cilium의 Service 로드 밸런싱 알고리즘은 기본적으로 random이며 변경 가능합니다. bpf-lb-algorithm-annotation이 false이면 별도의 로드 밸런싱 알고리즘이 설정되지 않은 것입니다.

cilium config view | grep bpf-lb-algorithm-annotation

 

예제 8: Observability

Cilium의 Observability 기능 또한 eBPF를 기반으로 합니다. 가시성 확보는 Hubble이라는 컴포넌트를 통해 이루어지며, CLI와 Web UI 대시보드 형태로 제공됩니다. 이 기능은 실제 운영 환경에서 경험을 통해 활용 노하우를 쌓는 것이 중요하므로, 본 문서에서는 간단히 소개만 하고 넘어가겠습니다.

 

• CLI

kubectl exec {cilium daemonset pod} -n kube-system -- cilium-dbg monitor

• Web UI 대시보드

$ cilium hubble ui
Opening "http://localhost:12000" in your browser...