N° 01 — 목록
'Cloud & Infrastructure' (51)
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 06. network-policy
NetworkPolicy 하나 넣었더니 모든 트래픽이 막혔다 — "기본 허용" 함정한 팀이 보안 점검을 앞두고 NetworkPolicy를 도입했다. "웹 Pod는 DB Pod로만 가게 하자"며 정책을 하나 넣었다. 그랬더니 갑자기 다른 트래픽 — 웹 Pod가 외부 API를 부르던 것, 모니터링이 메트릭을 수집하던 것 — 이 전부 멈췄다. "정책을 하나만 넣었는데 왜 다 막혔지?" 이 팀이 부딪힌 것이 NetworkPolicy의 "기본 허용, 정책 시 화이트리스트" 모델이다.이 글이 푸는 것은: NetworkPolicy가 기본으로 모든 트래픽을 허용하는 이유, 하나의 정책이 왜 전체를 막는가, 그리고 L3/L4 격리의 한계다.왜 Kubernetes 네트워크 기본이 "전부 허용"인가대부분의 방화벽은 기본이 ..
-
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가 규모에서 무너지나 — 선형 탐색..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 04. calico
Calico가 BGP로 Pod를 잇는 법 — 그리고 WireGuard가 가져온 변화한 클러스터가 두 데이터센터에 걸쳐 있었다. 트래픽이 노드 간에 평문_으로 흘렀다. 보안 팀이 "Pod 통신을 암호화하라"고 요구했다. 팀은 Calico의 WireGuard 모드를 켰다 — 노드 간 Pod 트래픽이 커널 수준에서 암호화됐다. 코드 한 줄 안 고치고. 이것이 Calico를 *네트워크 플러그인 이상으로 쓰는 사례다.이 글이 푸는 것은: Calico가 03장의 두 접근(오버레이/언더레이)을 BGP와 IPIP/VXLAN 모드로 어떻게 구체화하고, WireGuard로 암호화를 어떻게 덧붙이는가다. 그리고 왜 Calico가 "CNI 하나"가 아니라 "CNI + 정책 엔진" 두 역할인지.03장의 연장선에서 Calico ..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 03. cni model
Pod끼리 통신이 안 되면 범인은 거의 항상 이 층이다 — CNI가 Pod 네트워크를 만드는 법Service로는 통신이 되는데, Pod IP로 직접 연결하면 안 된다. 클러스터를 처음 세팅한 팀이 가장 먼저 부딪히는 네트워크 문제다. 01장에서 kube-proxy(Service 층)와 CNI(Pod 간 층)가 다른 층이라고 했다 — 범인은 거의 항상 CNI 쪽이다. 그런데 CNI가 정확히 뭘 만드는가? 왜 Pod마다 IP가 붙고, 서로 다른 노드의 Pod가 통신 가능한가?이 글이 푸는 것은: CNI(Container Network Interface)가 Pod 네트워크를 어떻게 만드는가, 그리고 오버레이(overlay)와 언더레이(underlay)라는 두 근본 접근이 어떻게 다른가다. 이 글이 04(Cal..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 02. coredns
"web"이라고만 쳤는데 왜 다른 namespace로 가버리나 — CoreDNS와 NDots 함정한 팀이 클러스터 안에서 외부 API(api.weather.com)를 호출하는 코드를 올렸다. 어느 날부터 호출이 이상하게 느려지더니, 가끔 존재하지 않는 도메인(NXDOMAIN) 응답이 왔다. 원인은 Pod의 DNS 검색 도메인 설정 — ndots:5 — 이었다. 외부 도메인을 쳤는데 CoreDNS가 그것을 api.weather.com.default.svc.cluster.local 같은 클러스터 내부 이름으로 먼저 풀려 시도하다 실패하고, 그제야 외부로 나갔다. 매 요청마다 여러 번의 실패한 DNS 질의가 쌓인 것이다.이 글이 푸는 것은: CoreDNS가 클러스터 안에서 서비스 디스커버리를 어떻게 담당하고,..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 01. service kube-proxy
Pod는 죽을 때마다 IP가 바뀌는데, 클라이언트는 어떻게 "이 앱"을 찾나한 Pod의 IP는 10.0.1.5였다. 어플리케이션 클라이언트는 그 IP로 접속했다. 그런데 노드가 죽어 Pod가 다른 노드로 재스케줄됐고, IP가 10.0.1.9로 바뀌었다. 클라이언트는 여전히 10.0.1.5로 연결을 시도하다 실패했다 — 아무도 IP가 바뀌었다고 알려주지 않았으니까.이것이 Pod IP로 직접 접속하면 안 되는 이유다. Pod는 재스케줄될 때마다 IP가 바뀐다. 클라이언트가 "이 앱"을 안정적으로 찾으려면, 바뀌는 IP를 감추는 고정된 진입점이 필요하다. 그 역할을 Service가 한다.이 글이 푸는 것은: Service가 바뀌는 Pod IP들을 어떻게 하나의 안정된 이름으로 묶는가, kube-proxy가 그..