이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- Kubernetes는 컨테이너 운영에서 어떤 문제를 해결하는가?
- Kubernetes 도입이 새로 만드는 운영 비용은 무엇인가?
- Spring 백엔드 팀은 도입 전 어떤 준비 상태를 확인해야 하는가?
개요
Kubernetes는 여러 컨테이너를 선언한 상태에 맞게 실행하고, 네트워크와 설정과 자원 경계를 표준화하는 플랫폼이다.
컨테이너가 많아지고 배포가 잦아지면 VM이나 단일 Compose 환경만으로 운영하기 어려워진다.
Kubernetes는 이런 문제를 줄여 주지만 무료로 단순함을 주지는 않는다.
새로운 추상화, 권한 체계, 관측 체계, 장애 분석 경로, 비용 구조가 생긴다.
도입 판단은 “많이 쓰니까”가 아니라 우리 팀의 운영 문제와 비용을 비교해서 해야 한다.
해결하는 문제
Kubernetes가 잘 해결하는 문제는 다음과 같다.
- 컨테이너를 여러 노드에 배치한다.
- 죽은 컨테이너를 다시 만든다.
- 새 버전을 점진적으로 배포한다.
- Service discovery와 내부 트래픽 라우팅을 제공한다.
- 설정과 Secret을 이미지 밖에서 주입한다.
- resource request/limit으로 자원 경계를 둔다.
- workload 수를 scale-out할 수 있다.
- namespace와 RBAC로 팀/환경 경계를 나눌 수 있다.
이 장점은 서비스 수가 늘고 팀이 커질수록 가치가 커진다.
하나의 Spring API와 하나의 DB만 있는 상황에서는 장점보다 복잡도가 클 수 있다.
새로 생기는 비용
Kubernetes를 도입하면 다음 비용이 생긴다.
- manifest와 controller 개념을 배워야 한다.
- Pod, Service, Ingress, Secret, Volume 관계를 디버깅해야 한다.
- cluster add-on, ingress controller, metrics, log 수집을 운영해야 한다.
- RBAC와 namespace 권한을 설계해야 한다.
- resource request/limit을 서비스별로 조정해야 한다.
- 배포 도구와 image registry 권한을 관리해야 한다.
- 로컬 개발 환경과 운영 환경 차이가 커질 수 있다.
- managed Kubernetes를 써도 node, 비용, network, upgrade 책임이 남는다.
운영 비용을 과소평가하면 도입 후 장애 분석 시간이 더 길어진다.
Spring 백엔드 관점
Spring 서비스가 Kubernetes에 올라가면 애플리케이션 설정도 바뀐다.
- graceful shutdown이 필요하다.
- readiness가 준비 상태를 정확히 표현해야 한다.
- liveness가 일시적 장애를 재시작 폭주로 만들면 안 된다.
- JVM memory 설정이 container limit과 맞아야 한다.
- DB connection pool 합계가 replica 수와 함께 계산되어야 한다.
- log는 stdout/stderr로 수집되기 쉽게 남겨야 한다.
- transaction 중 종료되는 경우를 고려해야 한다.
Kubernetes는 Spring 애플리케이션의 운영 계약을 더 명확히 요구한다.
도입 전 준비 상태
도입 전 다음 질문에 답할 수 있어야 한다.
- image build와 registry push가 안정적인가?
- 배포 실패 시 이전 버전으로 돌아가는 절차가 있는가?
- 로그와 metric을 Pod 단위가 아니라 서비스 단위로 볼 수 있는가?
- Secret 관리 방식이 정해져 있는가?
- namespace, RBAC, service account 책임자가 있는가?
- ingress, certificate, DNS 운영자가 정해져 있는가?
- resource request/limit을 정할 부하 데이터가 있는가?
- 장애 중
kubectl describe, event, log를 읽을 사람이 있는가?
이 준비가 없다면 Kubernetes는 배포 자동화보다 장애 분석 복잡도를 먼저 키울 수 있다.
장애 신호
- manifest는 적용됐지만 어떤 controller가 상태를 못 맞추는지 모른다.
- Pod 로그는 보지만 event와 endpoint를 보지 않는다.
- resource limit을 복사해 쓰다가 서비스별 OOMKilled가 반복된다.
- namespace 권한이 넓어 Secret 접근 범위를 통제하지 못한다.
- ingress controller나 certificate 문제를 애플리케이션 장애로 오해한다.
- HPA가 scale-out해도 DB connection limit 때문에 장애가 커진다.
- 팀원이 한 명만 Kubernetes 운영을 이해한다.
이 신호는 도입 자체보다 운영 체계가 부족하다는 뜻이다.
안전한 도입 방식
- 처음부터 모든 서비스를 옮기지 말고 stateless API 한 개로 시작한다.
- 배포, 관측, Secret, rollback을 먼저 표준화한다.
- ingress와 certificate 운영 책임을 명확히 한다.
- resource request/limit은 부하 테스트와 운영 metric으로 조정한다.
- DB, message broker 같은 stateful 구성은 충분히 숙련된 뒤 판단한다.
- 운영 문서에는 명령뿐 아니라 실패 신호와 완화 절차를 적는다.
도입 범위를 작게 잡으면 Kubernetes 학습과 실제 운영 문제를 구분하기 쉽다.
하지 말아야 할 대응
- 장애 대응 체계 없이 production workload부터 옮기지 않는다.
- 모든 값을 sample YAML에서 복사해 그대로 쓰지 않는다.
- 로그 수집과 metric 없이 Pod 수만 늘리지 않는다.
- RBAC 없이 팀 전체에 넓은 권한을 주지 않는다.
- Kubernetes를 쓰면 자동으로 무중단 배포가 된다고 가정하지 않는다.
인프라 담당자와 공유할 자료
- 도입 목적: 배포 표준화, scale-out, multi-service 운영, 학습 중 무엇인지
- 옮길 서비스와 제외할 서비스
- 필요한 namespace, ingress, certificate, DNS
- resource request/limit 초안과 근거
- Secret 관리 방식
- 로그/metric 수집 방식
- 장애 대응 담당자와 rollback 절차
공유 자료는 기술 선택 이유와 운영 책임을 함께 보여 줘야 한다.
운영 체크리스트
- Kubernetes가 해결할 현재 운영 문제가 명확한가?
- 도입으로 새로 생기는 비용을 팀이 감당할 수 있는가?
- 배포/관측/권한/Secret/runbook이 준비되었는가?
- Spring 애플리케이션의 graceful shutdown과 probe가 준비되었는가?
- DB connection과 replica 수가 함께 계산되었는가?
- 도입 실패 시 기존 운영 방식으로 돌아갈 수 있는가?
확인 질문
확인 질문
- Kubernetes가 잘 해결하는 대표 문제는 무엇인가?
- 컨테이너 배치, 재생성, 점진 배포, service discovery, 설정 주입, 자원 격리다.
- Kubernetes 도입이 만드는 새 비용은 무엇인가?
- manifest, 권한, 관측, network, resource 조정, upgrade, 장애 분석 복잡도다.
- Spring 팀이 도입 전 반드시 준비해야 할 것은 무엇인가?
- image 배포, probe, graceful shutdown, 로그/metric, Secret, rollback, DB connection 계산이다.
리뷰 체크포인트
- 도입 목적이 현재 운영 문제와 연결되어 있는가?
- 운영 비용이 구체적으로 적혀 있는가?
- Spring 애플리케이션 수정 필요 사항이 포함되어 있는가?
- 작게 시작하는 도입 범위가 있는가?
- 도입 실패 시 되돌릴 경로가 있는가?