CNI
Container Network Interface
CNI(Container Network Interface)는 Kubernetes 및 컨테이너 런타임의 네트워킹 플러그인 표준입니다. Flannel, Calico, Cilium 등 다양한 CNI 플러그인으로 Pod 간 통신을 구현합니다.
Container Network Interface
CNI(Container Network Interface)는 Kubernetes 및 컨테이너 런타임의 네트워킹 플러그인 표준입니다. Flannel, Calico, Cilium 등 다양한 CNI 플러그인으로 Pod 간 통신을 구현합니다.
CNI(Container Network Interface)는 컨테이너 런타임과 네트워크 플러그인 사이의 표준 인터페이스입니다. CNCF(Cloud Native Computing Foundation)에서 관리하며, Kubernetes가 Pod에 네트워크를 할당하고 Pod 간 통신을 가능하게 하는 핵심 메커니즘입니다. CNI 없이는 Kubernetes 클러스터의 Pod들이 서로 통신할 수 없습니다.
CNI는 2015년 CoreOS에 의해 시작되었습니다. Docker의 libnetwork와 달리 단순함과 확장성에 초점을 맞춰 설계되었습니다. 컨테이너가 생성되면 kubelet이 CNI 플러그인을 호출하여 네트워크 네임스페이스를 설정하고 IP를 할당합니다. 컨테이너 삭제 시에는 반대로 네트워크 리소스를 정리합니다.
대표적인 CNI 플러그인으로는 Flannel(가장 단순, VXLAN 기반), Calico(네트워크 정책 + BGP 라우팅), Cilium(eBPF 기반, L7 정책), Weave Net(암호화 지원), AWS VPC CNI(AWS 네이티브 IP 할당) 등이 있습니다. 프로덕션 환경에서는 Calico가 가장 널리 사용되며, 고급 기능이 필요하면 Cilium을 선택합니다.
Kubernetes의 네트워크 모델은 "모든 Pod은 다른 모든 Pod과 NAT 없이 통신할 수 있다"는 원칙을 따릅니다. CNI 플러그인은 이 원칙을 구현하기 위해 오버레이 네트워크(VXLAN, IPIP), 언더레이 네트워크(BGP), 또는 클라우드 네이티브 방식(AWS VPC CNI)을 사용합니다.
# Calico CNI 설치 (가장 널리 사용)
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/custom-resources.yaml
# 설치 확인
kubectl get pods -n calico-system
watch kubectl get pods -n calico-system
# Calico 네트워크 정책 예제 (특정 Pod만 통신 허용)
cat <
# Flannel CNI 설치 (가장 단순)
kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml
# 설치 확인
kubectl get pods -n kube-flannel
kubectl get nodes -o wide
# Flannel 설정 확인
kubectl get configmap kube-flannel-cfg -n kube-flannel -o yaml
# Flannel CIDR 확인
cat /run/flannel/subnet.env
# FLANNEL_NETWORK=10.244.0.0/16
# FLANNEL_SUBNET=10.244.0.1/24
# 노드별 Pod CIDR 확인
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDR}{"\n"}{end}'
# Flannel 로그 확인 (문제 해결 시)
kubectl logs -n kube-flannel -l app=flannel
# kubeadm 초기화 시 Pod CIDR 지정 (Flannel 기본값)
# kubeadm init --pod-network-cidr=10.244.0.0/16
# Cilium CNI 설치 (eBPF 기반, 고급 기능)
# Cilium CLI 설치
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-amd64.tar.gz
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
# Cilium 설치
cilium install --version 1.14.2
# 설치 상태 확인
cilium status --wait
# 연결성 테스트
cilium connectivity test
# L7 네트워크 정책 (HTTP 메소드 기반 제어)
cat <
"kubeadm init 후에 CNI를 설치해야 노드가 Ready 상태가 됩니다. 우리 팀은 Calico를 쓰는데, 네트워크 정책이 기본 제공되고 BGP 라우팅도 지원해서 확장성이 좋습니다. 단순히 오버레이만 필요하면 Flannel이 가볍고 좋아요."
"CNI는 컨테이너 런타임이 네트워크 네임스페이스를 설정하고 IP를 할당하는 표준 인터페이스입니다. kubelet이 Pod를 생성할 때 /etc/cni/net.d/의 설정을 읽고 /opt/cni/bin/의 바이너리를 실행합니다. 실제로 Calico의 경우 Felix가 iptables 룰을 관리하고, BIRD가 BGP로 라우팅 정보를 교환합니다."
"기본 Kubernetes는 모든 Pod이 서로 통신할 수 있어서 보안상 위험합니다. Calico나 Cilium으로 NetworkPolicy를 적용해서 namespace 간 격리하고, 특정 포트만 허용해야 합니다. Cilium은 L7 정책도 지원해서 HTTP 메소드 단위로 제어할 수 있습니다."
kubeadm init 후 CNI를 설치하지 않으면 노드가 NotReady 상태로 유지됩니다. coredns Pod도 Pending 상태가 됩니다. 클러스터 초기화 직후 반드시 CNI를 설치하세요.
CNI의 Pod CIDR(예: 10.244.0.0/16)이 호스트 네트워크나 VPC CIDR과 겹치면 라우팅 문제가 발생합니다. kubeadm init --pod-network-cidr 옵션으로 충돌하지 않는 대역을 지정하세요.
한 클러스터에 여러 CNI를 설치하면 예측 불가능한 동작이 발생합니다. 기존 CNI를 완전히 제거한 후 새 CNI를 설치하세요. 특히 Flannel에서 Calico로 마이그레이션 시 주의가 필요합니다.
개발/테스트 환경은 Flannel(단순함), 프로덕션은 Calico(안정성 + 네트워크 정책), 고급 관찰성/보안이 필요하면 Cilium(eBPF 기반), AWS EKS는 AWS VPC CNI(네이티브 성능)를 선택하세요.