컨테이너를 안정적으로 운영하는 엔지니어가 되는 트랙

kubectl로 nginx Pod를 생성하고 Deployment와 Service를 차례로 만들어 클러스터 외부에서 접근 가능한 상태까지 구성한다. K8s 3대 리소스의 역할과 관계를 직접 손으로 익힌다.

배포 직후 Pod가 CrashLoopBackOff 상태에 빠졌다. kubectl 명령으로 원인을 진단하고 Deployment를 수정해 정상 상태로 복구한다.

신규 배포한 api-service에 클라이언트 연결이 안 된다. Pod는 Running이고 Service도 있는데 왜? selector-label 불일치 → Endpoint 없음 → DNS 해석 실패 전체 흐름을 직접 디버깅하고 복구한다.

DB URL 같은 설정값은 ConfigMap으로, API 키 같은 민감 정보는 Secret으로 분리해 Deployment에 환경변수로 주입한다. 컨테이너 이미지와 설정을 완전히 분리하는 12-Factor App 원칙을 직접 적용한다.

신규 버전을 배포했더니 CrashLoopBackOff가 쏟아진다. 서비스는 살려두면서 이전 버전으로 60초 안에 롤백해야 한다. RollingUpdate 전략의 동작 원리와 kubectl rollout 명령을 완전히 익힌다.

Pod가 주기적으로 재시작되고 kubectl describe에서 OOMKilled 메시지를 확인한 후, 메모리 사용량을 분석하고 resources.requests/limits를 적절히 설정해 안정화한다.

Horizontal Pod Autoscaler(HPA)를 구성해 CPU 사용량이 70%를 초과할 때 Pod를 자동으로 늘리고, 부하가 줄면 다시 줄이는 오토스케일링 동작을 직접 확인한다.

port-forward로 파드는 되는데 도메인 접속만 404/503이다. Ingress 라우팅은 Ingress→Service→Endpoints(Pod)의 사슬이다. 어느 고리가 끊겼는지(호스트/경로 규칙, 서비스 셀렉터, 엔드포인트 비어있음, Ingress 컨트롤러)를 단계별로 좁혀 특정하고 복구한다.

PVC를 쓰는 파드가 Pending에서 멈췄다. PVC 바인딩은 PVC(요청)↔StorageClass(프로비저너)↔PV(실제 볼륨)의 협상이다. 왜 바인딩이 안 되는지(StorageClass 없음·용량/접근모드 불일치·프로비저너 미동작)를 진단하고, 데이터가 Pod 재시작/재스케줄에도 살아남는지 영속성을 검증한다.

CI의 서비스 계정이 "forbidden"으로 막혔다. RBAC은 주체(ServiceAccount)–역할(Role/ClusterRole)–바인딩(RoleBinding)의 연결이다. forbidden 메시지를 해독하고(누가·어떤 동작·어떤 리소스·어떤 네임스페이스), can-i로 권한을 확인하고, 필요한 동작만 담은 Role을 만들어 바인딩한다. cluster-admin 남발 없이 최소 권한으로 푼다.