Calico 리서치

Kubernetes/Calico

Calico 리서치

이쿠우우 2026. 1. 12. 21:47

목표

Calico에 대해 알아봄.

Calico 란?

Calico는 Container, VM 환경에서 L3기반 Virtual Network를 구축하게 도와주는 Networking Providers.

kubernetes에서 사용 가능한 CNI (Container Network Interface)로 Flannel과 더불어서 대표적으로 사용되고 있는 CNI.

Calico는 Kubernetes 이외에도 OpenShift, Mirantis Kubernetes Engine(MKE), OpenStack, Docker Shim등 다양한 플랫폼에서 사용 가능.

CNI란?

CNI : Container Network Interface

컨테이너 간의 네트워킹을 제어할 수 있는 플러그인을 만들기 위한 표준.

Kubernetes Cluster 내부는 Master Node 에 의해 여러 컨테이너가 생성 삭제 복구를 반복하고 있음

그에 따라 각 컨테이너의 고정적이지 않고 재할당이 빈번함.

이러한 특징을 해결하기 위해 Kubernetes Cluster는 가상 네트워크가 구성되어 있는데

기본적으로는 Worker Node 의 kube-proxy 가 네트워크를 관리하지만

보다 효율적인 네트워크 환경을 구성하기 위해

다양한 네트워크 관련 Addon 이 제공됨

종류)

Flannel, Calico, Canal, Cilium, CNI-Genie, Contiv, Multus, NSX-T, Nuage, Romana, Weave Net

Flannel과 Calico의 차이점

[Network Policy]

Flannel : 지원하지 않음

Calico : 지원

[Networking mode]

Flannel : VXLAN

Calico : IP-in-IP, VXLAN, Direct

[IPAM]

Flannel : HOST의 IPAM 사용함.

Calico : Calico 전용 IPAM을 별도로 사용함.

Calico Components

Calico-node

Daemonset으로 배포되어 모든 node에서 동작하고 있음.

Calico CNI 동작의 핵심 역할을 수행하는 container가 모두 calico-node에 포함되어있음.

Calico-node : Felix

Calico의 핵심 에이전트(Brain) 역할을 수행하며, 실제 패킷을 처리하기 위해 호스트의 커널을 조작하는 담당자.

Interface 관리: Pod가 생성되면 호스트와 연결되는 가상 인터페이스(cali***)를 생성하고 관리합니다.
Route Table 관리 (Local): 내 노드에 떠 있는 Pod로 가는 경로(Local Route)를 호스트 라우팅 테이블에 설정합니다.
Network Policy (ACL) 관리: K8s NetworkPolicy 리소스를 감지하여 방화벽 룰(iptables 등)을 설정합니다.
상태 보고: 노드의 헬스 체크 및 상태 정보를 Datastore에 보고합니다. (etcd)
- Datastore mode가 etcd인 경우 : etcd에 다이렉트로 상태보고함.
- Datastore mode가 Kubernetes API (KDD) 인 경우 : kube-apiserver 에 상태보고함 calicoNode라는 Custom Resource(CR)의 Status 필드를 업데이트

[Felix vs BIRD : 라우팅 역할 분담]

Routing Table을 작성하는 작업은 두 프로세스가 역할을 나누어 수행합니다.

BIRD: 다른 노드(Peer)로부터 받은 원격지 Pod 대역의 경로를 호스트 라우팅 테이블에 입력합니다.
- (예: "Node B로 가려면 eth0으로 가라")
Felix: 자기 노드에 생성된 Pod의 경로를 호스트 라우팅 테이블에 입력합니다.
- (예: "Pod A로 가려면 cali123 인터페이스로 가라")

[kube-proxy와 Felix의 관계 & eBPF 모드]

일반 모드 (Standard Linux Networking):
- kube-proxy: Service(ClusterIP) 연결 및 부하분산 담당 (iptables 또는 IPVS 사용).
- Felix: Pod 통신 보안(Network Policy) 담당.
- 결론: 둘 다 실행되어야 함.
eBPF 모드 (Calico의 고성능 모드):
- Felix가 eBPF 프로그램을 이용해 Network Policy뿐만 아니라 Service 부하분산까지 모두 처리함.
- 결론: 이 경우에만 kube-proxy를 비활성화(대체)할 수 있음.

