Kubernetes

Q&A 모음

Q1. Deployment와 StatefulSet의 차이는? A. Deployment는 Pod가 서로 완전히 대체 가능하다고 가정해 무작위 이름을 붙이고 로드밸런싱하지만, StatefulSet은 각 Pod에 순서 있는 고유 인덱스(web-0, web-1...)를 부여해 죽었다 재생성돼도 같은 정체성을 유지한다. 리더/샤드 역할이 고정돼야 하는 분산 데이터베이스류에 StatefulSet을 쓴다. (k8s-learn-02, 03)

Q2. requests와 limits의 차이는? A. requests는 스케줄러가 노드를 고르는 기준('최소 이만큼 필요'), limits는 런타임 상한이다 — CPU는 초과 시 스로틀링, 메모리는 초과 시 OOMKilled로 강제 종료된다. (k8s-learn-05)

Q3. Pod의 QoS 클래스는 어떻게 정해지고, 노드 압박 시 축출 순서는? A. requests/limits 설정 상태로 Kubernetes가 자동 계산한다 — 모든 컨테이너가 CPU·메모리 request=limit이면 Guaranteed, 하나라도 설정됐지만 그 조건을 못 채우면 Burstable, 아무것도 설정 안 하면 BestEffort. 축출은 BestEffort→Burstable→Guaranteed 순이며, requests를 초과해서 쓰는 Pod만 대상이 된다. (k8s-learn-05)

Q4. liveness/readiness/startup probe의 차이는? A. liveness 실패는 컨테이너 재시작, readiness 실패는 재시작 없이 Service 엔드포인트에서만 제외(트래픽 차단), startup은 성공 전까지 다른 두 프로브 실행 자체를 지연시켜 느린 초기화 앱의 오탐 재시작을 막는다. (k8s-learn-06)

Q5. StatefulSet에 헤드리스 서비스를 함께 쓰는 이유는? A. 일반 Service는 단일 가상 IP로 로드밸런싱해 특정 Pod를 지목할 수 없지만, 헤드리스 서비스(clusterIP: None)는 Pod마다 개별 DNS 레코드를 만들어 `web-0.서비스이름`처럼 특정 Pod에 직접 접속할 수 있게 한다 — StatefulSet의 순서 있는 정체성을 DNS까지 확장하는 것. (k8s-learn-03)

Q6. NodePort와 LoadBalancer의 관계는? A. 독립적인 대안이 아니라 계층 구조다 — NodePort는 ClusterIP 기능을 포함한 채 모든 노드의 고정 포트로도 접근 가능하게 하고, LoadBalancer는 그 NodePort 위에 클라우드 외부 로드밸런서를 얹은 것이라 NodePort·ClusterIP를 전부 가진다. (k8s-learn-04)

Q7. Pod가 Pending에서 안 움직인다. 어떻게 진단하는가? A. 자원 부족(요청만큼 여유 있는 노드 없음), nodeSelector/affinity 불일치, taint-toleration 불일치, PVC 미바인딩이 대표 원인이다. 원인을 하나씩 추측하기보다 `kubectl describe pod`의 Events 섹션을 먼저 보면 스케줄러가 남긴 실패 사유 메시지로 바로 좁혀진다. (k8s-learn-07)

Q8. 컨트롤 플레인 컴포넌트 중 실제 컨테이너를 기동하는 건 무엇인가? A. 컨트롤 플레인 자체는 아무것도 직접 기동하지 않는다 — 스케줄러가 '어느 노드에 배정할지'만 결정해 API 서버(및 etcd)에 기록하면, 그 노드의 kubelet이 이를 감지해 컨테이너 런타임에게 실제 컨테이너 기동을 지시한다. (k8s-learn-01)