day-log

들어가며3년 전쯤만 해도 "CNI는 그냥 Calico 깔자"가 답이었다. 안정적이고 자료 많고 문제 생기면 iptables 룰 뜯어보면 됐다. 그런데 최근 1년 사이에 분위기가 좀 바뀌었다. GKE Dataplane V2가 Cilium 기반이고, AKS도 "Azure CNI Powered by Cilium"을 권장 옵션으로 밀고 있다. EKS는 기본은 여전히 AWS VPC CNI지만 Cilium을 얹는 사례가 눈에 띄게 늘었다.우리 팀도 작년 하반기에 새 클러스터 두 개를 띄우면서 Cilium으로 갈아탔다. 기존 클러스터는 Calico를 계속 쓰고 있어서, 1년 정도 두 개를 같이 운영하면서 느낀 걸 정리해본다. 결론부터 말하면 "신규는 Cilium, 기존은 굳이 안 옮긴다"이긴 한데, 이게 모든 팀에 ..

kube-proxy를 Cilium으로 교체한 지 1년이 좀 넘었다. 처음엔 단순히 "iptables 룰이 많아져서 느려지니까 eBPF로 바꾸자" 정도의 인식이었는데, 운영하면서 보니 동작 모델 자체가 완전히 다르다. ClusterIP 패킷이 어디서 어떻게 처리되는지, 왜 socket-level LB가 그렇게 강조되는지, DSR은 왜 켰을 때 갑자기 응답이 안 오는지 — 이런 걸 제대로 알아야 디버깅이 가능했다.이번 글은 우리 팀에서 KubeCon EU 2026 직후 사내 발표용으로 정리한 내용을 다시 풀어쓴 거다. 코드 예제보다는 패킷이 흐르는 경로를 추적하는 데 집중했다.kube-proxy의 한계, 그리고 왜 eBPF가 답이 됐나kube-proxy iptables 모드는 Service 하나당 여러 개의..

CNI 교체는 사실 자주 할 일이 아니다. 한 번 들어가면 클러스터 수명 내내 같이 가는 컴포넌트라 잘못 고르면 두고두고 후회한다. 우리 팀은 작년 4분기에 Calico로 운영하던 프로덕션 클러스터 3개를 Cilium으로 옮겼고, 그 후 약 8개월을 양쪽 다 운영해봤다. 아직 일부 레거시 클러스터는 Calico를 그대로 두고 있어서 비교가 가능한 상황이다.이번 KubeCon EU에서도 Cilium 세션이 절반은 되더라. CNCF 2025 연간 서베이에서 Cilium이 Calico랑 Flannel을 제치고 프로덕션 CNI 1위를 먹었다는 발표가 있었는데, 우리 팀이 옮길 때만 해도 그 정도까진 아니었다. 1년 사이에 분위기가 꽤 바뀐 셈이다.왜 옮겼는가솔직히 처음부터 옮길 생각은 없었다. Calico는 안..

CNI 갈아탈까 말까 하는 고민은 누구나 한 번쯤 한다. 우리 팀도 작년 말부터 "Cilium 한번 가보자" 분위기가 있었고, 결국 6개월 가까이 PoC와 운영 시뮬레이션을 돌렸다. 결론부터 말하면, 메인 워크로드는 Calico에 남겼고 새로 구축한 ML 추론 클러스터만 Cilium으로 갔다. 같은 회사 안에서 CNI를 두 개 쓰게 된 셈인데, 이 글은 왜 그런 결정을 했는지에 대한 정리다.왜 갈아타고 싶었나우리 메인 EKS 클러스터는 노드 80대 규모. Calico를 3년 넘게 써왔고 큰 문제는 없었다. 그런데 최근 1년 사이 두 가지 가려운 부분이 생겼다.하나는 kube-proxy iptables 룰이 너무 길어진 거다. Service 수가 1,200개를 넘기면서 노드당 iptables 룰이 4만 줄..