[Cilium Study 1기 by Gasida] Cilium - 기본용어정리

Cilium을 위한 용어 정리

스터디 1주차 시작

리눅스 / 네트워크 지식이 많이 부족하다고 느껴졌다. 기본적인 부분을 학습해본다.

eBPF(extended Berkeley Packet Filter)

역사적으로 운영 체제는 전체 시스템을 감독하고 제어할 수 있는 특권적인 능력을 갖추고 있어 관측 가능성(observability), 보안, 네트워킹 기능을 구현하기에 이상적인 장소이다. 동시에, 운영 체제 커널은 그 중심적인 역할과 안정성 및 보안에 대한 높은 요구 사항 때문에 발전시키기가 어려웠다. 따라서 운영 체제 수준에서의 혁신 속도는 전통적으로 운영 체제 외부에서 구현되는 기능에 비해 느렸다. eBPF는 샌드박스화된 프로그램이 운영 체제 내에서 실행되도록 허용하여 애플리케이션 개발자가 런타임에 eBPF 프로그램을 실행하여 운영 체제에 추가 기능을 더할 수 있게 해주었다. JIT컴파일러(Just-In-Time) 와 검증엔진(verification engine)의 도움으로 마치 네이티브 코드로 컴파일된것처럼 안정성과 실행 효율성을 보장해준다.

이로 인해 오늘날 eBPF는 데이터 센터 및 클라우드 네이티브 환경에서 고성능 네트워킹 및 로드밸런싱 제공, 낮은 오버헤드로 세분화된 보안 관측 데이터 추출, 애플리케이션 개발자의 애플레키에션 추적지원, 성능 문제 해결을 위한 통찰력 제공, 예방적 애플리케이션 및 컨테이너 런타임 보안 강화등 다양한 분야에서 혁신이 일어나고 있다.

Routing

Encapsulation

모든 클러스터 노드는 UDP 기반 캡슐화 프로토콜인 VXLAN 또는 Geneve를 사용하여 터널 메시(mesh)를 형성한다. Cilium 노드 간의 모든 트래픽은 캡슐화 된다.

네트워크 요구사항

캡슐화는 일반적인 노드 간 연결에 의존한다. 즉, Cilium 노드들이 이미 서로 통신할 수 있다면 모든 라우팅 요구사항은 이미 충족된 것이다.

• 기본 네트워크는 IPv4를 지원해야함. IPv6 기반 터널링 상태에 대해서는 Github 이슈 17240을 참조
• 기본 네트워크와 방화벽은 캡슐화된 패킷을 허용해야한다.

캡슐화 모드	포트 범위	프로토콜
VXLAN (기본값)	8472	UDP
Geneve	6081	UDP

장점

• 단순성 : 클러스터 노드를 연결하는 네트워크는 파드 CIDR를 인식할 필요가 없다. 클러스터 노드는 여러 라우팅 또는 링크계층 도메인을 생성할 수 있다. 클러스터 노드들이 IP/UDP를 사용하여 서로 통신할 수 있는 한 기본 네트워크의 토폴로지는 중요하지않다
• 주소 공간 : 기본 네트워킹 제약에 의존하지않으므로 사용 가능한 주소공간이 잠재적으로 훨씬 크며, 파드 CIDR 크기가 적절하게 구성되면 노드당 원하는 수의 파드를 실행할 수 있다.
• 자동 구성 : 쿠버네티스와 같은 오케스트레이션 시스템과 함께 실행될 때, 관련된 할당 접두사를 포함한 클러스터의 모든 노드 목록이 각 에이전트에게 자동으로 제공된다. 클러스터에 새로 합류하는 노드는 자동으로 메시에 통합된다.
• ID컨텍스트 : 캡슐화 프로토콜은 네트워크 패킷과 함께 메타데이터를 전달할 수 있다. Cilium은 이 기능을 사용하여 소스 보안 ID와 같은 메타데이터를 전송한다. ID 전송은 원격 노드에서 ID 조회를 한 번 피하기 위해 설계된 최적화임

단점

• MTU 오버헤드 : 캡슐화 헤더를 추가하기 때문에 페이로드에 사용할 수 있는 유효 MTU가 네이티브 라우팅보다 낮다 (VXLAN의 경우 네트워크 패킷당 50바이트). 이로 인해 특정 네트워크 연결의 최대 처리량이 낮아진다. 이는 점보 프레임을 활성화하여 크게 완화할 수 있다. (1500바이트당 50바이트 오버헤드 vs 9000바이트당 50바이트 오버헤드).

