Kubernetes 기초 설계 가이드
Pod는 실행 단위지만 운영 단위는 아니다
Pod는 컨테이너가 실제로 돌아가는 최소 단위입니다. 하지만 직접 Pod를 다루기보다 대부분은 Deployment 같은 상위 리소스로 관리합니다. Pod는 죽고 다시 생길 수 있는 존재이기 때문에, IP 고정이나 로컬 상태 의존 설계는 위험합니다.
Deployment는 원하는 상태를 유지한다
Deployment의 핵심은 현재 상태를 선언한 원하는 상태로 맞춰 간다는 점입니다. 버전 롤아웃, 롤백, replica 수 조정이 모두 이 모델 위에서 동작합니다.
Service는 네트워크 불안정을 숨긴다
Pod는 계속 바뀌지만 Service는 안정적인 접근 지점을 제공합니다. 앱끼리 직접 Pod IP를 바라보지 않고 Service 이름을 통해 통신하는 이유가 여기에 있습니다.
ConfigMap과 Secret은 설정 경계를 만든다
애플리케이션 이미지에 환경별 값을 박아 넣지 않고 외부 설정으로 분리하면, 같은 이미지를 여러 환경에 배포하기 쉬워집니다. 다만 Secret은 base64 인코딩일 뿐 암호화 그 자체는 아니라는 점을 기억해야 합니다.
YAML보다 더 중요한 것은 운영 질문
Kubernetes를 쓴다는 것은 단순 배포 스크립트 교체가 아닙니다. readiness probe를 어떻게 둘지, 자원 요청과 제한을 어떻게 잡을지, 장애 시 재시작만으로 충분한지, 로그와 메트릭은 어디서 볼지 같은 질문이 따라옵니다.
자주 하는 실수
Pod를 VM처럼 생각해 ssh 접속과 로컬 파일 상태에 의존하는 경우가 많습니다. 또 requests/limits 없이 배포하거나, liveness/readiness를 같은 의미로 설정해 장애를 키우는 경우도 흔합니다.
마무리
Kubernetes 기초의 핵심은 리소스 종류를 외우는 것이 아니라, 선언형 운영 모델을 이해하는 것입니다. Pod, Deployment, Service, ConfigMap이 각각 어떤 문제를 해결하는지 알면 복잡한 클러스터도 훨씬 읽기 쉬워집니다.
운영 환경에서 어려워지는 지점
- 쿠버네티스 기본기는 pod, service, deployment를 단순 YAML 객체로만 보면 쉽게 오용되기 때문에 중요하다.
- 초기 고통의 대부분은 스케줄링, 네트워킹, 헬스 관리에 대한 정신 모델 부족에서 나온다.
- 컨트롤 플레인은 운영을 자동화하지만 애플리케이션 규율까지 대신해주지는 않는다.
중요한 아키텍처 결정
- pod는 내구 서버가 아니라 일시적인 실행 단위로 본다.
- resource request, probe, rollout 동작을 처음부터 의도적으로 선언한다.
- 클러스터 관심사와 애플리케이션 관심사를 분리해 YAML을 읽기 가능하게 유지한다.
실무 예시
운영을 고려한 최소 배포는 헬스와 자원 기대치를 명시적으로 적는다.
resources:
requests:
cpu: 100m
memory: 256Mi
livenessProbe:
readinessProbe:
피해야 할 안티패턴
- readiness나 liveness 전략 없이 컨테이너를 배포하는 것.
- stateless deployment 안에 stateful 가정을 넣는 것.
- 스케줄링 결과를 이해하지 않고 manifest를 복사해 쓰는 것.
운영 체크리스트
- 실사용량과 비교해 request/limit를 검토한다.
- rollout과 rollback 경로를 테스트한다.
- pod 재시작 패턴과 probe 실패를 관찰한다.
- manifest를 버전 관리하고 환경 차이를 분명히 한다.
최종 판단
쿠버네티스 기본기는 객체 이름이 아니라 런타임 동작을 이해하는 일이다. 실행 모델을 초기에 익힌 팀이 피할 수 있는 장애를 훨씬 많이 피한다.
Continue Reading
다음으로 읽기 좋은 글
Kubernetes 클러스터 유형 완전 가이드
단일 노드부터 고가용성, 관리형, 멀티 클러스터까지 Kubernetes 클러스터 유형별 구조, 선택 기준, 구성 방법, 운영 트레이드오프를 실무 관점으로 정리합니다.
🚀 DevOpsKubernetes 심화 — HPA, Resource 관리, Pod Scheduling
Kubernetes 운영을 설정 모음이 아니라 자원 배치와 장애 복원력의 관점에서 정리합니다. requests/limits, HPA, affinity, taint, PDB, probe를 언제 어떻게 써야 하는지 실무적으로 설명합니다.
📚 IT 이야기컨테이너와 쿠버네티스는 어떻게 배포의 감각을 바꿨나
한때 배포는 늘 불안한 행사처럼 느껴졌지만, 컨테이너와 쿠버네티스는 그것을 더 반복 가능하고 더 자동화된 일상으로 바꾸려 했습니다.
📈 최신 동향Kubernetes v1.34 에서 플랫폼 팀이 봐야 할 것
Kubernetes v1.34 릴리스를 플랫폼 팀 관점에서 읽어내며 운영, 워크로드 설계, 클러스터 거버넌스에 중요한 변화만 추려 정리한 글입니다.
다음 탐색