Kubernetes Calico CNI(Container Network Interface)

Calico

kubespray로 클러스터를 구성하면 default CNI로 Calico가 셋업된다. 현재 회사에 구성된 클러스터에 사용되는 CNI만큼, 한번 살펴보려고 한다.

요즘 Cilium에 대한 언급이 많은데, Cilium은 eBPF 기반으로 L7 네트워크 정책과 보안에 특화되어있어, 고성능 및 세분화된 보안 정책이면 Calico는 Linux 커널의 L3 라우팅 기반으로 BGP(Border Gateway Protocol)을 활용하여 주로 대규모 클러스터 환경에서 기본적인 보안 정책을 지원하며 성능 최적화도 뛰어나다고 알려져있다. 

Calico는 Tigera라는 회사에서 개발했으며, 아래 공식 문서를 참고하면 좋다.

https://docs.tigera.io/calico/latest/about/

• 쿠버네티스 워크로드와 레거시 워크로드가 원활하고 안전하게 통신할 수 있게하는 네트워크 솔루션
• 베어메탈로 구성된 클러스터부터, EKS, GKE, AKS, OpenShift, VMware, openstack 지원 및 Flannel 통합
• Dataplane으로 iptables, eBPF, VPP, Windows HNX 지원
• 클러스터 내의 allow/deny 정책을 namespace, global로 설정가능
• HTTP method, path 등을 통하여 Application L7 정책 강화

Architecture

 

https://docs.tigera.io/calico/latest/reference/architecture/overview

Calico-node

각 클러스터 노드에 설치되는 데몬으로 아래와 같이 daemonset과 노드별로 pod가 생성되어 있는 것을 확인할 수 있다. 네트워크 정책 및 라우팅을 관리하며 두가지 핵심 컴포넌트가 존재한다.

- Felix: Calico의 주요 에이전트로, 각 노드에서 실행되며, 포드간 네트워크 정책을 설정하고 적용함. IP 테이블을 이용해 네트워크 트래픽을 제어하며, 네트워크 정책을 기반으로 포드간 트래픽을 허용하고 차단함.

- BIRD: BGP 라우터로, 각 노드 간 경로 정보를 교환하고 라우팅을 관리함. BGP로 네트워크 경로 설정하고, 노드 간 라우팅 정보를 동기화함.

Kubernetes API Server

Calico 설정과 상태를 저장하는 데이터 저장소. 초기에는 etcd가 주로 사용되었으나, 현재는 Kubernetes API와 통합하여 상태를 관리. 각 파드에 할당된 IP 주소와 네트워크 정책 등의 정보를 중앙에서 관리.

Typha

대규모 클러스터에서 사용되는 컴포넌트, 클러스터에 있는 여러 calico-node의 업데이트 정보를 집계하여 Felix에 전달. Felix와 etcd간 직접적인 통신을 줄여 대규모 환경에서 성능을 최적화.

CNI Plugin

Calico CNI 플러그인은 쿠버네티스의 네트워크 인터페이스 역할을 담당하여 파드가 생성되거나 삭제될 때 IP 주소를 할당하고 네트워크 설정을 적용. (Kubernetes와 Calico 간의 연결을 담당)

CNI IPAM

각 파드에 고유한 IP를 할당하고 할당된 IP 주소를 관리. IP 주소 충돌을 방지하며, 네트워크 자원을 효율적으로 사용할 수 있도록 도움.

calicoctl ipam show를 통해서 IPAM 정보를 확인할 수 있다. 할당 가능한 대역대가 현재 많이 남아있는 것을 볼 수 있다.(Blcok은 각 노드에 할당된 Pod CIDR 정보를 말한다)

Workflow of Calico Architecture

1. 파드 생성: Kubernetes는 Calico CNI 플러그인을 호출하여 새 파드에 IP를 할당하고 네트워크 인터페이스를 설정. 여기서 IPAM을 통해 고유 IP 주소가 부여.

