Calico가 BGP로 Pod를 잇는 법 — 그리고 WireGuard가 가져온 변화한 클러스터가 두 데이터센터에 걸쳐 있었다. 트래픽이 노드 간에 평문_으로 흘렀다. 보안 팀이 "Pod 통신을 암호화하라"고 요구했다. 팀은 Calico의 WireGuard 모드를 켰다 — 노드 간 Pod 트래픽이 커널 수준에서 암호화됐다. 코드 한 줄 안 고치고. 이것이 Calico를 *네트워크 플러그인 이상으로 쓰는 사례다.이 글이 푸는 것은: Calico가 03장의 두 접근(오버레이/언더레이)을 BGP와 IPIP/VXLAN 모드로 어떻게 구체화하고, WireGuard로 암호화를 어떻게 덧붙이는가다. 그리고 왜 Calico가 "CNI 하나"가 아니라 "CNI + 정책 엔진" 두 역할인지.03장의 연장선에서 Calico ..
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..
클러스터의 두뇌와 손 — 컨트롤 플레인과 노드가 어떻게 갈리는가한 클러스터에서 노드 3대가 동시에 재부팅됐다. Pod들은 전부 죽었고, 운영자는 "클러스터가 죽었다"고 보고했다. 하지만 정확히 무엇이 죽은 걸까? 재부팅된 노드 위의 kubelet은 다시 살아나자마자 apiserver에 "내가 돌아왔다, 내 담당 Pod들을 다시 띄워 달라"고 물었고, 90초 안에 Pod들이 복구됐다. 죽은 건 Pod였지 클러스터가 아니었다.이 사례가 보여주는 건 Kubernetes의 가장 중요한 분리 — 결정하는 층(컨트롤 플레인)과 실행하는 층(노드) — 이다. 이 분리를 이해하면 "무엇이 죽었는지, 그래서 무엇이 복구되는지"를 정확히 읽을 수 있다. 이 글은 그 두 층이 정확히 어떤 부품으로 이뤄지고 어떻게 통신하는지..
Archive
Calico가 BGP로 Pod를 잇는 법 — 그리고 WireGuard가 가져온 변화한 클러스터가 두 데이터센터에 걸쳐 있었다. 트래픽이 노드 간에 평문_으로 흘렀다. 보안 팀이 "Pod 통신을 암호화하라"고 요구했다. 팀은 Calico의 WireGuard 모드를 켰다 — 노드 간 Pod 트래픽이 커널 수준에서 암호화됐다. 코드 한 줄 안 고치고. 이것이 Calico를 *네트워크 플러그인 이상으로 쓰는 사례다.이 글이 푸는 것은: Calico가 03장의 두 접근(오버레이/언더레이)을 BGP와 IPIP/VXLAN 모드로 어떻게 구체화하고, WireGuard로 암호화를 어떻게 덧붙이는가다. 그리고 왜 Calico가 "CNI 하나"가 아니라 "CNI + 정책 엔진" 두 역할인지.03장의 연장선에서 Calico ..
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..
클러스터의 두뇌와 손 — 컨트롤 플레인과 노드가 어떻게 갈리는가한 클러스터에서 노드 3대가 동시에 재부팅됐다. Pod들은 전부 죽었고, 운영자는 "클러스터가 죽었다"고 보고했다. 하지만 정확히 무엇이 죽은 걸까? 재부팅된 노드 위의 kubelet은 다시 살아나자마자 apiserver에 "내가 돌아왔다, 내 담당 Pod들을 다시 띄워 달라"고 물었고, 90초 안에 Pod들이 복구됐다. 죽은 건 Pod였지 클러스터가 아니었다.이 사례가 보여주는 건 Kubernetes의 가장 중요한 분리 — 결정하는 층(컨트롤 플레인)과 실행하는 층(노드) — 이다. 이 분리를 이해하면 "무엇이 죽었는지, 그래서 무엇이 복구되는지"를 정확히 읽을 수 있다. 이 글은 그 두 층이 정확히 어떤 부품으로 이뤄지고 어떻게 통신하는지..
wall
방문 흔적을 남겨주세요. 질문이나 인사 모두 환영합니다.
