한 번 쓰고 영원히 본다 — watch/list가 조정 루프를 어떻게 지탱하는가kubectl get pods를 1초마다 돌리는 모니터링 스크립트를 본 적이 있다. 잘 동작했지만 apiserver에 1초마다 전체 Pod 목록을 요청했다 — 클러스터에 Pod가 5000개면 매초 5000개를 직렬화해 보내는 셈이다. 어느 순간 apiserver가 CPU 100%에 도달했고, 모니터링이 클러스터를 죽이는 역설이 벌어졌다. 해결책은 폴링을 멈추는 게 아니라 watch로 바꾸는 것이었다.이 글이 푸는 질문: Kubernetes에서 수십 개의 컨트롤러가 동시에 돌면서 매번 "상태가 바뀌었나?"를 확인하는데, 왜 apiserver는 붕괴하지 않는가? 답은 list-watch 패턴과 리소스 버전(resourceVersi..
클러스터의 두뇌와 손 — 컨트롤 플레인과 노드가 어떻게 갈리는가한 클러스터에서 노드 3대가 동시에 재부팅됐다. Pod들은 전부 죽었고, 운영자는 "클러스터가 죽었다"고 보고했다. 하지만 정확히 무엇이 죽은 걸까? 재부팅된 노드 위의 kubelet은 다시 살아나자마자 apiserver에 "내가 돌아왔다, 내 담당 Pod들을 다시 띄워 달라"고 물었고, 90초 안에 Pod들이 복구됐다. 죽은 건 Pod였지 클러스터가 아니었다.이 사례가 보여주는 건 Kubernetes의 가장 중요한 분리 — 결정하는 층(컨트롤 플레인)과 실행하는 층(노드) — 이다. 이 분리를 이해하면 "무엇이 죽었는지, 그래서 무엇이 복구되는지"를 정확히 읽을 수 있다. 이 글은 그 두 층이 정확히 어떤 부품으로 이뤄지고 어떻게 통신하는지..
Archive
한 번 쓰고 영원히 본다 — watch/list가 조정 루프를 어떻게 지탱하는가kubectl get pods를 1초마다 돌리는 모니터링 스크립트를 본 적이 있다. 잘 동작했지만 apiserver에 1초마다 전체 Pod 목록을 요청했다 — 클러스터에 Pod가 5000개면 매초 5000개를 직렬화해 보내는 셈이다. 어느 순간 apiserver가 CPU 100%에 도달했고, 모니터링이 클러스터를 죽이는 역설이 벌어졌다. 해결책은 폴링을 멈추는 게 아니라 watch로 바꾸는 것이었다.이 글이 푸는 질문: Kubernetes에서 수십 개의 컨트롤러가 동시에 돌면서 매번 "상태가 바뀌었나?"를 확인하는데, 왜 apiserver는 붕괴하지 않는가? 답은 list-watch 패턴과 리소스 버전(resourceVersi..
클러스터의 두뇌와 손 — 컨트롤 플레인과 노드가 어떻게 갈리는가한 클러스터에서 노드 3대가 동시에 재부팅됐다. Pod들은 전부 죽었고, 운영자는 "클러스터가 죽었다"고 보고했다. 하지만 정확히 무엇이 죽은 걸까? 재부팅된 노드 위의 kubelet은 다시 살아나자마자 apiserver에 "내가 돌아왔다, 내 담당 Pod들을 다시 띄워 달라"고 물었고, 90초 안에 Pod들이 복구됐다. 죽은 건 Pod였지 클러스터가 아니었다.이 사례가 보여주는 건 Kubernetes의 가장 중요한 분리 — 결정하는 층(컨트롤 플레인)과 실행하는 층(노드) — 이다. 이 분리를 이해하면 "무엇이 죽었는지, 그래서 무엇이 복구되는지"를 정확히 읽을 수 있다. 이 글은 그 두 층이 정확히 어떤 부품으로 이뤄지고 어떻게 통신하는지..
wall
방문 흔적을 남겨주세요. 질문이나 인사 모두 환영합니다.