Calico-node : BIRD

CALICO_NETWORKING_BACKEND 설정이 bird 일 때만 실행되는 BGP 데몬.

(vxlan 모드나 none 모드에서는 실행되지 않음.)

모든 노드에 배포되어 실행되며, 노드 간에 BGP Peering을 맺음.

내 노드에 있는 Pod들의 IP 정보를 다른 노드(Peer)들에게 전파하는 역할을 담당.

이를 통해 각 노드는 클러스터 전체의 Pod 경로(Route)를 학습하게 됨.

기본적으로 bird 백엔드 모드에서는 IP-in-IP, VXLAN 캡슐화를 모두 지원하지만, 라우팅 정보 교환 자체는 BGP(BIRD)가 담당함.

참고 (Backend=vxlan 인 경우):

이 모드에서는 BIRD가 배포되지 않으며, BGP 대신 Felix가 Datastore 정보를 기반으로 라우팅을 직접 처리함.

BGP Peering 모드 (Topology)

BIRD가 노드끼리 통신하는 방식은 크게 두 가지로 나뉘며, 클러스터 규모에 따라 선택해야 함.

BGPConfiguration 리소스의 nodeToNodeMeshEnabled 값으로 설정 가능

Node-to-Node Mesh (Default):
- nodeToNodeMeshEnabled : true
- 모든 노드가 서로 1:1로 연결됨 (Full Mesh).
- 모든 노드가 서로 1:1로 연결되므로, 노드 수가 N개일 때 연결 수는 N(N-1)/2* 개가 됨.
- 설정이 간편하나 노드 수가 많아지면 부하가 급증함.
- 단점 : 노드가 100개면 약 5,000개의 연결이 필요하지만, 노드가 1,000개가 되면 약 50만 개의 연결이 필요해져 네트워크 부하가 급증함.
Route Reflector (RR):
- nodeToNodeMeshEnabled : false
- 특정 노드(RR)를 통해서만 라우팅 정보를 교환하는 중앙 집중형 구조.
- 비유: 교실(Cluster)에서 모든 학생(Node)이 서로 떠드는 것(Full Mesh) 대신, 반장(RR)에게만 이야기하고 반장이 이를 전체에게 전달하는 방식.
- 이를 통해 연결 복잡도를 획기적으로 줄여 대규모 클러스터에서도 안정적인 통신이 가능함.
- 대규모 클러스터(Node 100개 이상)에서 필수적임.

[BIRD 프로세스 동작 확인]

ps -ef | grep bird

[peering node 목록 확인 : calicoctl 사용]

calicoctl node status

[BGP 란?]

Border Gateway Protocol의 약자로
서로 다른 AS(Autonomous System) 즉
서로 다른 Router를 연결해주는 Protocol로 Packet을 어느 Router로 Routing할지 결정해줌.
따라서 각 Router는 자신이 전달할 수 있는 IP List를 알고 있어야 함.

[Calico에서의 역할]
Calico는 각 노드를 가상의 BGP 라우터로 취급함.
각 노드는 자신이 관리하는 Pod CIDR(IP 대역) 정보를 "내 쪽으로 보내라"고 다른 노드들에게 전파함.
- iBGP (Internal BGP): 같은 클러스터 내부의 노드끼리 통신할 때 사용 (기본 AS 번호: 64512).
- eBGP (External BGP): 클러스터 외부의 물리 라우터(ToR 스위치 등)와 통신할 때 사용.

Calico-node : Confd

calico-node 컨테이너 내부에서 동작하는 경량 설정 관리 도구.

전통적인 라우팅 데몬인 BIRD는 본래 정적인 설정 파일(bird.cfg)을 읽어 동작하는데,

수시로 변하는 Kubernetes 환경(노드 추가/삭제, IP 대역 변경)에 대응할 수 있도록

