"메모리가 부족할 때 누구를 먼저 죽이나" — QoS가 결정하는 생존 서열한 노드에 10개의 Pod가 돌고 있었다. 메모리가 꽉 찼다. kubelet은 한 Pod를 골라 죽여야 했다. 그런데 왜 그 Pod였을까? 한 팀은 "랜덤인 줄 알았다"고 했다. 랜덤이 아니었다 — kubelet은 QoS(Quality of Service) 등급이라는 보이지 않는 서열에 따라 죽일 대상을 정한다. 그 서열을 모르면, 가장 중요한 Pod를 의도치 않게 가장 먼저 죽이는 대상으로 만든다.이 글이 푸는 것은: requests와 limits가 노드 자원을 어떻게 나누고, 그 결과 세 QoS 등급(Guaranteed/Burstable/BestEffort)이 어떻게 매겨지며, 노드 압박 시 누가 먼저 죽는가다.requests와..
왜 앱 설정을 이미지에 구우면 안 되는가 — ConfigMap과 Secret한 팀이 같은 앱을 개발/스테이징/운영 세 환경에 띄운다. 앱은 DB 호스트, API 키, 타임아웃 값을 설정 파일에서 읽는다. 처음엔 환경마다 이미지를 따로 빌드했다 — 설정 파일만 다른 이미지 세 개. 그러다 설정이 바뀔 때마다 빌드 3번, 푸시 3번, 배포 3번에 지쳤다. 그리고 깨달았다: 이미지는 코드여야지 환경 설정이어선 안 된다.이 글이 푸는 것은: Kubernetes가 ConfigMap(비기밀 설정)과 Secret(기밀 값)으로 "설정을 이미지에서 빼내는" 방법, 그리고 Secret이 사실 "비밀"이 아니라는 진실이다.설정은 세 가지로 주입된다Kubernetes에서 컨테이너에 설정을 넣는 방법은 세 가지다. 모두 Co..
Pod가 죽어도 데이터는 남아야 한다 — 볼륨에서 CSI까지의 한 단계한 팀이 Postgres를 Deployment로 띄웠다. Pod는 로컬 디스크에 데이터를 썼다. 어느 날 노드가 재부팅됐고 Pod는 다른 노드로 재생성됐다 — 그런데 데이터가 없었다. "Pod가 다시 돌아왔는데 왜 데이터가 없지?" 이 질문은 Kubernetes 스토리지 모델을 이해하지 못했을 때 반드시 부딪히는 벽이다.이 글이 푸는 것은: Kubernetes에서 "데이터를 영속시키려면" Pod의 로컬 파일시스템이 아니라 볼륨 추상화(Volume → PV/PVC → StorageClass → CSI)를 거쳐야 한다는 것, 그리고 각 단계가 왜 존재하는가다.Pod의 로컬 파일시스템은 Pod와 함께 죽는다가장 먼저 정리할 사실: 컨테이너의..
"이 Pod를 어느 노드에?" — 스케줄러가 매번 내리는 수십 개의 판단GPU가 달린 노드가 3대 있다. 머신러닝 추론 Pod를 배포했다. 그런데 스케줄러가 그것을 일반 CPU 노드에 올렸다. Pod는 GPU 없이 돌다가 OOM이 났고, 운영자는 "왜 스케줄러가 GPU 노드를 안 골랐지?"를 추적했다. 답은 간단했다 — 스케줄러는 Pod가 GPU를 원한다는 것을 몰랐다. 아무 요구도 명시하지 않았으니 가장 자원 여유가 큰 노드(일반 CPU 노드)를 골랐을 뿐이다.이 글이 푸는 것은: kube-scheduler가 "이 Pod를 어느 노드에?"를 어떻게 결정하고, 사용자가 그 결정을 어떻게 유도하는가다. 핵심은 스케줄링이 필터링 + 점수매기기의 두 단계라는 것과, 그 각 단계에 영향을 주는 네 가지 장치(n..
"모든 노드에 무조건 하나", "끝나고 죽는 Pod" — Deployment로 못 다루는 두 워크로드로그 수집 에이전트를 띄우려 한다. 요구사항은 단순하다: "클러스터의 모든 노드에 정확히 하나씩". 노드가 5대면 5개, 10대가 되면 10개. Deployment로 replicas: 5를 하면? 노드가 10대로 늘어도 여전히 5개 — 한 노드에 2개가 몰리거나 어떤 노드엔 아예 없을 수 있다. 요구사항을 만족 못 한다.또 다른 요구사항: "배치 작업을 돌려서 끝나면 사라지게". 그런데 Deployment의 Pod는 restartPolicy: Always라 영원히 재시작한다. "끝나면 그만"이라는 의미를 표현할 수가 없다.이 글은 Deployment가 다루지 못하는 두 부류의 워크로드 — 노드 단위(Dae..
Pod 이름이 매번 바뀌는데, 데이터베이스는 어떻게 클러스터를 이루나MySQL 3대로 Galera 클러스터를 세우려 한다. 각 노드는 "내가 노드 1번이고, 노드 2번은 저기, 노드 3번은 저기"라고 알아야 한다 — 서로를 안정적인 이름으로 부를 수 있어야 복제 토폴로지가 잡힌다. 그런데 04장에서 본 대로 일반 Pod는 죽을 때마다 이름이 바뀐다. "mysql-1"이 죽고 새 Pod가 "mysql-x7y9"로 살아나면, 다른 노드는 "내가 알던 노드가 사라졌네?"라고 혼란에 빠진다.이 글이 푸는 것은: Kubernetes가 상태 있는(stateful) 워크로드를 위해 StatefulSet으로 "안정된 정체(stable identity)"를 어떻게 보장하는가다. 핵심은 숫자다 — 0, 1, 2라는 순서가..
Archive
"메모리가 부족할 때 누구를 먼저 죽이나" — QoS가 결정하는 생존 서열한 노드에 10개의 Pod가 돌고 있었다. 메모리가 꽉 찼다. kubelet은 한 Pod를 골라 죽여야 했다. 그런데 왜 그 Pod였을까? 한 팀은 "랜덤인 줄 알았다"고 했다. 랜덤이 아니었다 — kubelet은 QoS(Quality of Service) 등급이라는 보이지 않는 서열에 따라 죽일 대상을 정한다. 그 서열을 모르면, 가장 중요한 Pod를 의도치 않게 가장 먼저 죽이는 대상으로 만든다.이 글이 푸는 것은: requests와 limits가 노드 자원을 어떻게 나누고, 그 결과 세 QoS 등급(Guaranteed/Burstable/BestEffort)이 어떻게 매겨지며, 노드 압박 시 누가 먼저 죽는가다.requests와..
왜 앱 설정을 이미지에 구우면 안 되는가 — ConfigMap과 Secret한 팀이 같은 앱을 개발/스테이징/운영 세 환경에 띄운다. 앱은 DB 호스트, API 키, 타임아웃 값을 설정 파일에서 읽는다. 처음엔 환경마다 이미지를 따로 빌드했다 — 설정 파일만 다른 이미지 세 개. 그러다 설정이 바뀔 때마다 빌드 3번, 푸시 3번, 배포 3번에 지쳤다. 그리고 깨달았다: 이미지는 코드여야지 환경 설정이어선 안 된다.이 글이 푸는 것은: Kubernetes가 ConfigMap(비기밀 설정)과 Secret(기밀 값)으로 "설정을 이미지에서 빼내는" 방법, 그리고 Secret이 사실 "비밀"이 아니라는 진실이다.설정은 세 가지로 주입된다Kubernetes에서 컨테이너에 설정을 넣는 방법은 세 가지다. 모두 Co..
Pod가 죽어도 데이터는 남아야 한다 — 볼륨에서 CSI까지의 한 단계한 팀이 Postgres를 Deployment로 띄웠다. Pod는 로컬 디스크에 데이터를 썼다. 어느 날 노드가 재부팅됐고 Pod는 다른 노드로 재생성됐다 — 그런데 데이터가 없었다. "Pod가 다시 돌아왔는데 왜 데이터가 없지?" 이 질문은 Kubernetes 스토리지 모델을 이해하지 못했을 때 반드시 부딪히는 벽이다.이 글이 푸는 것은: Kubernetes에서 "데이터를 영속시키려면" Pod의 로컬 파일시스템이 아니라 볼륨 추상화(Volume → PV/PVC → StorageClass → CSI)를 거쳐야 한다는 것, 그리고 각 단계가 왜 존재하는가다.Pod의 로컬 파일시스템은 Pod와 함께 죽는다가장 먼저 정리할 사실: 컨테이너의..
"이 Pod를 어느 노드에?" — 스케줄러가 매번 내리는 수십 개의 판단GPU가 달린 노드가 3대 있다. 머신러닝 추론 Pod를 배포했다. 그런데 스케줄러가 그것을 일반 CPU 노드에 올렸다. Pod는 GPU 없이 돌다가 OOM이 났고, 운영자는 "왜 스케줄러가 GPU 노드를 안 골랐지?"를 추적했다. 답은 간단했다 — 스케줄러는 Pod가 GPU를 원한다는 것을 몰랐다. 아무 요구도 명시하지 않았으니 가장 자원 여유가 큰 노드(일반 CPU 노드)를 골랐을 뿐이다.이 글이 푸는 것은: kube-scheduler가 "이 Pod를 어느 노드에?"를 어떻게 결정하고, 사용자가 그 결정을 어떻게 유도하는가다. 핵심은 스케줄링이 필터링 + 점수매기기의 두 단계라는 것과, 그 각 단계에 영향을 주는 네 가지 장치(n..
"모든 노드에 무조건 하나", "끝나고 죽는 Pod" — Deployment로 못 다루는 두 워크로드로그 수집 에이전트를 띄우려 한다. 요구사항은 단순하다: "클러스터의 모든 노드에 정확히 하나씩". 노드가 5대면 5개, 10대가 되면 10개. Deployment로 replicas: 5를 하면? 노드가 10대로 늘어도 여전히 5개 — 한 노드에 2개가 몰리거나 어떤 노드엔 아예 없을 수 있다. 요구사항을 만족 못 한다.또 다른 요구사항: "배치 작업을 돌려서 끝나면 사라지게". 그런데 Deployment의 Pod는 restartPolicy: Always라 영원히 재시작한다. "끝나면 그만"이라는 의미를 표현할 수가 없다.이 글은 Deployment가 다루지 못하는 두 부류의 워크로드 — 노드 단위(Dae..
Pod 이름이 매번 바뀌는데, 데이터베이스는 어떻게 클러스터를 이루나MySQL 3대로 Galera 클러스터를 세우려 한다. 각 노드는 "내가 노드 1번이고, 노드 2번은 저기, 노드 3번은 저기"라고 알아야 한다 — 서로를 안정적인 이름으로 부를 수 있어야 복제 토폴로지가 잡힌다. 그런데 04장에서 본 대로 일반 Pod는 죽을 때마다 이름이 바뀐다. "mysql-1"이 죽고 새 Pod가 "mysql-x7y9"로 살아나면, 다른 노드는 "내가 알던 노드가 사라졌네?"라고 혼란에 빠진다.이 글이 푸는 것은: Kubernetes가 상태 있는(stateful) 워크로드를 위해 StatefulSet으로 "안정된 정체(stable identity)"를 어떻게 보장하는가다. 핵심은 숫자다 — 0, 1, 2라는 순서가..
wall
방문 흔적을 남겨주세요. 질문이나 인사 모두 환영합니다.
