[DevOps] Cilium 이란?

Cilium은 무엇인가?

cillim이란?

Cilium을 간단히 설명하면 BPF (Berkeley Packet Filter) 를 기반으로 Pod Network를 구축하는 CNI Plugin입니다. 좀더 자세하게 공식문서에서는 Cilium을 아래와 같이 설명하고 있습니다.

Cilium은 Linux 컨테이너 관리 플랫폼을(Docker, Kubernetes) 사용하여 배포된 애플리케이션 서비스 간 네트워크 연결을 보호하는 오픈 소스 소프트웨어입니다. Cilium의 기반에는 eBPF라는 Linux 커널 기술이 사용되었습니다. 이를 통해 Linux 자체에 강력한 보안 가시성(Security visibility)과 제어 로직을 동적으로 입력할 수 있습니다. eBPF는 Linux 커널 내에서 실행되기 때문에 애플리케이션 코드나 컨테이너 구성을 변경하지 않고도 Cilium 보안 정책을 적용하고 업데이트할 수 있습니다.

Cilium은 공식문서 소개 글에서 “linux eBPF를 이용한 고성능 네트워킹 솔루션입니다” 라고 소개하고 있습니다. Cilium은 iptables을 이용한 쿠버네티스 트래픽 라우팅의 단점을 보완하여 네트워크 성능을 높히고자하는 목적을 갖고 있기 때문이죠.

iptables을 기반으로 IP와 Port기반의 전통적인 포워딩 기술은 20년이라는 세월동안 널리 사용되어 왔습니다. 특히 퍼블릭/프라이빗 클라우드 제품군들 모두 iptables기반의 Security Group등을 기본으로 제공하고 있고 Kubernetes 마저도 CNI 핵심으로 iptables을 활용하고 있습니다.

하지만 동적으로 변화하고 매우 복잡한 마이크로서비스를 사용하는 시대에 전통적인 방식의 IP, Port관리는 비효율적인 측면이 많습니다.

cilium 사전 뜻??

개인적으로 특정 서비스명의 본연의 뜻을 확인하는 편입니다. 그 뜻을 확인해보면 최초 개발자가 어떤 철학을 갖고 이 서비스를 만들었는지 조금이라도 이해할 수 있게 되는 것 같습니다. “Cilium”을 단어사전에 검색하면 '섬모', '속눈썹'등의 단어가 나옵니다. Cilium을 차근히 보다보니 OS내부(리눅스 커널)에서부터 컨테이너간 또는 외부와의 연결을 보호하는 역할이라고 하니 어느정도 이해가 되는 것 같습니다.

cilium 출시일?

