day-log

멀티클러스터 네트워킹 붙일 일이 생겼다. 처음엔 별 생각 없었는데, 막상 후보를 놓고 보니 결정이 애매했다. Cilium ClusterMesh랑 Submariner. 둘 다 CNCF 프로젝트고, 둘 다 "서비스가 클러스터 경계를 넘어서 통신하게 해준다"는 결과물은 비슷하다.근데 실제로 붙여보면 완전 다른 물건이다. 우리 팀은 결국 ClusterMesh로 갔지만, 그게 정답이라고는 못 하겠다. 상황에 따라 다르다.왜 이 결정을 해야 했나우리 쪽은 EKS 두 개 리전에 걸쳐 있다. 서울 + 도쿄. 원래는 리전간 통신이 필요 없었는데, 이번에 특정 서비스(주문/결제 쪽)를 DR 목적으로 양쪽에 띄우기로 하면서 상황이 바뀌었다.요구사항이 이랬다:서비스가 다른 리전 클러스터의 파드도 endpoint로 인식해야 함..

Ingress-NGINX를 4년 넘게 써왔다. 그동안 별문제 없이 잘 굴러갔는데, 올해 초부터 팀 내부에서 Gateway API로 넘어가야 하는 것 아니냐는 이야기가 계속 나왔다. 근거는 나쁘지 않았다. Gateway API v1.5가 2026년 2월에 나오면서 상당수 기능이 Stable로 승격됐고, 6월에 v1.6까지 이어졌다. Ingress에 없던 표준 트래픽 분할, 리트라이 버짓, BackendTLSPolicy 같은 것들이 실제로 필요했다.두 달 넘게 검토했고, 결론은 "전면 이관은 아니고, 신규 서비스부터 단계적으로"였다. 그 결정에 이르기까지 뭘 봤는지 정리해둔다.뭐가 다른가가장 큰 차이는 리소스 모델이다. Ingress는 하나의 오브젝트가 라우팅과 컨트롤러 설정을 다 짊어진다. 그래서 어노테이..

요즘 새 클러스터 세팅할 때마다 CNI를 Cilium으로 깔고, 그 다음날부터 "Hubble UI 켜주세요" 요청이 들어온다. Pixie도 붙여봤고, 최근에는 Grafana Beyla까지 검토 목록에 올렸다. 세 도구 다 "사이드카 없이 관측성 확보"라는 같은 문구를 쓰는데, 사실 내부적으로는 노드에서 하는 일이 꽤 다르다. 이번 주에 팀 세미나 준비하면서 각 도구가 어디에 eBPF 프로그램을 붙이는지, 데이터는 어떻게 흘러 나가는지 다시 정리했다.이 글은 그 정리 노트다. 사용법 튜토리얼은 아니고, "왜 이 도구는 HTTP 헤더까지 보이는데 저 도구는 IP:포트만 보이지?" 같은 궁금증에 답이 되도록 쓴다.eBPF 훅 포인트가 결정하는 관측 범위관측성 도구가 뭘 볼 수 있는지는 결국 커널의 어느 지점에..

이번 분기 OKR 중에 "데이터플레인 통합" 항목이 하나 있었다. 우리는 그동안 kube-proxy(iptables 모드) + Calico CNI 조합을 써왔는데, 네트워크폴리시 관측이 약하고 iptables 룰이 노드당 8천 줄을 넘기 시작하면서 syncProxyRules 지연이 P95 기준 1.2초까지 튀는 날이 가끔 있었다. 다른 팀이 먼저 Cilium 으로 갈아탔길래, 우리도 다음 주에 도입하기로 했다.결론부터 말하면 도입은 했다. 그런데 도입 첫날 새벽 2시에 보안팀한테 "audit log 의 source IP 가 전부 노드 IP 로 찍히는데 뭔가 잘못된 거 아니냐" 라는 메시지를 받았고, 거기서부터 24시간이 좀 정신없었다.1차 시도 — kubeProxyReplacement=true 만 켜고 ..

들어가며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만 줄..

요즘 사내에서 sidecar 없는 서비스 메시 이야기가 자주 나온다. 우리 팀도 작년 4분기에 Istio sidecar 모드를 운영하다가 메모리 footprint와 업그레이드 부담에 지쳐서 sidecarless 옵션을 진지하게 검토하기 시작했다. 후보는 두 개로 좁혀졌다. Istio Ambient Mode와 Cilium Service Mesh.둘 다 sidecar를 없앤다는 큰 그림은 같은데 접근 방식이 꽤 다르다. 어느 쪽이 우리 팀에 맞는지 판단하기까지 두 달 정도 PoC를 돌렸고, 그 과정에서 알게 된 것들을 정리한다. 결론부터 말하면 우리는 아직 한쪽을 완전히 못 정했다. 그래서 이 글은 깔끔한 권고문이 아니다.데이터 플레인이 어디서 도는가가장 큰 차이는 트래픽이 처리되는 위치다.Istio Amb..

NetworkPolicy를 처음 도입할 때 가장 답답한 게 뭐냐고 물으면, 나는 망설임 없이 "왜 막혔는지 모르겠다"고 답한다. kubectl logs를 봐도 connection timeout만 보이고, 정작 어느 정책이 그 트래픽을 끊었는지는 알려주지 않는다. 예전엔 cilium monitor를 노드 단위로 띄워서 한참을 들여다봤는데, Hubble이 들어오고 나서는 이 과정이 꽤 깔끔해졌다.이 글은 Cilium 1.19.x 환경에서 Hubble을 가지고 네트워크 정책을 디버깅하는 워크플로우를 정리한 거다. 우리 팀에서 정책을 새로 추가할 때마다 반복적으로 쓰는 절차이고, 신규 입사자한테도 이 순서대로 보여준다.Hubble flow를 보기 전에 확인할 것먼저 Hubble이 활성화돼 있어야 한다. 의외로 ..