N° 01 — 목록

'분류 전체보기' (197)

  1. Cloud & Infrastructure/Kubernetes

    Kubernetes - 08. scheduling

    "이 Pod를 어느 노드에?" — 스케줄러가 매번 내리는 수십 개의 판단GPU가 달린 노드가 3대 있다. 머신러닝 추론 Pod를 배포했다. 그런데 스케줄러가 그것을 일반 CPU 노드에 올렸다. Pod는 GPU 없이 돌다가 OOM이 났고, 운영자는 "왜 스케줄러가 GPU 노드를 안 골랐지?"를 추적했다. 답은 간단했다 — 스케줄러는 Pod가 GPU를 원한다는 것을 몰랐다. 아무 요구도 명시하지 않았으니 가장 자원 여유가 큰 노드(일반 CPU 노드)를 골랐을 뿐이다.이 글이 푸는 것은: kube-scheduler가 "이 Pod를 어느 노드에?"를 어떻게 결정하고, 사용자가 그 결정을 어떻게 유도하는가다. 핵심은 스케줄링이 필터링 + 점수매기기의 두 단계라는 것과, 그 각 단계에 영향을 주는 네 가지 장치(n..

    · 댓글
  2. Cloud & Infrastructure/Kubernetes

    Kubernetes - 07. daemonset job cronjob

    "모든 노드에 무조건 하나", "끝나고 죽는 Pod" — Deployment로 못 다루는 두 워크로드로그 수집 에이전트를 띄우려 한다. 요구사항은 단순하다: "클러스터의 모든 노드에 정확히 하나씩". 노드가 5대면 5개, 10대가 되면 10개. Deployment로 replicas: 5를 하면? 노드가 10대로 늘어도 여전히 5개 — 한 노드에 2개가 몰리거나 어떤 노드엔 아예 없을 수 있다. 요구사항을 만족 못 한다.또 다른 요구사항: "배치 작업을 돌려서 끝나면 사라지게". 그런데 Deployment의 Pod는 restartPolicy: Always라 영원히 재시작한다. "끝나면 그만"이라는 의미를 표현할 수가 없다.이 글은 Deployment가 다루지 못하는 두 부류의 워크로드 — 노드 단위(Dae..

    · 댓글
  3. Cloud & Infrastructure/Kubernetes

    Kubernetes - 06. statefulset

    Pod 이름이 매번 바뀌는데, 데이터베이스는 어떻게 클러스터를 이루나MySQL 3대로 Galera 클러스터를 세우려 한다. 각 노드는 "내가 노드 1번이고, 노드 2번은 저기, 노드 3번은 저기"라고 알아야 한다 — 서로를 안정적인 이름으로 부를 수 있어야 복제 토폴로지가 잡힌다. 그런데 04장에서 본 대로 일반 Pod는 죽을 때마다 이름이 바뀐다. "mysql-1"이 죽고 새 Pod가 "mysql-x7y9"로 살아나면, 다른 노드는 "내가 알던 노드가 사라졌네?"라고 혼란에 빠진다.이 글이 푸는 것은: Kubernetes가 상태 있는(stateful) 워크로드를 위해 StatefulSet으로 "안정된 정체(stable identity)"를 어떻게 보장하는가다. 핵심은 숫자다 — 0, 1, 2라는 순서가..

    · 댓글
  4. Cloud & Infrastructure/Kubernetes

    Kubernetes - 05. deployment

    새 버전을 띄우는 동안 옛 버전이 트래픽을 받는 찰나를 누가 만드는가한 팀이 금요일 오후에 새 버전을 배포했다. 컨테이너를 5개 돌리던 서비스였다. 가장 단순한 방법은 옛 컨테이너 5개를 전부 죽이고 새 5개를 띄우는 것이다 — 하지만 그러면 배포 중 몇 분간 서비스가 완전히 죽는다. 그래서 그들은 컨테이너를 하나씩만 바꿨다: 옛 것 1개를 죽이고 새 것 1개를 띄우길 5번 반복. 이 사이에 "옛 버전과 새 버전이 동시에 돌면서 각자 트래픽을 받는" 찰나가 생긴다. 문제는 — 이 찰나를 손으로 관리하면 어느 순간 꼬인다는 것이다.이 글이 푸는 것은: Kubernetes의 Deployment가 이 "점진적 교체"를 어떻게 자동화하고, 왜 그것이 replicas 선언 하나로 가능한가다.Deployment는 ..

    · 댓글
  5. Cloud & Infrastructure/Kubernetes

    Kubernetes - 04. pod

    왜 컨테이너 하나만 띄우면 "Pod"라는 포대까지 필요한가처음 Kubernetes를 배우는 사람은 거의 다 같은 의문을 갖는다. 컨테이너를 하나 띄우고 싶을 뿐인데, 왜 kind: Pod에 containers: 배열을 넣고 그 안에 컨테이너를 적어야 하나? Docker처럼 그냥 컨테이너를 실행하면 안 되나?이 질문은 사소해 보이지만 Kubernetes의 가장 근본적인 설계 결정을 건드린다. 왜 Kubernetes는 컨테이너를 직접 다루지 않고 Pod라는 한 겹 더 두른 단위를 배포의 최소 단위로 삼았는가? 이 글의 답은 단순하다 — Pod는 컨테이너가 아니라 "함께 죽고 함께 사는 컨테이너들의 묶음"이며, 이 묶음이 공유하는 것(네트워크·스토리지·생명)이 Kubernetes의 모델을 만든다.Pod는 컨테..

    · 댓글
  6. Cloud & Infrastructure/Kubernetes

    Kubernetes - 03. api machinery

    한 번 쓰고 영원히 본다 — watch/list가 조정 루프를 어떻게 지탱하는가kubectl get pods를 1초마다 돌리는 모니터링 스크립트를 본 적이 있다. 잘 동작했지만 apiserver에 1초마다 전체 Pod 목록을 요청했다 — 클러스터에 Pod가 5000개면 매초 5000개를 직렬화해 보내는 셈이다. 어느 순간 apiserver가 CPU 100%에 도달했고, 모니터링이 클러스터를 죽이는 역설이 벌어졌다. 해결책은 폴링을 멈추는 게 아니라 watch로 바꾸는 것이었다.이 글이 푸는 질문: Kubernetes에서 수십 개의 컨트롤러가 동시에 돌면서 매번 "상태가 바뀌었나?"를 확인하는데, 왜 apiserver는 붕괴하지 않는가? 답은 list-watch 패턴과 리소스 버전(resourceVersi..

    · 댓글