Cilium
Cilium CNI는 eBPF 프로그래밍 기술을 활용한 고성능 네트워크 솔루션입니다.
eBPF는 Linux OS의 커널단과 같이 권한이 존재하는 Context에서 샌드박스 프로그램을 실행할 수 있는 기술입니다.
iptables vs eBPF
iptables를 eBPF로 전환하는 이유가 무엇일까요?
이는 iptables의 몇가지 단점에서 비롯됩니다.
iptables
첫번째 단점
iptables는 클라이언트가 요청한 사항에 대하여, iptables에 설정된 규칙들을 찾을 때까지 평가합니다.
즉, 컨테이너 환경과 같이 무수한 파드, 서비스가 존재할 수록 iptables의 규칙은 늘어나며, 네트워크 성능이 하락합니다.
두번째 단점
iptables는 규칙 추가 시, iptables의 전체 규칙을 수정해야합니다.
이는 파드, 서비스가 많아질 수록 수정되는 시간이 증가됩니다.
k8s 환경에서, 컨테이너는 빈번하게 배포되고, 사라집니다. 즉, 파드에 할당된 IP 주소또한 매번 달라지기에, 위와 같은 단점들로 인하여 현대 워크로드에서는 지양됩니다.
eBPF
그렇다면, eBPF는 어떤 장점이 있어서 전환되고 있는 것일까요?
바로, 샌드박스 형태의 프로그램이기에 그렇습니다.
샌드박스 형태로 인하여, 파일 및 시스템이 다른 부분에 영향을 끼치지 않습니다.
즉, 커널 소스 코드 변경 및 커널 모듈을 로드할 필요없이 기능을 확장할 수 있는 것입니다.
Cilium CNI는 eBPF 기술을 통한 컨테이너 라우팅을 사용자가 쉽게 적용하도록 합니다.
Cilium의 3가지 기능
cilium은 네트워크, 보안, 관찰 가능성(Observability)와 같이 3가지의 강력한 기능을 제공합니다.
이때, 3가지의 기능을 안정적이게 수행하기 위해서 고안된 4가지의 구성요소가 존재합니다.
4가지 구성요소
- Cilium
- Agent
- 각 노드에서 Daemon으로 실행됨
- k8s 네트워크 정책을 감시하고, 이를 eBPF 프로그램으로 변환 후 커널에 로드
- 네트워크 트래픽 필터링, 라우팅, 로드밸런싱 처리
- CLI
- Operator
- k8s 리소스 감시 및 백그라운드 작업 처리
- IPAM(IP 주소 관리), 서비스 Discovrey, 외부 네트워크 연동 등 제어 루프 역할
- CNI
- Pod 생성 시, 네트워크 인터페이스 설정
- 각 Pod에 고유 IP 할당 및 네트워크 연결
- eBPF 기반의 네트워킹을 활성화하는 진입점
- Hubble
- 네트워크 및 보안에 대한 관찰(Observability) 도구
- 실시간 네트워크 흐름 추적 및 시각화 가능
- eBPF로 수집된 데이터를 L3~L7 수준의 가시성 제공
- eBPF
- 네트워킹 처리 담당
- Data Store
- Agent간에 상태 전파를 위한 데이터 저장소 역할
- CRD(default)
- key-value store
- etcd를 직접 활용하거나, 전용 etcd 클러스터를 유지 관리 하는 것이 가능
cillum 설치시, envoy, operator 등의 컴포넌트들이 설치됨을 확인 가능합니다.
Cilium Network
Cilium은 Overlay(VXLAN) 및 Underlay(Native-routing) 모드를 둘 다 지원합니다.
모드 별 Use case
여러가지 자료들을 취합하여 정리한 VXLAN/Native-routing Use case입니다.
참고용으로 살펴보시면 좋을 것 같습니다.
VXLAN
- 간단한 온프레미스 클러스터
- 노드 간 L3 라우팅이 구성되지 않은 환경
- 예: 개인 랩, 테스트 환경, 초기 PoC 등
- 네트워크 인프라 제어권이 없음
- Pod IP를 외부 네트워크에 숨기고 싶을 때
- VXLAN 캡슐화로 실제 Pod IP는 물리망에 노출되지 않음
- L2 브로드캐스트 충돌 가능성이 적음
- Multicloud/Hybrid 서로 다른 L3 네트워크에 노드가 분산된 경우
- 예: AWS + 온프레미스 하이브리드 클러스터가 VPN이나 터널링으로 연결된 경우
- 공용 IP 없이 VPN 터널 위에서 VXLAN 가능
Native-routing
- 네트워크 성능이 중요한 클러스터
- VXLAN 캡슐화/디캡슐화가 없으므로 CPU 사용량 적고 throughput 향상
- 예: 대규모 데이터 처리 파이프라인, 실시간 서비스
- Bare Metal BGP 같은 외부 라우터와 연동하는 온프레미스 환경
- 예: MetalLB + Cilium, 또는 Calico BGP 대체
- 각 노드의 Pod CIDR을 외부 라우터에 광고
- 간단한 L3 환경 동일 VPC 또는 서브넷에 있는 클러스터 노드
- 예: AWS VPC 내 노드 → 모두 같은 VPC 라우팅 테이블을 공유함
Cilium NIC
Cilium 설치시, 기본적으로 아래 3개의 NIC가 생성됩니다.
이때, cilium_net, cilium_host는 veth 쌍이며, 파드의 게이트웨이 역할을 수행합니다.
Cilium은 파드가 생성되면, lxc 인터페이스를 생성하여 파드에 할당합니다.
해당 인터페이스를 통해 파드는 통신이 가능해지게 됩니다.
- cilium_host
- 호스트의 게이트웨이 역할 수행
- 호스트 네임스페이스에 존재
- cilium_net
- pod와 연결되는 veth 페어의 브릿지 역할
- 즉, lxc 인터페이스가 해당 NIC를 통해 통신됨
- 호스트 네임스페이스에 존재
- 내부 pod간 트래픽이 해당 NIC를 통해 흐름
- pod와 연결되는 veth 페어의 브릿지 역할
Pod NIC 매핑 확인
Cilium은 Pod가 생성되면 자동적으로 lxc NIC를 생성한다고 했었습니다.
정말로 그런지 검증해보도록 하겠습니다.
테스트 파드를 생성합니다.
kubectl run testpod --image=nginx --restart=Never
파드의 ip와 생성된 node 위치를 파악합니다.
kubectl get pod testpod -o wide
파드가 생성된 노드의 할당된 cilium pod를 확인합니다.
- 본인의 경우 worker2
kubectl -n kube-system get pod -l k8s-app=cilium -owide
cilium pod로 접근합니다.
kubectl -n kube-system exec -it cilium-kwtz9 -- bash
파드의 ip와 동일한 엔드포인트 리스트를 확인합니다.
cilium endpoint list
엔드포인트의 정보를 불러옵니다.
-
networking 항목에서 엔드포인트와 연결된 lxc NIC 명 확인 가능
cilium endpoint get <endpoint>
-
worker2 node로 접근하여, lxc NIC를 확인해보니 확인된 정보로 Pod와 매핑됨을 알 수 있습니다.
파드 삭제시,
매핑된 lxc NIC가 삭제됨을 확인 가능합니다.
