cilium
Cilium은 현대의 분산 애플리케이션을 위한 차세대 네트워킹 및 보안 솔루션이다.
cilium 배경
현재 cilium은 kube-proxy를 완전히 대체할 수 있는 네트워크 오픈소스로 제대로 구성하면 cilium CNI를 사용하고 kube-proxy를 비활성화한 상태로 사용할 수 있다.
How??
cilium은 iptables을 이용한 쿠버네티스 트래픽 라우팅의 단점을 보완하여 네트워크 성능을 높히고자 하는 목적을 갖고있다.
iptables를 기반으로 IP/PORT 기반의 전통적인 포워딩 기술은 오랫동안 널리 사용되었고 퍼블릿/프라이빗 클라우드 제품군들 모두 iptables 기반의 Security Group등을 기본으로 제공하고 있고 쿠버네티스마저도 CNI 핵심으로 iptables를 활용하고 있다.
하지만 동적으로 변화하고 복잡한 마이크로서비스를 사용하는 시대에 전통적인 방식의 IP/PORT 관리는 비효율적인 측면이 많다.
사진에서 볼 수 있듯 네트워킹 스택에서 iptables를 우회하고 커널 단에서 네트워킹 처리하여 빠르다.
- iptables conntrack overhead : 네트워크 연결 상태를 추적해 보안과 세션 관리를 용이하게 하지만, 많은 연결을 추적할 때 시스템 자원을 많이 소모할 수 있습니다. 이로 인해 메모리와 CPU 사용이 증가하고, 네트워크 지연이 발생할 수 있습니다.
- iptables overhead : 패킷을 규칙과 일치시키는 과정에서 발생하는 CPU와 메모리 사용의 추가적인 부담을 말합니다. 특히 규칙이 많거나 연결 추적을 사용하면 오버헤드가 증가할 수 있습니다.
- Context-switch overhead :CPU가 여러 프로세스 간에 작업을 전환할 때 발생하는 성능 손실입니다. 작업 전환이 많아질수록 실제 연산 시간보다 전환에 소요되는 시간이 늘어나 시스템 성능이 떨어질 수 있습니다.
IPTables 방식의 단점
IPTables는 네트워크 패킷이 들어오고 나가는 경로에 따라 다양한 규칙을 설정할 수 있습니다.
하지만 이 규칙들이 매우 구체적이고 세부적이어서 관리가 어려울 수 있습니다.
또한, 규칙을 추가하고 수정하는 과정이 복잡할 수 있습니다.
많은 규칙이 설정된 경우, 네트워크 트래픽이 들어오고 나갈 때마다 그 규칙들을 일일이 검사해야 합니다.
규칙이 많아질수록 시스템의 성능이 떨어질 수 있습니다. 특히 대규모 네트워크 환경에서는 성능 저하가 눈에 띌 수 있습니다.
cilium은 iptables 대신 ebpf 맵에서 파드 엔드포인트를 추적한다.
cilium은 네트워크 뿐만 아니라 모니터링/보안 기능도 제공함으로써 쿠버네티스로 서비스를 운영할 도구의 수를 줄여 운영을 단순화하는 것을 목표로 한다.
즉, Cilium은 eBPF라는 강력한 기술을 기반으로 하여 기존 오버레이 네트워크 없이 리눅스 커널 내에서 직접 고급 네트워킹, 보안 및 로그 밸런싱 기능을 수행할 수 있다.
eBPF (Berkeley Packet Filter)
“효율적인 네트워킹, 가시성, 추적, 보안을 위해 커널을 동적으로 프로그래밍한다."
BPF(1992년) 를 확장해서 eBPF가 (2014년, Alexei Starovoitov) 가 나왔고, eBPF 를 다양한 영역 (보안, 추적, 네트워킹, 모니터링)에서 활용하기 시작하였습니다.
eBPF는 리눅스 커널 안에 내장된 작은 가상 머신으로,
특정 이벤트가 발생할 때 실행되는 프로그램을 커널에 적재하여 커널의 동작을 자유롭게 커스터마이징할 수 있게 합니다.
eBPF는 Linux 커널 내부에서 직접 동작하는 방식으로, 네트워크 프로그래밍에 효율성을 높였습니다.
기존의 유저 공간 네트워킹과 달리, eBPF는 커널에서 완전히 처리되므로 애플리케이션이 소켓 계층을 거치지 않아도 됩니다.
BPF
BPF는 1992년 버클리 대학에서 개발된 기술로, 네트워크 트래픽을 분석하고 필터링하는 데 사용됩니다
- 패킷 필터링:
BPF는 네트워크 트래픽에서 원하는 패킷을 고속으로 필터링할 수 있도록 설계되었습니다.
BPF는 패킷을 커널에서 처리하기 전에 필터링하여, 불필요한 패킷을 애플리케이션에 전달하지 않음으로써 시스템 리소스를 절약합니다.- 효율성:
BPF는 매우 경량화된 필터링 시스템입니다.
패킷을 처리할 때, 커널 내부에서 직접 실행되기 때문에 성능 저하가 거의 없고, 불필요한 복잡한 연산 없이 필요한 패킷만 추려냅니다.- 유연성:
BPF는 매우 유연한 구조를 가지고 있어, 사용자 정의 필터링 규칙을 쉽게 작성할 수 있습니다.
"eBPF는 커널 소스 코드를 변경하거나 커널 모듈을 로드하지 않고도 리눅스 커널에서 샌드박스된 프로그램을 실행할 수 있는 혁신적인 기술입니다."
cilium 구조
cilium 구성요소
Cilium은 여러 구성 요소가 함께 작동하여 네트워킹과 보안 기능을 수행합니다.
Agent
각 노드에 배포되며, Kubernetes API 서버와 통신합니다.
Cilium Agent는 eBPF 프로그램을 로드하고, 파드의 네트워크 트래픽을 처리하며, 네트워크 정책을 시행합니다.
DaemonSet으로 배포되어 노드마다 하나씩 실행됩니다.
eBPF 프로그램
Cilium은 eBPF를 사용하여 패킷 필터링, 라우팅, 트래픽 모니터링 등 다양한 네트워킹 기능을 수행합니다.
eBPF 프로그램은 커널 수준에서 실행되기 때문에 성능이 뛰어나고, 네트워크 트래픽을 매우 세밀하게 제어할 수 있습니다.
Cilium CNI 플러그인
Cilium은 Kubernetes의 CNI 플러그인으로서, 파드가 생성될 때 네트워크를 설정하고 IP 주소를 할당합니다.
또한, 새로운 파드가 생성되거나 삭제될 때 Cilium은 이를 감지하고 네트워크 구성을 업데이트합니다.
네트워크 정책
관리자는 Cilium을 통해 네트워크 정책을 정의할 수 있습니다.
예를 들어, 특정 파드 간의 트래픽을 허용하거나 차단하는 규칙을 설정할 수 있습니다.
Cilium은 이러한 정책을 eBPF 프로그램으로 변환하여 커널에서 직접 실행합니다.
Envoy 프록시 (선택 사항)
L7 규칙(애플리케이션 계층 프로토콜에 대한 규칙)을 사용하는 경우, Cilium은 Envoy 프록시를 사용하여 HTTP 트래픽을 관리합니다.
Envoy는 요청을 라우팅하고, 로드 밸런싱을 수행하며, 모니터링 및 로깅 기능을 제공합니다.
동작 방식
Cilium 에이전트는 데몬셋으로 배포되며, 이는 클러스터 노드당 하나의 에이전트 인스턴스가 있다는 것을 의미합니다.
에이전트 포드는 API 서비스와 통신하고 Linux 커널과 상호 작용하여 eBPF 프로그램을 로드하고 eBPF 맵을 업데이트합니다.
또한 Cilium CNI 플러그인에 연결하여 대화하므로 새로운 워크로드가 예약될 때마다 알림을 받습니다.
또한 CiliumNetworkPolicy가 L7 규칙을 사용할 때 Envoy 프록시 인스턴스를 시작합니다.
에이전트는 또한 클러스터 전체에 대한 통합 가시성을 위해 Hubble 릴레이가 연결할 수 있는 gRPC 서비스를 제공합니다.
cilium IP 주소 할당
IP 주소 할당
Cilium은 애플리케이션 컨테이너에 IP 주소를 할당하여 네트워크에서 접근할 수 있도록 합니다.
여러 개의 애플리케이션 컨테이너가 동일한 IP 주소를 공유할 수 있습니다.
여러 컨테이너가 같은 IP 주소를 사용할 때, Cilium에서는 이를 엔드포인트(endpoint) 라고 부릅니다. 엔드포인트는 같은 IP 주소를 가진 컨테이너 그룹을 나타냅니다.
포트 범위 사용
각 엔드포인트에 개별 IP 주소를 할당하면, 각 포드가 Layer 4 포트 범위의 모든 포트를 사용할 수 있습니다.
즉, 동일한 클러스터 노드에서 실행 중인 여러 애플리케이션 컨테이너가 80번 포트와 같은 잘 알려진 포트에 동시에 바인딩(연결)할 수 있으며, 이는 충돌을 피하는 데 도움을 줍니다.
IP 주소 관리(IPAM)
Cilium은 IP 주소 할당 및 관리를 위해 IP 주소 관리(IPAM) 기능을 제공합니다.
cilium_net 과 cilium_host
cilium_net
cilium_net는 Cilium이 관리하는 가상 네트워크 인터페이스입니다. (IPv6)
이 인터페이스는 Cilium의 eBPF 프로그램을 통해 네트워크 트래픽을 처리하고 제어합니다.
Cilium은 Pod 간의 통신을 관리하기 위해 cilium_net 인터페이스를 사용합니다.
이를 통해 Cilium은 보안 정책을 적용하고, 패킷을 필터링하며, 네트워크 성능을 최적화할 수 있습니다.
cilium_net 인터페이스는 각 Pod에 대해 생성되며, Pod의 IP 주소와 연결됩니다.
이 인터페이스는 eBPF 프로그램이 패킷을 검사하고 처리할 수 있도록 해줍니다.
따라서 Cilium은 커널 레벨에서 패킷을 효율적으로 처리할 수 있습니다.
cilium_host
cilium_host는 Cilium이 관리하는 호스트 네트워크 인터페이스입니다. (IPv4)
이 인터페이스는 클러스터 내의 Pod와 외부 네트워크 간의 연결을 처리합니다.
cilium_host는 Cilium이 Pod에서 나가는 트래픽과 외부에서 들어오는 트래픽을 처리하는 데 사용됩니다.
즉, Pod가 외부 네트워크와 통신할 때 이 인터페이스를 통해 이루어집니다.
이 인터페이스는 외부에서 들어오는 요청을 적절한 Pod로 전달하는 Reverse NAT 기능을 포함합니다.
cilium_host는 Cilium이 클러스터 내의 Pod와 외부 네트워크 간의 통신을 관리하기 위해 필수적인 역할을 합니다. 이를 통해 Cilium은 네트워크 정책을 적용하고, 외부와의 안전한 연결을 유지할 수 있습니다.
(⎈|CiliumLab:N/A) root@k8s-s:~# ip -br -c link
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
ens5 UP 02:ca:b4:99:6a:93 <BROADCAST,MULTICAST,UP,LOWER_UP>
cilium_net@cilium_host UP 9e:49:6a:bb:a4:d7 <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP>
cilium_host@cilium_net UP 4a:69:bb:d6:61:c6 <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP>
lxc_health@if7 UP be:40:78:dd:72:24 <BROADCAST,MULTICAST,UP,LOWER_UP>
(⎈|CiliumLab:N/A) root@k8s-s:~# ip -br -c addr
lo UNKNOWN 127.0.0.1/8 ::1/128
ens5 UP 192.168.10.10/24 metric 100 fe80::ca:b4ff:fe99:6a93/64
cilium_net@cilium_host UP fe80::9c49:6aff:febb:a4d7/64
cilium_host@cilium_net UP 172.16.0.12/32 fe80::4869:bbff:fed6:61c6/64
lxc_health@if7 UP fe80::bc40:78ff:fedd:7224/64Hubble
cilium에서 제공하는 모니터링 도구이다.
ebpf를 활용하면 가시성을 프로그래밍할 수 있으며 Hubble은 ebpf 성능을 최대한 활용하도록 설계되었다.
Hubble을 사용하면 L3/L4 및 심지어 L7에서도 쿠버네티스 클러스터에 대한 서비스 종속성 그래프를 손쉽게 볼 수 있다.
cilium 및 ebpf를 기반으로 구축되어 완전히 투명한 방식으로 네트워킹 인프라는 물론 서비스의 통신 및 동작에 대한 깊은 가시성을 제공한다.
Hubble로 파악할 수 있는 점
- service dependencies & communication map
어떤 서비스가 서로 통신하고 있나요?
얼마나 자주 통신하고 있나요? 서비스 종속성 그래프는 어떤 모양인가요?
어떤 HTTP 호출이 이루어지나요?
서비스는 어떤 kafka 토픽을 consume 하거나 produce 하나요? - network monitoring & alerting
네트워크 통신이 실패하나요? 왜 실패하나요? DNS 때문인가요?
애플리케이션 문제인가요 네트워크 문제인가요?
통신이 레이어4(TCP)에서 끊어지나요 7(HTTP)에서 끊어지나요?
지난 5분 동안 어떤 서비스에서 DNS 확인 문제가 발생했나요?
최근에 TCP 연결이 중단되었거나 연결 시간이 초과된 서비스는 무엇인가요?
응답되지 않는 TCP SYN 요청의 비율은 얼마인가요? - application monitoring
특정 서비스 또는 모든 클러스터에 대한 5xx 또는 4xx HTTP 응답 코드 비율은 얼마나 되나요?
어떤 서비스의 성능이 가장 낮나요? 두 서비스 간의 대기 시간은 얼마나 되나요? - security observability
네트워크 정책으로 인해 연결이 차단된 서비스는 무엇인가요?
클러스터 외부에서 어떤 서비스에 접근했나요?
어떤 서비스가 특정 DNS 이름을 확인했나요?
Cilium은 쿠버네티스 CNI 종류 중 하나로 알려져있지만 단순 네트워크 역할만 하지 않는다.
네트워크, 보안, 모니터링 영역에서 다양한 기능을 제공하는데 어떤게 있는지 알아보자.
High Performance Networking (CNI)
쿠버네티스에서 사용할 수 있는 CNI는 수십개가 있지만 기능, 규모, 성능은 크게 다르다.
이들 중 다수는 쿠버네티스 환경의 규모와 변동을 처리할 수 없는 레거시기술(iptables)에 의존하여 대기 시간이 늘어나고 처리량이 감소한다.
또한 대부분의 CNI는 L3/L4 네트워크 정책만 지원하고 그 이상은 거의 제공하지 않는다.
cilium은 수백, 수천 개의 컨테이너가 몇 초 내에 생성되고 파괴되는 대규모의 매우 동적인 클라우드 네이티브 환경을 위해 만들어졌다.
cilium은 ebpf를 사용하여 대규모 iptables 규칙의 함정을 피한다.
ebpf 기반 네트워킹은 대규모 작업에 최적화되어있으며 네트워크 병목 현상에 대해 걱정하지 않고 운영을 확장할 수 있다.
kube-proxy 대체
iptables와 netfilter는 서비스 추상화를 구현하기 위한 kube-proxy의 두 가지 기본 기술이다.
클라우드 네이티브 시대에는 특히 성능, 안정성, 확장성이 중요한 만큼 해당 도구들은 더 이상 가장 적합한 도구가 아니다.
kube-proxy를 cilium으로 전환하는 것은 매우 쉽다.
cilium은 Kubernetes API와 완벽하게 호환되는 쿠버네티스 네이티브 구현을 제공하기 때문에 kube-proxy를 cilium으로 교체하는 것은 간단한 프로세스이다.
cluster mesh
Cilium Cluster Mesh를 사용하면 모든 클러스터가 Cilium을 CNI로 실행할 경우,
파드가 다른 클러스터에 있는 서비스를 검색하고 접근할 수 있도록 네트워크를 연결할 수 있다.
Cluster Mesh는 여러 쿠버네티스 클러스터에 걸쳐 파드 ip 라우팅을 처리할 수 있다.
이를 통해 파드는 클러스터 간에 원활하게 통신할 수 있어 마이크로서비스 아키텍처의 전반적인 효율성이 향상된다.
Cluster Mesh를 사용하면 모든 클러스터 간에 시크릿 관리, 로깅, 모니터링, DNS와 같은 서비스를 공유할 수 있다.
이는 운영 오버헤드를 줄이고 관리를 단순화하며 테넌트 클러스터 간의 격리를 유지한다.
BGP
cilium은 BGP 성능을 증폭시켜 클라우드 환경에서 확장 가능하고 안전한 고속 라우팅을 제공한다.
cilium의 BGP 지원은 기존 네트워킹 인프라와 간단하고 쉽게 통합되도록 설계되었다.
cilium은 BGP 없이도 ebpf와 리눅스 라우팅 테이블을 통해 클러스터 내에서 효율적인 네트워크 트래픽 라우팅을 수행할 수 있다.
BGP는 대규모 또는 멀티클러스터 환경에서 경로 관리를 더 잘하기 위해 사용되며, cilium은 기본적으로 클러스터 내부의 라우팅을 처리하는 데 있어서 BGP 없이도 충분히 성능을 발휘할 수 있다.
service mesh
기존 서비스메시는 장점에도 불구하고 심각한 문제를 야기할 수 있다.
IP 및 포트 기반 네트워크 정책의 복잡성과 오류 발생 가능성, 프록시 기반 아키텍처로 인한 성능 오버헤드, 서비스 간 통신의 제한된 가시성, 기존 인프라와의 상호 운영성 문제, 서비스 수 및 트래픽 볼륨 증가에 따른 확장성 문제, 운영 및 리소스 오버헤드 등.
Cilium Service Mesh는 eBPF를 사용하여 메시 계층을 커널에서 직접 통신함으로써 사이드카 프록시가 필요하지 않도록 하여 기존 서비스메시 프레임워크를 재정의한다.
또한 네트워킹 및 애플리케이션 프로토콜 계층 모두에서 연결을 관리하고 IP, TCP, UDP, HTTP, Kafka, gRPC 및 DNS와 같은 프로토콜을 보다 효율적으로 처리한다.
ebpf를 사용함으로써 기존 프록시의 성능 단점을 우회하여 서비스 간의 직접적이고 효율적인 통신을 가능하게 한다.
service Map
클라우드 네이티브 환경의 문제를 해결할 때 문제는 네트워크, 환경, 종속성 계층 사이에 숨어 있을 수 있다.
예를 들어, DNS가 제대로 작동하는지, 정책 관련 문제로 애플리케이션이 실패하는지, 트래픽이 어디서 차단되는지 등의 문제를 확인하기 어려울 수 있지만 이런 문제 해결을 위해 로그를 검토하는 것은 어렵고 시간이 많이 걸리는 프로세스일 수 있다.
ebpf를 사용하면 모든 가시성을 프로그래밍할 수 있으며 깊고 상세한 가시성을 제공하는 동시에 오버헤드를 최소화하는 동적 접근 방식이 가능하다.
단순히 kubectl get pods를 보는 것 만으로는 각 서비스나 외부 API 또는 데이터베이스 간의 종속성을 나타내지 않는다.
Hubble은 L3/L4 및 L7 수준에서 쿠버네티스 클러스터 내의 서비스 종속성을 손쉽게 자동으로 제공한다.
이를 통해 사용자 친화적인 시각화 및 데이터 흐름 필터링이 Service Map으로 가능해지며 서비스 종속성을 쉽게 관리할 수 있다.
Metrics & Tracing Export
cilium의 metric/trace export 기능은 사용자가 쿠버네티스 환경을 쉽게 모니터링하고, 분석하고, 최적화할 수 있도록 지원하는 통합된 솔루션을 제공한다.
cilium을 통해 사용자는 애플리케이션과 네트워크에 대한 깊이있는 가시성을 확보할 수 있으며 설정 및 구성 과정도 간소화할 수 있다.
또한 cilium은 Jaeger, Zipkin, OpenTelemetry와 같은 다양한 추적 시스템과 통합되어 분산 추적 기능을 제공한다.
cilium은 성능 저하 없이 대용량 데이터를 처리하도록 최적화되어있다.
cilium은 애플리케이션의 대기시간, 요청비율, 오류비율을 포함한 다양한 메트릭을 캡처한다.
이러한 메트릭은 기존 모니터링 및 시각화 도구와 쉽게 통합되어 네트워크 성능을 실시간으로 추적할 수 있다.