동적으로 설정 파일을 생성하고 BIRD를 제어하는 역할을 수행함.

Confd는 아래와 같은 순환 구조로 BIRD를 최신 상태로 유지함.

Monitoring (감시): Calico Datastore(etcd 또는 K8s API)의 특정 Key/Value 값들을 실시간으로 모니터링(Watch)함.
Rendering (생성): 감지된 변경 사항(새로운 노드 정보, BGP 설정 변경 등)을 반영하여 BIRD 설정 템플릿을 기반으로 새로운 설정 파일(bird.cfg)을 생성함.
Trigger (적용): 설정 파일이 변경되면, Confd가 BIRD 프로세스에 **"설정을 다시 읽으라(Reload)"**는 명령을 내려 라우팅 정보를 갱신함.

Confd가 Datastore에서 주시하는 정보는 BGP Peering에 필수적인 데이터들임.

Node Information: 클러스터 내 다른 노드들의 IP 및 AS 번호 (Peering 대상).
Pod CIDR: 각 노드에 할당된 Pod IP 대역 (전파해야 할 경로 정보).
BGP Configuration: 앞서 정리한 BGPConfiguration 리소스(Full Mesh 여부, RR 설정 등).

Calico Datastore

Calico가 클러스터 네트워킹을 구성하는 데 필요한 모든 설정과 상태 정보를 저장하는 중앙 저장소.

저장 데이터:

Configuration: IP Pool, BGP Configuration, Felix Configuration 등.
Policy: Network Policy, Global Network Policy (보안 규칙).
Inventory: Node 정보, Endpoint(Pod) 정보 등.

Datastore은 Kubernetes, etcd 2개의 mode 를 제공하고 있음.

multi cluster가 아닌 경우에는 일반적으로 Kubernetes mode로 사용하는 것을 추천함.

데이터 저장소를 사용할 수 없는 경우 Calico Network는 계속 작동하지만 업데이트할 수 없음.

저장소 모드

Kubernetes mode(KDD: Kubernetes Datastore Driver)
- default mode.
- 별도의 DB를 구축하지 않고, Kubernetes API Server를 통해 데이터를 저장하고 조회함.
- 데이터는 실제로 Kubernetes의 etcd에 저장되지만,
- Calico는 이를 CRD(Custom Resource Definition) 형태로 관리함.
etcd mode
- 레거시(Legacy) 또는 특수 목적용으로 사용됨. kubernetes가 아닌 플랫폼(ex: openstack)
- kubernetes와 Calico 리소스를 분리할 수 있음.
- Calico가 직접 etcd 클러스터에 접속하여 데이터를 읽고 씀.
- Multi-cluster에서 Calico 구성할 때 사용함.

특징	Kubernetes API (KDD)	etcd Mode
권장 환경	일반적인 Kubernetes 클러스터	OpenStack, Hybrid, 특수 대규모 환경
데이터 접근	kube-apiserver 경유 (CRD)	etcd 직접 접속 (/calico/...)
운영 복잡도	낮음 (추가 관리 요소 없음)	높음 (별도 etcd 관리 및 백업 필요)
보안(RBAC)	Kubernetes RBAC 사용 가능	별도 인증서/계정 관리 필요

Calico IPAM plugin

kubernentes cluster의 Pod에 IP 주소를 할당하고 회수하는 관리자.

Calico Datastore에 저장되어있는 IP-Pools정보를 기반으로 Pod ip 대역을 설정함.

Kubernetes는 직접 Pod에 IP 주소를 할당하고 관리하는 대신 IPAM 플러그인을 사용하도록 설계되어있음.

CNI Plugin인과 마찬가지로 다양한 IPAM Plugin이 존재하지만, 보통은 CNI Plugin과 같이 제공됨.

Calico 역시 자체 IPAM Plugin인 calico-ipam을 가지고 있음.

kubernetes cluster는 default로 Host Local IPAM이 동작함.(각 Node별로 pod의 CIDR을 할당함)

하지만, Calico에서는 Pod의 IP를 직접 관리하기 위해 별도의 IPAM이 할당됨.

