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