CloudNet 가시다님이 진행하는 KANS 스터디 8주차 정리입니다.
실습 환경 구성
1. Cilium 소개
1.1 BPF/eBPF 소개
▶ Linux Network Stack : 리눅스 네트워크 스택의 단점은 복잡하고, 변경에 시간이 걸리고, 레이어를 건너뛰기 어렵다
▶ IPtables 단점
- IPtables updates must be made by recreating and updating all rules in a single transaction.
- Implements chains of rules as a linked list, so all operations are O(n).
- The standard practice of implementing access control lists (ACLs) as implemented by iptables was to use sequential list of rules.
- It's based on matching IPs and ports, not aware about L7 protocols.
- Every time you have a new IP or port to match, rules need to be added and the chain changed.
- Has high consumption of resources on Kubernetes.
Kuberntes uses iptables for..
- kube-proxy - the component which implements Services and load balancing by DNAT iptables rules
- the most of CNI plugins are using iptables for Network Policies
▶ BPF(Berkeley Packet Filter) kernel hooks : BPF는 커널에 삽입하여 패킷을 통제(필터링) 할 수 있으며, 다양한 영역에서 Hook을 통해서 접근 할 수 있습니다.
▶ extended Berkeley Packet Filter
- Dynamically program the kernel for efficient networking, observability, tracing, and security
- BPF(1992년)를 확장해서 eBPF가 (2014년, Alexei Starovoitov)가 나왔고, eBPF를 다양한 영역(보안, 추적, 네트워킹, 모니터링)에서 활용하기 시작하였다.
- eBPF is a revolutionary technology that can run sandboxed programs in the Linux Kernel without changing kernel source code or loading kernel modules.
-> 커널 내에 (샌드박스 내에서) 자유롭게 프로그래밍하여 적용 할 수 있다
1.2 Cilium 소개
- Cilium은 eBPF(Berkeley Packet Filter)를 기반으로 Pod Network 환경 + 보안을 제공하는 CNI Plugin입니다.
- Kubernetes와 같은 Linux 컨테이너 관리 플랫폼을 사용하여 배포된 응용 프로그램 서비스 간의 네트워크 및 API 연결을 제공하는 오픈 소스 소프트웨어 입니다.
▶ Cilium eBPF는 추가적인 App이나 설정 변경 없이 리눅스 커널을 자유롭게 프로그래밍하여 동작 가능
- Kernel Layer에서 동작하는 Bytecode를 안전하게 Kernel에 Loading(injection) 할 수 있다
▶ Cilium attaches eBPF programs to ingress TC hooks of these links in order to intercept all incoming packets for further processing.
- 모든 패킷을 가로채기 위해서 수신 NIC의 ingress TC hooks을 사용한다
- Linux TC(Traffic Control) : 커널에서 동작하는 패킷 스케줄러
▶ 2가지 네트워크 모드를 제공 : 터널 모드(VXLAN, GENEVE), 네이티브 라우팅 모드
- In the tunnel mode, Cilium sets up a number of VXLAN(UDP 8472) or Geneve(UDP 6081) interfaces and forwards traffic over them.
- In the native-routing mode, Cilium does nothing to setup reachability, assuming that it will be provided externally.
- 2021.10월 Cilium는 CNCF에 Join 되었다.
- 또한 Google GKE dataplane과 AWS EKS Anywhere에 기본 CNI로 Cilium을 사용한다.
| Cilium이란? Cilium은 클라우드 네이티브 환경에서 컨테이너화된 애플리케이션을 위한 차세대 네트워킹 및 보안 솔루션이다. 특히 Kubernetes 환경에서 뛰어난 성능과 보안을 제공하며, 컨테이너 간의 네트워크 연결을 효율적으로 관리하고 보호하는데 중점을 두고 있다. Cilium이 필요한 이유? - 복잡한 컨테이너 환경 : 컨테이너 오케스트레이션 도구인 Kubernetes가 널리 사용되면서 컨테이너간의 네트워크 통신이 더욱 복잡해졌다. Cilium은 이러한 복잡성을 해겨하고 안정적인 네트워킹 환경을 제공한다. - 강화된 보안 : 클라우드 환경에서 컨테이너 보안은 매우 중요하다. Cilium은 세밀한 네트워크 정책을 통해 컨테이너 간의 접근을 제한하고, 외부 공격으로부터 시스템을 보호한다. - 뛰어난 성능 : 기존의 네트워킹 방식보다 훨씬 빠르고 효율적인 네트워크 처리를 제공하여 애플리케이션 성능을 향상시킨다. Cilium의 주요 기능 - eBPF 기반 : Linux 커널의 eBPF 기술을 활용하여 네트워킹을 가속화하고 유연한 네트워크 정책을 구현한다. - 세밀한 네트워크 정책 : 컨테이너, 서비스, 라벨 등 다양한 기준으로 네트워크 트래픽을 제어할 수 있다. - 서비스 메시 : 컨테이너 간의 통신을 안전하고 효율적으로 처리하는 서비스 메시 기능을 제공한다. - 관찰성 : 네트워크 트래픽을 실시간으로 모니터링하고 분석하여 문제를 빠르게 파악할 수 있다. - Kubernetes 통합 : Kubernetes와 완벽하게 통합되어 사용하기 쉽다. Cilium의 장점 - 높은 성능 : eBPF 를 활용하여 네트워킹 오버헤드를 최소화하고, 애플리케이션 성능을 극대화합니다. - 강력한 보안 : 세밀한 네트우크 정책을 통해 컨테이너 환경을 안전하게 보호 - 확장성 : 대규모 클러스터에서도 안정적으로 운영 - 오픈 소스 : 누구나 자유롭게 사용하고 기여할 수 있는 오픈 소스 프로젝트 Cilium vs Clico  |
1.3 Cilium 아키텍처
▶ 구성요소
- Cilium Agent : 데몬셋으로 실행, K8s API 설정으로부터 '네트워크 설정, 네트워크 정책, 서비스 부하분산, 모니터링' 등을 수행하며, eBPF 프로그램을 관리한다
- Cilium Client (CLI) : Cilium 커멘드툴, eBPF maps에 직접 접속하여 상태를 확인할 수 있다
- Cilium Operator : K8s 클러스터에 대한 한 번씩 처리해야 하는 작업을 관리
- Hubble : 네트워크와 보안 모니터링 플랫폼 역할을 하여, 'server, Relay, Client, Graphical UI'로 구성되어 있다
- Data Store : Cilium Agent 간의 상태를 저장하고 전파하는 데이터 저장소, 2가지 종류 중 선택(K8s CRDs, Key-Value Store)
▶ eBPF Datapath
* Introduction
- The Linux kernel supports a set of BPF hooks in the networking stack that can be used to run BPF programs.
- XDP : 네트워킹 드라이버의 가장 앞 단에서 XDP BPF hook을 통해서 BPF program을 트리거되기 때문에, 가능한 최고의 패킷 처리 성능을 제공
- Prefilter : An XDP program and provides a set of prefilter rules used to filter traffic from the network for best performance.
- LoadBalancer & NodePort XDP Acceleration
- XDP-based Standalone Load Balancer : Maglev Consistent hashing, n-Tuple PCAP Recorder
- TC(Traffic Control) Ingree/Egress
- Network Interface 에 tc ingress hook에서 BPF programs 실행된다
- 파드와 연결된 veth pair의 lxc의 tc ingress hook에서 BPF programs 실행된다. 노드(호스트)로 in/out 트래픽 모두를 모니터링 및 통제/정책을 적용할 수 있다
- Socket operations : BPF socket operations program은 root cgroup에 연결되며 TCP event(ESTABLISED)에서 실행됨
- Socket send/recv : The socket send/recv hook은 TCP socket의 모든 송수신 작업에서 실행, hook에서 검사/삭제/리다이렉션을 할 수 있다
- Endpoint Policy : 정책에 따라 패킷을 차단/전달하거나, 서비스로 전달하거나, L7 정책 전달 할 수 있다
- the Cilium datapath responsible for mapping packets to identities and enforcing L3 and L4 policies.
- Service : 모든 패킷의 목적지 IP/Port의 map 조회 시 일치하면 L3/L4 endpoint로 전달하며, Service block는 모든 인터페이스의 TC ingress hook에서 동작할 수 있다
- L3 Encryption, Socket Layer Enforcement
- L7 Policy : The L7 Policy object redirect proxy traffic to a Cilium userspace proxy instance. Cilium uses an Envoy instance as its userspace proxy. Envoy will then either forward the traffic or generate appropriate reject messages based on the configured L7 policy.
▶ Life of a Packet
[Endpoint to Endpoint] : 그림처럼 L7 정책 시에는 커널 hookpoint와 Userspace Proxy 사용으로 성능이 조금 떨어질 수 있다
[Egress from Endpoint]
[Ingress to Endpoint]
▶ eBPF Maps
- 모든 eBPF Map은 상한 용량이 있으며, limit 관련 여러 옵션들이 있다
- kube-proxy는 리눅스 코어에 따라 CT table 최대 수가 결정되며, Cilium은 BPF Maps이라는 자체 연결 추적 테이블을 가지고 메모리에 따라 최대 수가 결정됨
▶ Iptables Usage
- 커널 버전이 낮을 경우 iptables 동작으로 구현 될 수 있다. 혹은 cilium 미동작(장애 등 문제) 시, 트래픽 처리 보완 시
- 아래 그림은 cilium과 iptables을 같이 사용 시 다이어그램을 나타낸다
2. Cilium 배포
2.1 배포
▶ Cilium 설치 정보(w/Helm) 및 확인
| 주요 파라미터 설정 --set debug.enabled=true # cilium 파드에 로그 레벨을 debug로 설정 --set autoDirectNodeRoutes=true #동일 대역 내의 노드들 끼리는 상대 노드의 podCIDR 대역의 라우팅이 자동으로 설정 --set endpointRoutes.enabled=true # 호스트에 endpoint(파드)별 개별 라우팅 설정 --set hubble.relay.enabled=true --set hubble.ui.enabled=true # hubble활성화 --set ipam.mode=kubernetes --set k8s.requireIPv4PodCIDR=true # k8s IPAM 활용 --set RubeProxyReplacement=true # Rube-proxy 없이 (최대한) 대처할 수 있게 --set ipv4NativeRoutingCIDR=192.168.0.0/16 #해당 대역과 통신 시 IP masq 하지 않음, 보통 사내망 대역을 지정 --set operator.replicas=1 # cilium-operator 파드 기본 1개 --set enableIPv4Masquerade=true --set bpf.masquerade=true # 파드를 위한 Masquerade, 추가로 Masquerade을 BPF로 처리 |
- Cilium CLI 설치 : inspect the state of a Cilium installation, and enable/disable various features (e.g. clustermesh, Hubble)
2.2 Cilium 기본 정보 확인
▶ 변수 & 단축키
▶ 자주 쓰는 Cilium CLI 명령어
▶ Cilium 기본 정보 확인
▶ 네트워크 기본 정보 확인 : k8s-w1/w2에 SSH 접속 후 ip -c link/route 정보 확인
2.3 Hubble UI & CLI
▶ Observability
- Network Observability with Hubble
- Setting up Hubble Observability
- Inspecting Network Flows with the CLI
- Service Map & Hubble UI
- Configuring Hubble exporter
- Congifure TLS with Hubble
- Running Prometheus & Grafana
- Monitoring & Metrics
- Layer 7 Protocol Visibility
- Hubble for Network Observability and Security (part 3) : Leveraging Hubble Data for Network Security
- Hubble for Network Observability and Security (part 2): Utilizing Hubble for Network Observability
- Hubble for Network Observability and Security (part 1) : Introduction to Cilium and Hubble
▶ Hubble 소개 : 통신 및 서비스와 네트워킹 인프라의 동작에 대한 심층적인 가시성을 완전히 투명한 방식으로 제공하는 관찰성을 제공
- Hubble is a fully distributed networking and security observability platform -> 네트워크/보안 모니터링
- It is built on top of Cilium and eBPF to enable deep visibility into the communication and behavior of services as well as the networking infrastructure in a completely transparent manner. without requiring the application to change in any way. -> 애플리케이션의 코드 수정 등 추가 설정 없이 동작
- containerized workload as well as more traditional workloads such as virtual machines and standard Linux processes -> VM/서버도 모니터링 가능
- By leveraging Linux eBPF, Cilium retains the ability to transparently insert security visibility + enforcement, but does so in a way that is based on service / pod / container identity (in contrast to IP address identification in traditional systems) and can filter on application-layer (e.g. HTTP) -> 전통적인 IP 기반은 모니터링/통제가 아니라 서비스/파드/ID 기반으로 모니터링 통제를 제공
- 기본적으로 Hubble APi는 Cilium 에이전트가 실행되는 개별 노드의 범위 내에서 작동합니다. 이는 네트워크 통찰력을 로컬 Cilium 에이전트가 관찰한 트래픽으로 제한합니다. Hubble CLI(hubble)를 사용하여 로컬 Unix Domain Socket을 통해 제공된 Hubble API를 쿼리할 수 있습니다. Hubble CLi 바이너리는 기본적으로 Cilium 에이전트 포드에 설치됩니다.
- Hubble Relay를 배포하면 전체 클러스터 또는 ClusterMesh 시나리오의 여러 클러스터에 대한 네트워크 가시성이 제공됩니다. 이 모드에서 hubble 데이터는 Hubble CLI(hubble)를 Hubble Relay 서비스로 지정하거나 Hubble UI를 통해 액세스 할 수 있습니다. Hubble UI는 L3/L4 및 L7 계층에서 서비스 종속성 그래프를 자동으로 검색할 수 있는 웹 인터페이스로, 사용자 친화적인 시각화 및 서비스 맵으로서의 데이터 흐름 필터링을 허용합니다.
- Metrics export via Prometheus : Key metrics are exported via Prometheus for integration with your existing dashboards.
- Cluster-wide observability with Hubble Relay
- 통제 예시
- Allow all HTTP requests with method GET and path /public/.*. Deny all other requests.
- Allow service1 to produce on Kafka topic topic1 and service2 to consume on topic1. Reject all other Kafka messages
- Require the HTTP header X-Token : [0-9]+ to be present in all REST calls.
▶ Hubble UI/CLI 접근 및 확인
3. 노드 간 파드 통신 확인
▶ eBPF Datapath
eBPF Datapath는 eBPF(eXtended Berkeley Packet Filter) 기술을 활용하여 네트워크 데이터를 처리하는 파이프라인을 의미한다. 네트워크 패킷이 생성되어 목적지까지 도달하는 과정에서 eBPF 프로그램들이 특정 지점에서 패킷을 검사하고 조작할 수 있도록 해준다.
- Intro
: Linux 커널은 BPF 프로그램을 실행하는 데 사용할 수 있는 네트워킹 스택에서 BPF 후크 세트를 지원한다. Cilium 데이터 경로는 이러한 후크를 사용하여 BPF 프로그램을 로드하고, 함께 사용하면 상위 수준의 네트워킹 구조를 만든다. - Life of a Packet
1) Endpoint to Endpoint : L7 정책이 있는 로컬 엔드포인트 간 흐름을 보여준다. 그 다음에는 소켓 계층 적용이 활성화된 동일한 엔드포인트 간 흐름이 이어진다. TCP 트래픽에 대해 소켓 계층 적용이 활성화된 경우 연결을 시작하는 핸드셰이크는 TCP 상태가 ESTABLISEHD가 될 때까지 엔드포인트 정책 객체를 탐색한다.
2) Egress from Endpoint : 선택적 오버레이 네트워크가 있는 이그레스로의 로컬 엔드포인트를 보여준다. 선택적 오버레이 네트워크에서 트래픽은 오버레이에 해당하는 Linux 네트워크 인터페이스로 전달된다. 기본 케이스에서 오버레이 인터페이스는 cilium_vxlan이라는 이름이 지정된다.
3) Ingress to Endpoint : 선택적 오버레이 네트워크와 함께 로컬 엔드포인트로의 유입을 보여준다. 유사한 소켓 계층 시행을 사용하여 프록시와 엔드포인트 소켓 간의 정책 경로 추적 집합을 피할 수 있다. - eBPF Maps
: 모든 BPF 맵은 상한 용량으로 생성된다. 한계를 넘어 삽입하면 실패하여 데이터 경로의 확장성이 제한된다. - Iptables Usage
: 사용되는 Linux 커널 버전에 따라 eBPF 데이터 경로는 eBPF에서 다양한 기능 세트를 완전히 구현할 수 있다. 특정 필수 기능을 사용할 수 없는 경우 레거시 iptables 구현을 사용하여 기능이 제공된다.
▶ 파드 생성 및 확인
▶ 파드의 ARP 동작 확인
- Node's eBPF programs