구성

• tunnel-protocol : 캡슐화 프로토콜을 vxlan 또는 geneve로 설정한다. 기본값은 vxlan임
• tunnel-port : 캡슐화 프로토콜의 포트를 설정한다. vxlan의 경우 기본값은 8472이고 geneve의 경우 6081이다

네이티브 라우팅

네이티브 라우팅 데이터 경로는 routing-mode: native로 활성화되며 네이티브 패킷 포워팅 모드를 사용한다. 네이티브 패킷 포워딩 모드는 캡슐화를 수행하는 대신 Cilium이 실행되는 네트워크의 라우팅 기능을 활용한다.

네이티브 라우팅 모드에서 Cilium은 다른 로컬 엔드포인트로 향하지 않는 모든 패킷을 리눅스 커널의 라우팅 하위 시스템에 위임한다. 이는 로컬 프로세스가 패킷을 보낸 것처럼 패킹이 라우팅된다는 의미이다 . 결과적으로 클러스터 노드를 연결하는 네트워크는 파드CIDR를 라우팅할 수 있어야한다.

네이티브 라우팅이 구성되면 Cilium은 리눅스 커널에서 자동으로 IP 포워딩을 활성화 한다.

네트워크 요구사항

네이티브 라우팅 모드를 실행하려면 Cilium이 실행되는 호스트를 연결하는 네트워크가 파드나 다른 워크로드에 할당된 주소를 사용하여 IP 트래픽을 포워딩할 수 있어야한다.

1. 노드 자체는 모든 파드 IP를 라우팅하는 방법을 모르지만, 네트워크에 다른 모든 파드에 도달하는 방법을 아는 라우터가 존재한다. 이 시나리오에서 리눅스 노드는 해당 라우터를 가리키는 기본 경로를 포함하도록 구성된다. 이 모델은 클라우드 프로바이더 네트워크 통합에 사용된다.

2. 각 개별 노드는 다른 모든 노드의 모든 파드 IP를 알게 되고, 이를 나타내기 위해 리눅스 커널 라우팅 테이블에 경로가 삽입된다. 모든 노드가 단일 L2 네트워크를 공유하는 경우, auto-direct-node-routes: true 옵션을 활성화하여 처리할 수 있다. 그렇지 않은 경우, BGP 데몬과 같은 추가 시스템 구성 요소를 실행하여 경로를 배포해야 한다.

구성

네이티브 라우팅 모드에서 데이터 경로를 실행하려면 다음 구성 옵션을 설정해야 한다.

routing-mode: native로 네이티브 라우팅 모드가 활성화된다.

ipv4-native-routing-cidr: x.x.x.x/y 네이티브 라우팅을 수행할 수 있는 CIDR을 설정한다.

(옵션)

direct-routing-skip-unreachable: BGP 데몬이 실행 중이고 클러스터 네트워크에 여러 네이티브 서브넷이 있는 경우, direct-routing-skip-unreachable: true를 auto-direct-node-routes와 함께 추가하여 트래픽이 항상 BGP 라우터에 의해 라우팅될 필요 없이 각 존에서 각 노드에 L2 연결성을 제공할 수 있다.

XDP(eXpress Data Path)

XDP는 리눅스 커널 네트워크 드라이버 단에서 동작하는 고성능 패킷 처리 기술.

IP Address Management

IP 주소 관리는 Cilium이 관리하는 네트워크 엔드포인트(컨테이너 및 기타)에서 사용하는 IP주소를 할당하고 관리하는 역할을 함

Feature	k8s Host scope	Cluster Scope	Multi-pool	CRD-backed	AWS ENI	Azure IPAM	GKE
Tunnel Routing	✅	✅	❌	❌	❌	❌	❌
Direct Routing	✅	✅	✅	✅	✅	✅	✅
CIDR Configuration	k8s	cilium	cilium	External	External(AWS)	External(Azure	External(GCP)
Multiple CIDRs per Cluster	❌	✅	✅	N/A	N/A	N/A	N/A
Multiple CIDRs per Node	❌	❌	✅	N/A	N/A	N/A	N/A
Dynamic CIDR/IP allocation	❌	❌	✅	✅	✅	✅	❌

기존 클러스터의 IPAM 모드를 변경하지 말아라. 라이브 환경에서 IPAM 모드를 변경하면 기존의 워크로드의 연결이 지속적으로 중단될 수 있다.
IPAM 모드를 변경하는 가장 안전한 방법은 새 IPAM 구성으로 쿠버네티스 클러스터를 새로 설치하는 것이다.