(참고 : Flannel의 경우 별도의 IPAM이 없고 Host의 IPAM을 사용함.)

Calico IPAM의 핵심 특징: Block Affinity

기존 방식 (Host-Local / Flannel):
- 고정 할당: 노드가 생성될 때 미리 큰 대역(예: /24, IP 256개)을 뚝 떼어 노드에 줌. (spec.podCIDR)
- 문제점:
  - Pod가 5개밖에 없는 노드도 IP 256개를 점유하므로 IP 낭비가 심함.
  - 반대로 Pod가 너무 많은 노드는 IP가 모자라 Pod 생성이 실패할 수 있음
Calico 방식 (Calico IPAM):
- 동적 블록 할당: 노드에 큰 대역을 미리 주지 않고, 작은 블록(Block, 기본 /26, IP 64개) 단위로 필요할 때마다 할당.
- 유연성: A 노드에 Pod가 많아져서 할당받은 블록을 다 쓰면, 동적으로 새로운 블록을 추가로 받아옴.
- 효율성: Pod가 적은 노드는 IP를 적게 가져가므로, 클러스터 전체의 IP 자원을 효율적으로 쓸 수 있음.

[Calico IPAM 설정 확인]

/etc/cni/net.d/10-calico.conflist

[참고] IPAM이란?

정의: IP Address Management의 약자로, 네트워크 상의 IP 주소 할당, 추적, 관리를 자동화하는 솔루션.
K8s에서의 의미: CNI 프레임워크의 일부로서, 컨테이너에 중복되지 않는 고유한 IP를 발급해주는 역할을 수행하는 모듈.

kube-controllers (Calico-kube-controllers)

Kubernetes API Server를 모니터링(Watch)하여, 클러스터의 상태 변화를 Calico Datastore에 동기화하는 컨트롤러

첨부한 그림에서 보이는 것 같이 calico-kube-controllers는 kube-apiserver를 watch하고 있음.

Datastore 모드에 따른 역할 차이

Etcd Mode인 경우: (핵심 동기화 담당)

K8s의 NetworkPolicy, Service 등을 감지하여 Etcd에 Calico 전용 데이터 포맷으로 변환 및 저장함.
이 컨트롤러가 죽으면 새로운 정책(Policy)이 적용되지 않음.

Kubernetes(KDD) Mode인 경우: (리소스 정리 및 청소 담당)

Felix가 K8s CRD를 직접 읽으므로 정책 동기화 역할은 줄어듦.
하지만 Garbage Collection(GC) 역할을 수행하기 위해 반드시 필요함.
예시:
- kubectl delete node로 노드를 삭제했을 때, kube-controllers가 없으면
- Calico는 해당 노드에 할당된 IP Block과 IP 정보를 삭제하지 않고 영원히 점유(Leak)하게 됨.
즉, 클러스터의 리소스 효율성과 데이터 무결성을 위해 KDD 모드에서도 배포되어야 함.

calico-kube-controller 내부 controller 항목

policy controller: watches network policies and programs Calico policies.
namespace controller: watches namespaces and programs Calico profiles.
serviceaccount controller: watches service accounts and programs Calico profiles.
workloadendpoint controller: watches for changes to pod labels and updates Calico workload endpoints.
node controller: watches for the removal of Kubernetes nodes and removes corresponding data from Calico, and optionally watches for node updates to create and sync host endpoints for each node.

컨트롤러	역할
Node Controller	• K8s 노드 삭제 시, Calico 데이터(IP 할당 정보 등)를 함께 삭제(GC). • (Etcd 모드 시) K8s 노드 정보를 Calico 호스트 정보로 동기화.
Policy Controller	• (주로 Etcd 모드) K8s NetworkPolicy를 감지하여 Calico Policy로 변환/동기화.
Namespace Controller	• Namespace 생성/삭제를 감지하여 Calico Profile을 관리.
ServiceAccount Controller	• ServiceAccount 변경 사항을 Calico Profile에 동기화.
WorkloadEndpoint Controller	• Pod의 라벨(Label) 변경 등을 감지하여 Endpoint 정보를 갱신.