Kubernetes란 무엇이고, 왜 써야 할까
컨테이너 오케스트레이션의 핵심 개념
도커(Docker)로 컨테이너를 하나 띄우는 건 쉽다. 그런데 서비스가 커지면 컨테이너가 수십, 수백 개로 늘어난다. "어떤 서버에 컨테이너를 배치할까?", "컨테이너가 죽으면 자동으로 다시 살릴 수 있을까?", "트래픽이 몰리면 자동으로 늘릴 수 있을까?" 같은 고민이 생긴다. 이걸 해결해주는 게 컨테이너 오케스트레이션이고, 그 대표 주자가 Kubernetes다.
K8s는 구글이 내부에서 15년 넘게 사용하던 Borg 시스템의 경험을 바탕으로 만든 오픈소스 프로젝트다. 컨테이너의 배포, 스케일링, 관리를 자동화해주는 플랫폼이라고 생각하면 된다. 학습 곡선이 좀 가파른 건 사실인데, 한번 익히면 인프라 운영이 정말 편해진다.
도커만으로는 부족한 이유
"도커 컴포즈로도 충분하지 않나?"라고 질문하는 경우가 많다. 소규모 프로젝트라면 맞는 말이다. 하지만 프로덕션 환경에서 무중단 배포, 자동 복구, 오토스케일링, 서비스 디스커버리 같은 기능이 필요하다면 도커 단독으로는 한계가 명확하다. Kubernetes는 이 모든 걸 선언적으로 관리할 수 있게 해준다. YAML 파일 하나로 "나는 이 상태를 원해"라고 선언하면, K8s가 알아서 그 상태를 유지해준다.
언제 도입을 고려해야 할까
마이크로서비스가 3개 이상이거나, 배포 주기가 주 1회 이상이거나, 트래픽 변동이 큰 서비스라면 Kubernetes 도입을 진지하게 고려해볼 만하다. 반대로 단일 서비스를 소수 인원이 운영하는 상황이라면 오버엔지니어링일 수 있다. 도구는 상황에 맞게 쓰는 게 중요하다.
핵심 구성 요소 빠르게 이해하기
Pod, Deployment, Service -- 3대장 정리
Pod는 K8s에서 가장 작은 배포 단위다. 하나 이상의 컨테이너를 묶어놓은 그룹이라고 보면 된다. 보통은 컨테이너 하나 = Pod 하나로 구성하는 경우가 대부분이다.
Deployment는 Pod를 어떻게 배포하고 관리할지 정의하는 상위 리소스다. "이 Pod를 3개 띄워줘", "업데이트할 때 롤링으로 해줘" 같은 전략을 여기서 설정한다. 실무에서는 Pod를 직접 만드는 일은 거의 없고, 거의 항상 Deployment를 통해 관리한다.
Service는 Pod들에게 안정적인 네트워크 엔드포인트를 부여하는 리소스다. Pod는 생성될 때마다 IP가 바뀌기 때문에, Service가 앞단에서 고정된 주소로 트래픽을 라우팅해주는 역할을 한다.
Namespace와 ConfigMap 활용법
Namespace는 클러스터 안에서 리소스를 논리적으로 분리하는 공간이다. 보통 dev, staging, production 같은 환경 단위로 나누거나, 팀별로 분리해서 사용한다. 초기에 namespace 분리를 안 하고 모든 걸 default에 넣었다가 나중에 리소스 정리가 정말 고통스러웠다.
ConfigMap은 애플리케이션 설정값을 외부에서 주입할 때 사용한다. 환경변수나 설정 파일을 이미지 안에 하드코딩하지 않고, ConfigMap으로 분리하면 이미지를 다시 빌드하지 않고도 설정을 바꿀 수 있다. 민감한 정보는 Secret 리소스를 사용하는 게 좋다.
실전 배포: 처음부터 끝까지
로컬 환경 세팅 (minikube / kind)
처음 Kubernetes를 연습할 때는 클라우드에 클러스터를 만들 필요 없다. 로컬에서 minikube나 kind(Kubernetes in Docker)를 사용하면 충분하다. kind를 추천한다. 도커만 설치되어 있으면 바로 쓸 수 있고, 멀티 노드 클러스터도 쉽게 구성할 수 있다. minikube는 VM 기반이라 자원 소모가 좀 더 크지만, 대신 애드온 지원이 풍부하다.
kubectl(큐브컨트롤)은 K8s 클러스터와 소통하는 CLI 도구인데, 이건 반드시 설치해야 한다. 앞으로 거의 모든 작업을 kubectl로 하게 된다.
첫 번째 앱 배포하기
가장 간단한 배포 흐름은 이렇다. 먼저 Deployment YAML 파일을 작성한다. 여기에 컨테이너 이미지, 레플리카 수, 포트 정보 등을 명시하고, kubectl apply -f 명령으로 클러스터에 적용한다. 그다음 Service를 만들어서 외부에서 접근 가능하게 해주면 끝이다.
이 과정에서 가장 많이 실수하는 부분이 이미지 태그다. latest 태그를 사용하면 캐시 문제로 이전 이미지가 배포되는 경우가 비일비재하다. 반드시 버전 태그(예: v1.2.3)를 사용하고, imagePullPolicy를 명시적으로 설정해야 한다.
무중단 배포와 롤백 전략
Kubernetes의 꽃은 롤링 업데이트다. Deployment에 새 이미지 버전을 지정하고 apply하면, K8s가 자동으로 기존 Pod를 하나씩 내리고 새 Pod를 올려준다. 이 과정에서 서비스 중단이 없다. 만약 새 버전에 문제가 있다면 kubectl rollout undo 한 방으로 이전 버전으로 되돌릴 수 있다.
여기에 Readiness Probe와 Liveness Probe를 설정하면 금상첨화다. Readiness Probe는 "이 Pod가 트래픽을 받을 준비가 됐는지" 확인하고, Liveness Probe는 "이 Pod가 살아있는지" 확인한다. 이 두 가지를 제대로 설정하면 배포 중 에러 페이지가 사용자에게 노출되는 상황을 크게 줄일 수 있다.
실무에서 바로 쓰는 운영 팁
Resource Requests/Limits를 꼭 설정하자. CPU와 메모리 제한을 안 걸면, 특정 Pod가 노드 자원을 독식해서 다른 Pod가 죽는 참사가 벌어진다. requests는 최소 보장 자원, limits는 최대 허용 자원이다. 반드시 둘 다 설정해야 한다.
label과 annotation을 잘 활용하자. 리소스가 많아지면 label로 필터링하는 게 생명줄이다. 팀명, 환경, 앱 버전 등을 label로 붙여두면 kubectl get pods -l app=api,env=prod 같은 명령으로 원하는 리소스만 빠르게 조회할 수 있다.
kubectl 명령어를 alias로 등록하자. k=kubectl, kgp="kubectl get pods", kaf="kubectl apply -f" 같은 단축 명령을 등록해두면 생산성이 확 올라간다.
모니터링은 선택이 아니라 필수다. Prometheus + Grafana 조합을 초기에 세팅해둬야 한다. 장애가 터진 후에 모니터링을 세팅하려고 하면 이미 늦다.
Helm 차트를 적극 활용하자. YAML 파일이 수십 개로 불어나면 관리가 정말 힘들다. Helm은 K8s의 패키지 매니저로, 템플릿화된 차트로 환경별 배포를 깔끔하게 관리할 수 있다.
장단점 비교표
| 구분 | 장점 | 단점 |
|---|---|---|
| 자동 복구 | 컨테이너 장애 시 자동 재시작, 노드 장애 시 다른 노드로 자동 이동 | 자동 복구 설정이 잘못되면 무한 재시작 루프에 빠질 수 있음 |
| 스케일링 | HPA로 트래픽에 따라 자동 확장/축소 | 오토스케일링 임계값 튜닝에 시행착오가 필요함 |
| 배포 전략 | 롤링 업데이트, 카나리, 블루그린 등 다양한 전략 지원 | YAML 설정의 복잡도가 높아 초기 세팅에 시간이 걸림 |
| 에코시스템 | Helm, Istio, ArgoCD 등 풍부한 도구 생태계 | 선택지가 너무 많아 의사결정 피로가 발생할 수 있음 |
| 학습 곡선 | 한 번 익히면 어느 클라우드에서든 동일한 방식으로 운영 가능 | 개념이 많아 입문자에게 초기 진입 장벽이 상당히 높음 |
| 비용 | 리소스 효율적 분배로 장기적으로 인프라 비용 절감 가능 | 관리형 서비스(EKS, GKE 등) 이용 시 클러스터 자체 비용 발생 |
마무리: 누구에게 추천하는가
- 마이크로서비스 아키텍처를 운영 중이거나 전환을 계획하는 백엔드/인프라 엔지니어
- 배포 자동화와 무중단 배포에 관심이 있는 DevOps 엔지니어
- 트래픽 변동이 크고 오토스케일링이 필요한 서비스를 운영하는 팀
- 멀티 클라우드 또는 하이브리드 클라우드 전략을 고려 중인 조직
- 컨테이너 기반 개발에 익숙하고, 다음 단계로 컨테이너 오케스트레이션을 배우고 싶은 개발자
Kubernetes는 쉽지 않다. 처음에는 YAML 지옥에 빠진 기분이 들 것이다. 하지만 Pod, Deployment, Service 이 세 가지 개념만 확실히 잡으면 나머지는 하나씩 붙여나가면 된다. 완벽하게 이해하고 시작하려고 하지 말고, 일단 minikube나 kind로 로컬 클러스터를 띄워서 직접 손으로 만져보자. 이론 열 번 읽는 것보다 한 번 배포해보는 게 훨씬 빠르게 이해된다.
