Kubernetes 입문과 도입 판단
3줄 요약
- Kubernetes는 컨테이너 실행, 배포, 라우팅, 설정 주입, 자원 격리를 표준 리소스로 선언하게 해 준다.
- Pod, Deployment, Service, Ingress, ConfigMap, Secret, Volume, Probe, Resource Limit은 Spring 백엔드 운영의 실패 경계를 나누는 단위다.
- 도입 판단은 “쓸 수 있는가”보다 “운영 복잡도를 감당할 팀, 관측, 배포, 권한 체계가 있는가”를 기준으로 해야 한다.
핵심 정리
- Pod는 실행 단위이고 Deployment는 원하는 Pod 수와 배포 전략을 유지하는 controller다.
- Service는 변하는 Pod IP 앞에 안정적인 접근 지점을 만들고, Ingress는 외부 HTTP 요청을 Service로 라우팅한다.
- ConfigMap은 일반 설정, Secret은 민감 정보, Volume은 파일 형태의 설정이나 저장소 연결을 다룬다.
- Probe는 트래픽을 받을 준비와 재시작 기준을 구분하고, resource request/limit은 배치와 장애 격리에 영향을 준다.
- Kubernetes는 self-healing과 표준화를 주지만 manifest, RBAC, 관측, 장애 분석, 비용이라는 운영 부담을 늘린다.
- 개인 프로젝트는 학습 목적과 운영 목적을 분리하고, 팀 서비스는 배포 빈도와 운영 역량을 기준으로 도입을 판단한다.
헷갈리는 지점
- Pod가 Running이면 서비스도 정상이라고 생각하기 쉽다.
- readiness, Service endpoint, Ingress rule, 애플리케이션 로그까지 확인해야 요청 처리 가능성을 알 수 있다.
- Secret을 쓰면 자동으로 안전하다고 오해하기 쉽다.
- 기본 Secret은 접근 제어와 암호화 설정, 회전 절차, 출력 공유 통제가 함께 있어야 안전하다.
- Kubernetes가 단순히 배포를 쉽게 해 준다고 보기 쉽다.
- 배포 자동화는 강해지지만 장애 분석 경로와 운영 책임도 더 많아진다.
확인 질문
- Service와 Ingress는 각각 무엇을 해결하는가?
- Service는 Pod 집합의 안정적인 내부 접근 지점을 만들고, Ingress는 외부 HTTP 요청을 Service로 라우팅한다.
- readiness와 liveness를 분리해야 하는 이유는 무엇인가?
- 요청을 잠시 받지 못하는 상태와 컨테이너를 재시작해야 하는 상태가 다르기 때문이다.
- 개인 프로젝트에서 Kubernetes 도입을 보류해도 되는 신호는 무엇인가?
- 서비스 수가 적고 배포 빈도가 낮으며 VM 또는 Compose로 장애 대응이 충분히 단순한 경우다.