day-log

Kubernetes 1.33에서 kube-proxy의 nftables 모드가 GA로 승격됐다. 우리 팀도 iptables 모드에서 nftables 모드로 옮기는 논의를 시작했는데, 막상 "왜 nftables가 iptables보다 빠른가"라는 질문에 답이 잘 안 나왔다. "룰 개수가 줄어드니까 빠르지" 정도로 부족했다. 그래서 KEP-3866과 실제 룰 덤프를 뜯어보며 정리했다. 이 글은 그 결과다.기본적으로 아직 iptables가 kube-proxy의 기본 모드로 남아있고, 명시적으로 --proxy-mode nftables를 줘야 nftables 모드가 켜진다. 커널은 5.13 이상이 필요하다. 이 부분은 공식 블로그에도 명확히 적혀 있다.왜 iptables 모드가 느렸는가먼저 iptables 모드의 구..

Kubernetes Service가 어떻게 Pod에 트래픽을 흘려보내는지, 표면적으로는 다들 안다. Service → Endpoints → Pod IP 이렇게 이어진다는 그림 말이다. 그런데 실제로 v1.33 기준으로 클러스터 안에서 벌어지는 일은 이 그림과 조금 다르다. Endpoints API는 이제 사실상 legacy로 밀려나 있고, 그 자리를 EndpointSlice가 완전히 차지했다. 최근에 우리 팀 신규 클러스터를 1.33으로 올리면서 노드 350대짜리 스테이징에서 Service 업데이트 지연을 재현하다가, 이 내부 동작을 다시 파고들 일이 있었다. 오늘은 그 정리다.이 글은 짧지 않다. Service의 실체가 궁금하거나, kube-proxy 성능이 왜 클러스터 규모에 따라 갑자기 무너지는지 ..

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

왜 또 kube-proxy 얘기인가kube-proxy는 Kubernetes에서 가장 오래된 컴포넌트 중 하나다. 그런데 사람들은 의외로 이 친구가 실제로 뭘 하는지 잘 모른다. Service ClusterIP로 패킷이 들어오면 Pod로 잘 가더라, 정도가 평균적인 이해다. 나도 한참 그랬다.올해 1.33에서 nftables 모드가 정식으로 GA가 됐고, 이제 Linux 노드에서는 공식 권장 모드가 nftables라는 분위기가 만들어졌다. 우리 팀에서도 다음 분기 클러스터 업그레이드 때 nftables로 넘어갈지를 두고 논의 중이다. 결정을 하려면 세 모드가 도대체 어떻게 다른지를 손에 쥐고 있어야 하는데, 매번 검색해서 보다 보니 한번 정리해두자 싶었다.이 글은 "어느 모드가 빠른가" 같은 표 비교가 아..