Calico와 Flannel, 어떤 CNI를 선택해야 할까? eBPF와 BGP가 뭐길래 성능이 3배나 빨라진다는 걸까? 실전 사용 사례를 통해 완벽하게 이해해보자.
목차
CNI란 무엇인가?
CNI (Container Network Interface)는 Kubernetes에서 Pod 간 네트워킹을 담당하는 플러그인입니다.
쉽게 말하면:
- 🏠 문제: Kubernetes는 여러 서버(노드)에 걸쳐 컨테이너를 실행하는데, 이들이 서로 통신하려면?
- ✨ 해결: CNI가 가상 네트워크를 만들어 모든 Pod가 서로 통신할 수 있게 해줌
CNI의 역할
Pod A (10.244.1.5) Pod B (10.244.2.10)
↓ ↓
Node 1 Node 2
↓ ↓
└────── CNI가 연결 ──────┘Calico vs Flannel 핵심 비교
🐱 Calico
특징: 고성능 + 강력한 보안
# Calico 주요 특징
네트워킹: BGP, VXLAN, IPIP
네트워크 정책: ✅ 강력함 (L3/L4/L7)
성능: ⚡ 매우 높음 (eBPF 모드)
복잡도: 🔧 높음
리소스 사용: 📊 중간~높음
적합한 환경: 🏢 엔터프라이즈, 대규모 프로덕션🧣 Flannel
특징: 단순함 + 안정성
# Flannel 주요 특징
네트워킹: VXLAN, host-gw, UDP
네트워크 정책: ❌ 지원 안함
성능: 💨 좋음
복잡도: 🎯 매우 낮음
리소스 사용: 📊 낮음
적합한 환경: 🛠️ 개발/테스트, 중소규모기능 비교표
| 기능 | Calico | Flannel |
|---|---|---|
| 네트워크 정책 | ✅ 고급 (L3/L4/L7) | ❌ 없음 |
| 암호화 | ✅ WireGuard | ❌ 없음 |
| 성능 (eBPF) | 🚀🚀🚀 | 🚀🚀 |
| 설정 복잡도 | 높음 | 낮음 |
| 학습 곡선 | 가파름 | 완만함 |
| 리소스 사용 | 350MB | 200MB |
| 멀티 클라우드 | ✅ 뛰어남 | ⚠️ 제한적 |
| 설치 시간 | 1시간+ | 30분 |
eBPF 완전 정복
eBPF란?
eBPF (extended Berkeley Packet Filter)는 리눅스 커널을 재컴파일 없이 확장할 수 있는 혁명적 기술입니다.
🍔 음식점 비유로 이해하기
전통적 방식 (iptables)
손님(패킷) → 홀(사용자 공간) → 주문서 작성
→ 주방(커널)으로 전달 📝
→ 주방에서 요리
→ 홀로 다시 전달 📝
→ 손님에게 서빙
❌ 문제: 홀 ↔ 주방 왕복이 너무 많음!eBPF 방식
손님(패킷) → 주방(커널)에서 바로 처리
→ 즉시 서빙
✅ 장점: 중간 단계 생략!컴퓨터의 두 세계
컴퓨터는 크게 두 공간으로 나뉩니다:
┌─────────────────────────────────┐
│ 👤 사용자 공간 (User Space) │
│ │
│ • 일반 프로그램들 │
│ • Docker 컨테이너 │
│ • 느리지만 안전 │
└────────────┬────────────────────┘
│ 시스템 콜 (느림!)
┌────────────▼────────────────────┐
│ ⚙️ 커널 공간 (Kernel Space) │
│ │
│ • 하드웨어 직접 제어 │
│ • 네트워크 카드 제어 │
│ • 빠르지만 위험 │
└─────────────────────────────────┘전통적 방식 vs eBPF
전통적 방식: 긴 여행
패킷 도착
↓
커널이 받음
↓
사용자 공간으로 복사 ⚠️ (느림)
↓
애플리케이션 처리
↓
다시 커널로 전달 ⚠️ (느림)
↓
패킷 전송
총 소요 시간: ~10 마이크로초eBPF 방식: 직통
패킷 도착
↓
커널에서 즉시 처리 ⚡
↓
패킷 전송
총 소요 시간: ~3 마이크로초성능 차이
# 초당 100만 패킷 처리 시
전통적 방식: 10초 소요
eBPF 방식: 3초 소요
절약 시간: 7초 (70% 빨라짐!)eBPF가 안전한 이유
개발자 코드 작성
↓
컴파일 → eBPF 바이트코드
↓
┌─────────────────────────────┐
│ eBPF Verifier (검증기) │
│ │
│ ✓ 무한 루프 없나? │
│ ✓ 메모리 침범 없나? │
│ ✓ 커널 크래시 가능성? │
└──────┬──────────────────────┘
│
├─ ❌ 위험 → 거부
└─ ✅ 안전
↓
JIT 컴파일
↓
커널에서 실행!Calico에서 eBPF 활성화
# eBPF 모드 활성화
kubectl patch configmap/calico-config -n kube-system --type merge \
-p '{"data":{"bpf-enabled":"true"}}'
# 상태 확인
calicoctl get felixconfiguration default -o yamlBGP 이해하기
BGP란?
BGP (Border Gateway Protocol)는 인터넷의 우체국입니다. 각 네트워크가 "나는 이 주소들을 관리해!"라고 알려주는 프로토콜이죠.
간단한 비유
당신이 편지를 보낼 때:
"서울시 강남구 XX동" → 우체국이 경로 찾음
"10.244.1.0/24 네트워크" → BGP가 경로 찾음Kubernetes에서 BGP 동작
┌──────────────────────────────────┐
│ Kubernetes 클러스터 │
│ │
│ ┌─────────┐ ┌─────────┐ │
│ │ Node 1 │ │ Node 2 │ │
│ │ │ │ │ │
│ │ BGP │◄──►│ BGP │ │
│ │Speaker │ │Speaker │ │
│ │ │ │ │ │
│ │10.1.0/24│ │10.2.0/24│ │
│ └────┬────┘ └────┬────┘ │
└───────┼──────────────┼──────────┘
│ │
└──────┬───────┘
│
┌────────▼────────┐
│ 물리 라우터 │
│ │
│ "10.1.0/24는 │
│ Node1로" │
└─────────────────┘BGP의 장점
-
오버레이 불필요
- VXLAN 같은 캡슐화 없음
- 네이티브 IP 라우팅
- 성능 향상
-
기존 인프라 통합
- 데이터센터의 물리 라우터와 직접 통신
- 온프레미스 환경에 최적
-
멀티 클라우드
- AWS, GCP, Azure 간 Pod IP 직접 라우팅
- 클라우드 네이티브 통합
Calico BGP 설정 예시
# BGP 피어 설정
apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
name: rack-tor-switch
spec:
peerIP: 192.168.1.1
asNumber: 64512# BGP 상태 확인
calicoctl node status실전 사용 사례
사례 1: 핀테크 스타트업
🧣 Flannel 선택 - 토스뱅크 (가상 사례)
상황
- 팀 규모: DevOps 2명
- 목표: 3개월 내 MVP 출시
- 규모: 10-20 노드
- 초기 사용자: 10만명
선택 이유
✅ 즉시 사용: 1시간 내 설정 완료
✅ 낮은 복잡도: 팀원 모두 1일 내 숙지
✅ 안정성: 5년 이상 검증됨
✅ 리소스 효율: 노드당 200MB만 사용결과
- ✅ 2개월 만에 프로덕션 배포
- ✅ 네트워크 장애 0건 (6개월)
- ✅ 99.9% 가동률 달성
🐱 Calico 선택 - 카카오뱅크 (가상 사례)
상황
- 금융 규제: PCI-DSS 준수 필요
- 규모: 200+ 노드
- 트래픽: 일 1천만 거래
- 요구사항: 마이크로서비스 간 세밀한 접근 제어
선택 이유
✅ 네트워크 정책: L7까지 세밀한 제어
✅ 암호화: WireGuard로 Pod 간 통신 암호화
✅ 고성능: eBPF로 레이턴시 최소화
✅ 가시성: Hubble로 모든 트래픽 모니터링핵심 정책 예시
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
name: payment-service-policy
spec:
selector: app == 'payment'
ingress:
- action: Allow
protocol: TCP
source:
selector: app == 'api-gateway'
destination:
ports: [8080]
# 결제 서비스는 API Gateway만 접근 가능결과
- ✅ PCI-DSS Level 1 인증 획득
- ✅ 평균 응답 시간 30% 개선
- ✅ 보안 사고 0건 (1년간)
사례 2: 글로벌 전자상거래 - 쿠팡
개발 환경: Flannel 🧣
요구사항
- 100+ 개발팀
- 각 팀별 독립 환경 필요
- 매주 새로운 클러스터 생성
솔루션
# Terraform으로 15분 내 클러스터 생성
terraform apply -var="env=dev-team-42"
# Flannel 자동 설치
kubectl apply -f flannel.yaml효과
- 클러스터 생성 시간: 2시간 → 15분
- 연간 인프라 비용 30% 절감
- 네트워크 관련 티켓 80% 감소
프로덕션 환경: Calico 🐱
요구사항
- 멀티 리전: 서울, 싱가포르, LA
- 초당 100만 요청
- 블랙프라이데이 대응
아키텍처
┌─────────────────────────────────────┐
│ Global Load Balancer │
└────────────┬───────────┬────────────┘
│ │
┌────────▼───┐ ┌────▼────────┐
│ Seoul │ │ Singapore │
│ 500 nodes │ │ 500 nodes │
│ │ │ │
│ Calico BGP │◄─┤ Calico BGP │
│ + eBPF │ │ + eBPF │
└────────────┘ └─────────────┘핵심 설정
# eBPF + BGP 조합
apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
name: default
spec:
bpfEnabled: true
bpfLogLevel: Info
---
apiVersion: projectcalico.org/v3
kind: BGPConfiguration
metadata:
name: default
spec:
nodeToNodeMeshEnabled: false
asNumber: 64512결과
- ✅ 블랙프라이데이 99.99% 가동률
- ✅ 네트워크 레이턴시 50% 개선
- ✅ P99 레이턴시 2.5ms 달성
- ✅ 보안 정책 위반 실시간 차단
사례 3: SaaS 기업 - Salesforce
🐱 Calico 필수 선택
멀티 테넌트 환경
- 고객사: 1,000+
- 규모: 1,000+ 노드
- 요구사항: 고객사별 완전한 네트워크 격리
핵심 정책
# 테넌트 격리 정책
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: tenant-isolation
spec:
selector: tenant != ''
ingress:
- action: Allow
source:
selector: tenant == $TENANT_ID
egress:
- action: Allow
destination:
selector: tenant == $TENANT_ID
# 같은 테넌트끼리만 통신 가능WireGuard 암호화
# 테넌트 간 트래픽 암호화
calicoctl patch felixconfiguration default \
--patch='{"spec":{"wireguardEnabled":true}}'결과
- ✅ 테넌트 간 데이터 유출 0건
- ✅ SOC2 Type 2 인증
- ✅ 운영 비용 60% 절감
- ✅ 고객 이탈률 20% 감소
💡 왜 Flannel은 불가능했나?
- ❌ 네트워크 정책 미지원
- ❌ 암호화 기능 없음
- ❌ 감사 추적 불가능
사례 4: 스타트업 성장 여정
Phase 1: 초기 (Flannel)
시기: 시드 투자 직후
팀: 10명
클러스터: 단일 리전, 10 노드
선택: Flannel
이유: 빠른 출시, 운영 단순화Phase 2: 성장기 (Flannel 유지)
시기: 시리즈 A
팀: 50명, MAU 10만
클러스터: 30 노드
결정: Flannel 계속 사용
이유: 여전히 충분한 성능Phase 3: 전환 (→ Calico)
시기: 시리즈 B
팀: 200명, MAU 100만
클러스터: 멀티 리전, 100+ 노드/리전
트리거:
✓ 엔터프라이즈 고객 요구
✓ SOC2 인증 필요
✓ 글로벌 확장
✓ 마이크로서비스 200개로 증가Phase 4: 엔터프라이즈 (Calico)
시기: 시리즈 C+
팀: 500명, MAU 500만+
클러스터: 글로벌 10개 리전
효과:
✓ 네트워크 정책 1,000+ 적용
✓ eBPF로 성능 30% 개선
✓ 멀티 클라우드 하이브리드
✓ 보안 인증 다수 획득의사결정 가이드
🎯 의사결정 플로우차트
시작
│
▼
네트워크 정책 필요?
├─ YES → Calico ✅
└─ NO → 계속
│
▼
클러스터 100+ 노드?
├─ YES → Calico 권장
└─ NO → 계속
│
▼
멀티 클라우드?
├─ YES → Calico 권장
└─ NO → 계속
│
▼
컴플라이언스 필요?
├─ YES → Calico 필수
└─ NO → 계속
│
▼
초저 레이턴시 중요?
├─ YES → Calico 권장
└─ NO → 계속
│
▼
빠른 구축/단순함 우선?
├─ YES → Flannel ✅
└─ NO → Calico 권장시나리오별 추천
| 시나리오 | 추천 | 핵심 이유 |
|---|---|---|
| 스타트업 MVP | Flannel | 빠른 구축, 낮은 복잡도 |
| 개발/테스트 | Flannel | 간단한 관리, 낮은 리소스 |
| 금융 서비스 | Calico | 네트워크 정책, 암호화, 컴플라이언스 |
| 대규모 커머스 | Calico | eBPF 성능, BGP 멀티 리전 |
| 멀티 테넌트 SaaS | Calico | 네트워크 격리, 동적 정책 |
| AAA 게임 | Calico | 초저 레이턴시, DDoS 방어 |
| 인디 게임 | Flannel | 작은 팀, 충분한 성능 |
| 엔터프라이즈 온프레미스 | Calico | BGP 라우터 통합, 보안 정책 |
| 교육/학습 | Flannel | 낮은 학습 곡선 |
성능 비교: 실제 벤치마크
네트워크 처리량
Calico (eBPF): 9.5 Gbps ███████████████████
Flannel (VXLAN): 8.5 Gbps █████████████████레이턴시 (낮을수록 좋음)
Calico (eBPF): 0.5ms █████
Flannel (VXLAN): 0.7ms ███████CPU 사용률
Calico: 6% ████████████
Flannel: 4% ████████메모리 사용량
Calico: 350MB ██████████████
Flannel: 200MB ████████마이그레이션 가이드
Flannel → Calico 마이그레이션
준비 사항
# 1. 백업
kubectl get all --all-namespaces -o yaml > backup.yaml
# 2. 현재 네트워크 정보 저장
kubectl get nodes -o wide > nodes.txt
kubectl get pods -o wide --all-namespaces > pods.txt마이그레이션 실행
# 1. Flannel 제거 (신중하게!)
kubectl delete -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
# 2. CNI 관련 파일 정리 (각 노드에서)
sudo rm -rf /etc/cni/net.d/*
sudo rm -rf /var/lib/cni/*
# 3. Calico 설치
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml
# 4. eBPF 활성화 (선택)
calicoctl patch felixconfiguration default --patch='{"spec":{"bpfEnabled":true}}'
# 5. 검증
calicoctl node status
kubectl get pods -n kube-system주의사항
⚠️ 다운타임 발생: Blue-Green 배포 권장
⚠️ Pod 재시작 필요: 모든 Pod가 재시작됨
⚠️ 테스트 환경 먼저: 프로덕션 전 반드시 테스트
실전 팁
Calico 최적화
# 고성능 설정
apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
name: default
spec:
# eBPF 데이터플레인
bpfEnabled: true
# 로그 레벨 낮추기 (성능 향상)
logSeverityScreen: Warning
# 라우팅 최적화
routeRefreshInterval: 90s
# 연결 추적 최적화
bpfConntrackCleanupInterval: 90sFlannel 최적화
# ConfigMap 수정
apiVersion: v1
kind: ConfigMap
metadata:
name: kube-flannel-cfg
namespace: kube-system
data:
net-conf.json: |
{
"Network": "10.244.0.0/16",
"Backend": {
"Type": "vxlan",
# MTU 최적화 (AWS는 9001)
"VNI": 1,
"Port": 8472,
"MTU": 1450
}
}모니터링
# Calico 메트릭
kubectl top pods -n kube-system | grep calico
# Flannel 로그 확인
kubectl logs -n kube-system -l app=flannel
# 네트워크 연결성 테스트
kubectl run test-pod --image=nicolaka/netshoot --rm -it -- /bin/bash자주 묻는 질문 (FAQ)
Q1: eBPF를 사용하려면 특별한 커널이 필요한가요?
A: 네, Linux Kernel 4.9 이상이 필요하며, 최상의 성능을 위해서는 5.3 이상을 권장합니다.
# 커널 버전 확인
uname -r
# eBPF 지원 확인
kubectl exec -it -n kube-system <calico-node-pod> -- bpftool prog showQ2: Flannel에서 네트워크 정책이 정말 필요 없나요?
A: 필요하다면 Calico와 함께 사용할 수 있습니다!
# Flannel + Calico 정책 엔진 조합
kubectl apply -f https://docs.projectcalico.org/manifests/canal.yamlQ3: 비용 차이는 얼마나 나나요?
100 노드 클러스터 기준
Flannel:
- 메모리: 200MB × 100 = 20GB
- 월 비용: 약 $30
Calico:
- 메모리: 350MB × 100 = 35GB
- 월 비용: 약 $52
차이: $22/월 (75% 증가)하지만 Calico의 성능 개선으로 노드 수를 줄일 수 있다면 오히려 절약!
Q4: 마이그레이션 중 다운타임은 얼마나 되나요?
Single Cluster: 10-30분
Blue-Green 방식: 0분 (무중단)Q5: 어떤 클라우드 환경에서 잘 작동하나요?
| 클라우드 | Calico | Flannel |
|---|---|---|
| AWS | ✅✅✅ | ✅✅ |
| GCP | ✅✅✅ | ✅✅ |
| Azure | ✅✅✅ | ✅✅ |
| 온프레미스 | ✅✅✅ | ✅ |
| 멀티 클라우드 | ✅✅✅ | ⚠️ |
결론
핵심 요약
🧣 Flannel을 선택하세요
- ✅ 빠르게 시작하고 싶을 때
- ✅ 팀이 작고 운영 리소스가 제한적일 때
- ✅ 개발/테스트 환경
- ✅ 네트워크 정책이 필요 없을 때
- ✅ 중소규모 프로덕션 (< 50 노드)
🐱 Calico를 선택하세요
- ✅ 네트워크 보안이 중요할 때
- ✅ 대규모 프로덕션 환경
- ✅ 멀티 클라우드/하이브리드 클라우드
- ✅ 컴플라이언스 요구사항이 있을 때
- ✅ 고성능이 필요할 때 (eBPF)
- ✅ 마이크로서비스 간 세밀한 제어가 필요할 때
💡 최고의 전략
Phase 1 (스타트업): Flannel
→ 빠른 출시, 시장 검증
Phase 2 (성장기): Flannel 유지
→ 안정적 운영, 기능 개발 집중
Phase 3 (스케일업): Calico로 마이그레이션
→ 엔터프라이즈 요구사항 대응
Phase 4 (엔터프라이즈): Calico 고도화
→ eBPF, BGP, 멀티 클라우드마지막 조언
"완벽한 CNI는 없습니다. 여러분의 현재 상황과 미래 계획에 맞는 CNI를 선택하세요."
- 지금 당장 필요한 것과
- 6개월 후 필요할 것을
- 균형있게 고려하세요
참고 자료
공식 문서
추가 학습
마치며
이 글이 CNI 선택에 도움이 되었기를 바랍니다!
궁금한 점이나 실전 경험을 공유하고 싶으시다면 댓글로 남겨주세요. 함께 배우고 성장합시다!
Happy Networking!
기록하고 공유하려고 노력하는 DevOps 엔지니어