2. Felix: 각 노드에서 Felix 에이전트가 실행되어 네트워크 정책을 가져와 IP 테이블에 적용. 이를 통해 설정된 네트워크 정책에 따라 파드간 트래픽이 허용되거나 차단.

3. BIRD BGP: 각 노드간의 라우팅 정보를 동기화하여 포드 간 L3 통신을 지원. 노드간에 직접 연결된 라우팅 경로를 통해 파드가 서로 통신(VXLAN을 사용하면 vxlan.calico라는 가상 네트워크 인터페이스를 통해서 사용되기 때문에 BIRD 프로세스가 사용되지 않음)

여기서 클러스터 구성에따라 Typha가 calico-node의 상태를 집계하여 최적화하는 작업이 추가된다.

calicoctl

IPAM을 확인해보려면 calicoctl을 이용해야한다. 아래 링크를 참고해서 설치한 후에 ippool의 ip 할당 상태와 pod의 IP를 확인해본다.

https://docs.tigera.io/calico/latest/operations/calicoctl/install

Install calicoctl | Calico Documentation

ippool을 확인해보면, vxlanMode가 Always로 설정된 것을 알 수 있다. Vxlan(Virtual Extensible LAN)은 네트워크 오버레이 기술로, 대규모 쿠버네티스 클러스터나 여러 서브넷에 노드 간 네트워크 트래픽을 안정적으로 전달하는 데 사용된다.

VxLAN

L2 데이터 링크 계층의 오버레이 네트워크를 L3 네트워크 위에 생성하여 서로 다른 서브넷에 있는 노드 통신이 가능케한다. 쉽게 말하면, 서로 다른 데이터센터나 서브넷에 있어도 파드들이 같은 가상 네트워크에 연결된 것처럼 통신된다.

BGP를 사용하지 않기 때문에 node status는 확인할 수 없다.

이 모드를 사용하면 BGP가 필요없으며, 16만 개 이상의 가상 네트워크를 지원하기 때문에 대규모 클러스터에서 유용하다.  특히 트래픽이 캡슐화되어 전달되기 때문에 노드와 서브넷간에 동일한 IP를 사용하더라도 트래픽이 충돌하지 않는다.

calicoctl get ippool: default-pool이라는 IP pool이 생성되어있고, CIDR qjadnlrk 10.233.64.0/18로 설정되어있다. Selector는 all()로 설정되어 모든 노드에 이 IP pool이 사용된다. (10.233.64.0/18로 설정된 IP 풀은 10.233.64.1부터 10.233.127.254까지 IP를 포함)

calicoctl get wep -n arbitrum-full: wep는 workload endpoint를 의미한다. arbitrum-full 네임스페이스의 워크로드에 대한 설정을 확인할 수 있다. IP pool의 CIDR 기준으로 할당된 IP 주소는 10.233.111.195/32, 인터페이스는 cali4f9077be901이다.(각 워크로드에는 고유한 가상 네트워크 인터페이스가 생성)

route -n

서버의 라우팅 테이블을 살펴보면 calico에 네트워크 경로가 어떻게 구성되어있는지 확인가능하다. 

Default Route(0.0.0.0)은 기본 라우팅 경로로, 서버가 외부 네트워크와 통신할 때 사용되는 경로이며 enp1s0f0 인터페이스를 사용한다. calico관련된 것은 vxlan.calico, cali207106af9cc, calif1f81b83f47 인터페이스다.

vxlan.calico는 VXLAN 오버레이 네트워크를 통해 노드 간 통신에 VXLAN 터널링이 사용되고 있는 것을 확인할 수 있다.

나머지 calico workload interface는 개별 파드의 네트워크 트래픽을 처리하여 10.233.97.128과 10.233.97.131에 직접 연결한다.

10.233.97.128를 사용하는 파드는 이전에 할당되었다가 삭제되어 발견할 수 없었으나, 10.233.97.131은 dns-autoscaler가 사용하는 ip였다.