Cilium은 Dockercon 2017에서 최초 발표 하였고 2018년 4월 24일에 1.0이 정식 Release 되었습니다. 현재 22년 8월 기준 1.12.0이 최신버전입니다. (realease 정보 : https://github.com/cilium/cilium/releases )

• Dockercon은 Doker inc. 와 Docker community 에서 2014년 처음 시작한 도커 콘퍼런스 입니다.

iptables 의 단점

Kubernetes Cluster 내부 또는 외부에서 접근하고자 하는 Application에 대해 접근을 위해서는 Endpoint가 필요한데, 이러한 Endpoint를 제공하는 것이 Kubernetes의 Service 라는 Object가 제공합니다. Kubernetes Cluster 상에 배포한 Application에 대한 Endpoint를 제공하기 위해 Service를 구성하는 방식은 일반적으로 ClusterIP 또는 NodePort 등을 사용하게 됩니다.

앞서 언급한 Service 유형들은 실제 요청이 Endpoint로 전달되었을 때, 요청에 대한 Target Pod로 Routing 하기 위해서 각 Node에 배포 되어 있는 kube-proxy가 이를 대신 수행합니다. 즉, kube-proxy가 생성한 iptables를 기반으로 동작한다는 것이 맞겠죠.

Service가 생성되면 해당 Service에 대한 Targer Backend로의 분산을 위한 iptables Chain 및 규칙이 생성되는데 이러한 iptables의 규칙을 생성하고 배포하는 것을 kube-proxy가 담당합니다.

kube-proxy가 열일을 해주는 덕분에 Service를 생성하고 운영하는데 추가 노력이 들지 않습니다만, Service가 더 많은 환경에서는 이러한 iptables 기반의 환경은 잠재적으로 다양한 문제를 야기 할 수 있습니다.

iptables 기반의 환경에서 문제가 될 수 있는 문제 중 대표적인 몇 가지는 다음과 같습니다.

• Performance

사용자에게 서비스를 제공할 때, 가장 중요한 부분인 Latency 입니다.

사용자에게 보다 낮은 지연으로 서비스를 제공하기 위해 CDN도 사용하는 만큼 서비스를 평가 할 때 중요하게 판단되는 요소 중 인데요. iptables 기반의 환경의 가장 큰 문제점은 iptables의 수가 많아지는 만큼 Delay가 발생한다는 점 입니다. iptables는 Packet이 iptables의 규칙에 일치할 때까지 모든 규칙을 평가 하게 되는데 이러한 규칙이 많아 질수록 전달되는 시간과 처리 시간이 그만큼 지연됩니다.

• Time

또한, iptables의 가장 큰 단점은 "Incremental Update"를 지원하지 않는 다는 점 입니다. 따라서 새로운 Service가 생성 되면서 추가되는 규칙을 적용하기 위해서 전체 iptables list를 교체 해야 합니다. 예를 들어, 5000개의 Service(40,000개의 규칙)가 있고 하나의 Rule을 추가하는데 11분 정도가 소요됩니다. Service를 생성하면 기본적으로 생성되는 규칙이 Service의 수만큼 늘어나기 때문에 많은 Service를 제공하는 환경에서는 적합하지 않습니다.

• Operations

사용자에게 Service를 제공하기 위해 여러가지 옵션들을 고민하면서 운영적인 측면을 빼놓을 수는 없습니다.

안정적인 Service를 제공하기 위해서는 실제 구성된 환경을 잘 이해해야 하는데, Service가 증가하면서 기하급수적으로 늘어나는 iptables의 규칙을 모두 이해하기는 거의 불가능에 가깝습니다.

위에서 설명 드린 것처럼 iptables 기반의 환경은 모든 트래픽 처리를 iptables에 의존하기 때문에 발생하는 문제입니다. 그럼 다음에서 iptables가 어떻게 동작하는지에 대해 살펴보도록 하겠습니다.

cilium 구성요소

cilium은 크게 4가지 구성요소가 있습니다.

1. Cilium
   • agent: Cilium을 실행하기 위한 네트워크 정책, 설정 등을 수행합니다. 쿠버네티스에서는 데몬셋으로 실행되어 각 노드마다 pod로 실행되고 API서버를 이용하여 작업을 수행합니다.
   • client: Cilium 명령어(CLI)를 실행하기 위한 클라이언트 입니다.
   • operator: 쿠버네티스 클러스터에 전체에 한번씩 수행되어야 하는 작업을 담당합니다.
2. Hubble: 네트워크와 보안 모니터링 역할을 수행하며 server, relay, client, graphical UI로 구성되어 있습니다.
3. eBPF: 네트워킹 처리를 담당합니다.
4. Data Source(etcd): 각 노드간 실행하고 있는 cilium agent상태를 동기화 하기 위한 데이터를 저장합니다.

cilium의 네트워크 모드

2022년 2월 기준 터널모드(VXLAN, GENEVE), native routing 총 2가지 네트워크 모드를 지원합니다.

cilium의 IPAM mode

IPAM 은 ip할당 및 관리를 담당하며 아래와 같이 다양한 모드를 지원합니다.

• Cluster Scope (Default)
• Kubernetes Host Scope
• Azure IPAM
• AWS ENI
• Google Kubernetes Engine
• CRD-Backed
• Technical Deep Dive

cilium 동작방식

Cilium은 eBPF 기반 네트워킹을 지원하는 CNI로 현재 가장 널리 알려져 있습니다. Cilium은 eBPF를 기반으로 Networking, Security, Observability, Tracing을 제공하며 Google GKE, AWS EKS 등 다양한 퍼블릭 클라우드에서도 Container 기반 네트워킹을 Cilium을 사용할 정도로 가장 빠른 발전을 하고 있습니다.

Cilium에서 eBPF 동작을 설명하기에 앞서 기본적인 Datapath는 다음과 같습니다.

Endpoint to Endpoint

https://docs.cilium.io/en/stable/_images/cilium_bpf_endpoint.svg

기본적인 설명에 앞서, 각 Box의 색깔 분류는 다음과 같습니다.

• 빨간 Box : Kernel Hook point
• 녹색 Box : Network device components
• 노란 Box : Cilium Components

Endpoint 간 통신이 발생하면 좌측A Endpoint부터 우측 B Endpoint까지의 Datapath는 다음과 같습니다.

• A Endpoint가 B Endpoint와 TCP 통신을 하는 경우, 기본적으로 TC egress Hook을 트리거
• TC(Traffic Control) ingress Hook은 eBPF 프로그램을 실행 ("bpf_lxc")
• (Optional) L7 Policy를 설정한 경우 :
• Userspace의 Proxy로 전달을 위해 Network Stack으로 전달 (L7 Proxy를 사용하는 경우, iptables를 사용)
• B Endpoint에 Packet이 도달하면 TC ingress Hook이 트리거
• B Endpoint에 수신 되기 전에 TC Ingress Hook이 트리거 되어 eBPF 프로그램 실행 ("bpf_lxc")

출처

eBPF Basic : https://m.blog.naver.com/PostView.naver? blogId=kangdorr&logNo=222593265958&navType=by
Cilium 누구냐 넌? : https://ddii.dev/kubernetes/cilium-1/
Cilium CNI 등장배경 : https://malwareanalysis.tistory.com/288
Cilium CNI pod 통신 : https://malwareanalysis.tistory.com/290
AWS EKS에 Cilium CNI 설치하기 : https://isn-t.tistory.com/42
'eBPF부터 오픈소스까지' 2022년 '관찰가능성' 주요 트렌드 5가지: https://www.itworld.co.kr/news/223914