새 버전을 띄우는 동안 옛 버전이 트래픽을 받는 찰나를 누가 만드는가한 팀이 금요일 오후에 새 버전을 배포했다. 컨테이너를 5개 돌리던 서비스였다. 가장 단순한 방법은 옛 컨테이너 5개를 전부 죽이고 새 5개를 띄우는 것이다 — 하지만 그러면 배포 중 몇 분간 서비스가 완전히 죽는다. 그래서 그들은 컨테이너를 하나씩만 바꿨다: 옛 것 1개를 죽이고 새 것 1개를 띄우길 5번 반복. 이 사이에 "옛 버전과 새 버전이 동시에 돌면서 각자 트래픽을 받는" 찰나가 생긴다. 문제는 — 이 찰나를 손으로 관리하면 어느 순간 꼬인다는 것이다.이 글이 푸는 것은: Kubernetes의 Deployment가 이 "점진적 교체"를 어떻게 자동화하고, 왜 그것이 replicas 선언 하나로 가능한가다.Deployment는 ..
왜 컨테이너 하나만 띄우면 "Pod"라는 포대까지 필요한가처음 Kubernetes를 배우는 사람은 거의 다 같은 의문을 갖는다. 컨테이너를 하나 띄우고 싶을 뿐인데, 왜 kind: Pod에 containers: 배열을 넣고 그 안에 컨테이너를 적어야 하나? Docker처럼 그냥 컨테이너를 실행하면 안 되나?이 질문은 사소해 보이지만 Kubernetes의 가장 근본적인 설계 결정을 건드린다. 왜 Kubernetes는 컨테이너를 직접 다루지 않고 Pod라는 한 겹 더 두른 단위를 배포의 최소 단위로 삼았는가? 이 글의 답은 단순하다 — Pod는 컨테이너가 아니라 "함께 죽고 함께 사는 컨테이너들의 묶음"이며, 이 묶음이 공유하는 것(네트워크·스토리지·생명)이 Kubernetes의 모델을 만든다.Pod는 컨테..
한 번 쓰고 영원히 본다 — 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의 가장 중요한 분리 — 결정하는 층(컨트롤 플레인)과 실행하는 층(노드) — 이다. 이 분리를 이해하면 "무엇이 죽었는지, 그래서 무엇이 복구되는지"를 정확히 읽을 수 있다. 이 글은 그 두 층이 정확히 어떤 부품으로 이뤄지고 어떻게 통신하는지..
Kubernetes는 컨테이너를 실행하지 않는다2014년 즈음, 한 팀이 매일 새벽 서버 50대에 SSH로 접속해 같은 설정을 복사하고 있었다. 컨테이너는 이미 있었다. Docker가 "한 번 빌드하면 어디서든 돌아간다"고 약속했고, 실제로 그랬다. 그런데 팀은 여전히 밤을 새웠다. 컨테이너를 실행하는 일은 해결됐는데, "어디에, 몇 개를, 어떻게 계속 띄워 둘까"를 결정하는 일은 사람이 하고 있었다.이 글이 푸는 질문은 하나다. Kubernetes는 정확히 이 "결정"의 어느 부분을 가져갔는가? 그리고 왜 그 방식(선언적 API + 조정 루프)이 컨테이너를 더 빨리 띄우는 것보다 훨씬 근본적인 변화였는가?Kubernetes가 "실행"하지 않는다는 것의 의미흔한 오해부터 꺼내자. Kubernetes는 컨..
Archive
새 버전을 띄우는 동안 옛 버전이 트래픽을 받는 찰나를 누가 만드는가한 팀이 금요일 오후에 새 버전을 배포했다. 컨테이너를 5개 돌리던 서비스였다. 가장 단순한 방법은 옛 컨테이너 5개를 전부 죽이고 새 5개를 띄우는 것이다 — 하지만 그러면 배포 중 몇 분간 서비스가 완전히 죽는다. 그래서 그들은 컨테이너를 하나씩만 바꿨다: 옛 것 1개를 죽이고 새 것 1개를 띄우길 5번 반복. 이 사이에 "옛 버전과 새 버전이 동시에 돌면서 각자 트래픽을 받는" 찰나가 생긴다. 문제는 — 이 찰나를 손으로 관리하면 어느 순간 꼬인다는 것이다.이 글이 푸는 것은: Kubernetes의 Deployment가 이 "점진적 교체"를 어떻게 자동화하고, 왜 그것이 replicas 선언 하나로 가능한가다.Deployment는 ..
왜 컨테이너 하나만 띄우면 "Pod"라는 포대까지 필요한가처음 Kubernetes를 배우는 사람은 거의 다 같은 의문을 갖는다. 컨테이너를 하나 띄우고 싶을 뿐인데, 왜 kind: Pod에 containers: 배열을 넣고 그 안에 컨테이너를 적어야 하나? Docker처럼 그냥 컨테이너를 실행하면 안 되나?이 질문은 사소해 보이지만 Kubernetes의 가장 근본적인 설계 결정을 건드린다. 왜 Kubernetes는 컨테이너를 직접 다루지 않고 Pod라는 한 겹 더 두른 단위를 배포의 최소 단위로 삼았는가? 이 글의 답은 단순하다 — Pod는 컨테이너가 아니라 "함께 죽고 함께 사는 컨테이너들의 묶음"이며, 이 묶음이 공유하는 것(네트워크·스토리지·생명)이 Kubernetes의 모델을 만든다.Pod는 컨테..
한 번 쓰고 영원히 본다 — 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의 가장 중요한 분리 — 결정하는 층(컨트롤 플레인)과 실행하는 층(노드) — 이다. 이 분리를 이해하면 "무엇이 죽었는지, 그래서 무엇이 복구되는지"를 정확히 읽을 수 있다. 이 글은 그 두 층이 정확히 어떤 부품으로 이뤄지고 어떻게 통신하는지..
Kubernetes는 컨테이너를 실행하지 않는다2014년 즈음, 한 팀이 매일 새벽 서버 50대에 SSH로 접속해 같은 설정을 복사하고 있었다. 컨테이너는 이미 있었다. Docker가 "한 번 빌드하면 어디서든 돌아간다"고 약속했고, 실제로 그랬다. 그런데 팀은 여전히 밤을 새웠다. 컨테이너를 실행하는 일은 해결됐는데, "어디에, 몇 개를, 어떻게 계속 띄워 둘까"를 결정하는 일은 사람이 하고 있었다.이 글이 푸는 질문은 하나다. Kubernetes는 정확히 이 "결정"의 어느 부분을 가져갔는가? 그리고 왜 그 방식(선언적 API + 조정 루프)이 컨테이너를 더 빨리 띄우는 것보다 훨씬 근본적인 변화였는가?Kubernetes가 "실행"하지 않는다는 것의 의미흔한 오해부터 꺼내자. Kubernetes는 컨..
wall
방문 흔적을 남겨주세요. 질문이나 인사 모두 환영합니다.
