N° 01 — 목록
'Hubble' (2)
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 13. troubleshooting
"네트워크가 안 된다"에서 시작해 범인을 좁히는 법 — 트러블슈팅 결정 트리한 서비스가 "DB에 연결이 안 된다"고 보고됐다. 운영자가 1시간을 헤맸다 — Pod가 살아있는지, Service가 있는지, NetworkPolicy가 막는지, CNI가 꼬였는지, DNS가 풀리는지 전부 의심했다. 결국 원인은 conntrack 테이블 만료. 그런데 그 1시간의 대부분은 틀린 층을 뒤진 데 쓰였다. 이 글은 그 1시간을 5분으로 줄이는 결정 트리를 다룬다.이 글이 푸는 것은: "네트워크가 안 된다"는 모호한 증상에서 시작해, 어느 층(DNS/kube-proxy/CNI/정책/커널)인지를 체계적으로 좁히는 절차다. 핵심은 층별로 나눠 한 층씩 검증하는 것이다.먼저 층을 나눈다 — 어디를 의심할 것인가지금까지 01~1..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 05. cilium ebpf
Cilium이 eBPF로 kube-proxy를 통째로 바꾸는 법한 클러스터의 노드가 2000개였다. Service가 만 개 넘게 있었고, kube-proxy가 각 노드에 만든 iptables 규칙이 수십만 줄이었다. 패킷 하나를 라우팅할 때마다 커널이 그 규칙을 선형으로 훑었다 — 지연이 눈에 띄게 커졌다. 팀은 Cilium으로 전환했다. kube-proxy를 끄고, eBPF가 라우팅을 직접 처리하게 했다. 규칙이 해시 테이블로 바뀌어 거의 일정한 속도로 떨어졌다.이 글이 푸는 것은: Cilium이 eBPF로 왜 iptables/kube-proxy를 대체할 수 있는가, 그리고 그것이 단순히 "빠른 CNI"가 아니라 근본적으로 다른 데이터플레인인 이유다.왜 iptables가 규모에서 무너지나 — 선형 탐색..