Cilium 살펴보기

Cilium 살펴보기

💡 KANS 스터디
CloudNet에서 주관하는 KANS(Kubernetes Advanced Networking Study)으로 쿠버네티스 네트워킹 스터디입니다. 아래의 글은 스터디의 내용을 기반으로 작성했습니다.

스터디에 관심이 있으신 분은 CloudNet Blog를 참고해주세요.

들어가며

이전 포스팅에서 ebpf에 대해 알아봤다. Cilium은 ebpf를 사용하는 CNI이다. CNI는 파드 통신과 IPAM에 대한 책임을 가지는데 여기에서는 Cilium의 기본적인 아키텍처 구조를 살펴보며 어떻게 파드 통신을 지원하는지 알아본다.

Cilium

기존의 리눅스 네트워크 스택도 복잡하며, 앞서 ebpf편에서 살펴봤듯이 기존의 iptables는 여러 단점이 있다. 특히 클러스터의 규모가 커질수록 단점이 부각된다.

Cilium은 이런 문제를 해결하고자 ebpf를 사용하여 Kernel을 커스텀하여 성능과 보안을 잡은 CNI Plugin이다. iptables의 단점을 해결하고자 하니 kube-proxy를 사용하지 않고 Cilium에서 서비스와 관련된 작업도 진행한다. (아직 일부 iptables에 의존하는 동작들은 이슈가 발생할 수 있다고 한다.)

출처: https://isovalent.com/blog/post/migrating-from-metallb-to-cilium/

아키텍처

Cilium을 데몬셋으로 실행하여, eBPF 코드를 관리하여 eBPF를 통해 기존 네트워크 정책, 서비스 관련 정책, 모니터링 등을 진행한다.

출처: https://docs.cilium.io/en/stable/overview/component-overview/

구성요소

• Cilium Agent : 데몬셋으로 실행, 네트워크 관련 설정 및 모니터링 등을 수행하며, eBPF 프로그램을 관리
• Cilium Client (CLI) : Cilium 커멘드툴, eBPF Data(Ring Buff, Maps)에 접속할 수 있다.
• Cilium Operator : K8S 클러스터에 대한 한 번씩 처리해야 하는 작업을 관리, controlplane 역할
• Hubble : 네트워크와 보안 모니터링 플랫폼 역할을 하여, ‘Server, Relay, Client, Graphical UI’ 로 구성
• Data Store : Cilium Agent 간의 상태를 저장하고 전파하는 데이터 저장소, K8S CRDs, Key-Value Store형태로 저장된다.

Traffic Control

• TC(Traffic Control) Ingres/Egress: Network Interface 에 tc ingress hook 에서 BPF programs 실행된다.
  • XDP로 트래픽을 제어하는 것도 가능하다. 참고자료
• Endpoint Policy: 정책에 따라 패킷을 차단/전달하거나, 서비스로 전달하거나, L7 정책 전달 할 수 있다.
• Service 관련: 모든 패킷의 목적지 IP/Port 의 map 조회 시 일치하면 L3/L4 endpoint 로 전달하며, Service block 는 모든 인터페이스의 TC ingress hook 에서 동작할 수 있다.
• L7: L7도 지원하며, L7 정책 처리를 위해 내부적으로는 envoy를 사용한다. 그렇기에 네트워크 스택 아랫단에서 처리하지 못하고 userspace에서 처리한다

출처: https://static.sched.com/hosted_files/kccncna19/1a/Liberating k8s from kube-proxy and iptables.pdf

통신

파드 통신

L3/L4 정책을 통해 트래픽을 제어한다. 이후 허용되면 TCP 핸드쉐이크 과정을 진행하는데, 이때 소켓 계층 정책을 통해 연결 여부를 결정한다. 덕분에 소켓 Layer에서 추가적인 정책검사가 필요하지 않는다. 만약 TCP 연결이 진행(ESTABLISHED)되면 L7 정책을 확인한다. 한번 연결을 맺고, L7 정책이 없다면 빠르게 라우팅된다. (TCP Accelerated Path)

Egress

Overlay 네트워크와 L3 암호화는 선택적이며, 진행시 추가적인 작업이 일어난다. Overlay 인터페이스의 기본값은 cilum_vxlan이다. 소켓 정책과 L7 프록시를 사용하면 정책 검사를 진행하지 않고 바로 외부로 나갈 수 있다.(L3 encryption off 일때)

Ingress

외부에서 트래픽이 들어오는 경우에도 유사하다. Proxy와 Socket 정책 적용을 통해 여러 과정을 건너뛰고 바로 엔드포인트로 라우팅이 가능하다.

Load Balancing

Cilium에서 서비스(ClusterIP type)에 대해 통신할 때 로드밸런싱이 이뤄지는 방식은 네트워크 기반 로드밸런싱, 소켓 기반 로드밸런싱 2가지로 나뉜다. 잘 정리해주신 블로그 포스팅

출처: https://cilium.io/blog/2019/08/20/cilium-16/

아래는 해당 블로그의 글이다.

“소켓 기반 로드 밸런싱은 클라이언트와 네트워크 기반 로드 밸런싱의 장점을 결합하여 애플리케이션 투명성을 유지하면서, 연결 설정 시점에만 주소를 변환하여 로드 밸런싱 비용을 줄인다. 즉, 애플리케이션이 백엔드와 직접 통신하는 것처럼 성능이 유지되며, 이후 추가 변환 없이 효율적인 데이터 전송이 가능함.”

Observability

은 Cilium에서 만든 eBPF 기반 네트워크/보안 모니터링 플랫폼이다. eBPF 기반이기에 이전에는 불가능했던 Kernel 단까지 세밀하게 확인이 가능하며 성능에도 영향이 적다.

출처: https://github.com/cilium/hubble

아래는 Service MAP 예시 사진이며, Hubble CLI를 통해 네트워크 Flow에 대한 정보를 얻을 수 있다. 가령, 네트워크 정책 거부 확인, 개별 TCP 연결이나 HTTP 요청 혹은 Kafka 통신에 대한 Connection이나 지연시간 Response를 얻을 수 있다.

예시) Denied connection attempt

starwars/enterprise-5775b56c4b-thtwl:37800   starwars/deathstar-695d8f7ddc-lvj84:80(http)   Policy denied (L3)   TCP Flags: SYN
starwars/enterprise-5775b56c4b-thtwl:37800   starwars/deathstar-695d8f7ddc-lvj84:80(http)   Policy denied (L3)   TCP Flags: SYN
starwars/enterprise-5775b56c4b-thtwl:37800   starwars/deathstar-695d8f7ddc-lvj84:80(http)   Policy denied (L3)   TCP Flags: SYN

네트워크 관련 Metrics & 모니터링도 제공한다.)

출처: https://docs.cilium.io/en/stable/observability/hubble/hubble-ui/index.html

참고자료: https://cilium.io/blog/2019/11/19/announcing-hubble/, https://github.com/cilium/hubble?tab=readme-ov-file

마치며

Cilium은 eBPF를 사용하여 Kernel을 커스텀하여 보안과 성능을 확보한 CNI이다. Linux 네트워크 스택을 우회하여 성능을 확보했으며 엔드포인트 연결시 TCP 핸드쉐이크시 Socket 기반 정책을 적용하며, L7 Proxy를 적용하면 TCP 가속이 가능하도록 커스텀하였다. 이제 다음 포스팅에서는 앞서 알아본 Cilium의 구조를 실습을 통해 확인해본다.