K8s 입문 (Pod, Service, 배포)
Docker로 컨테이너를 띄우고 Compose로 묶음을 관리하는 단계까지 오면, 그 다음 자연스럽게 마주치는 질문이 "여러 호스트에 걸쳐 수십·수백 개의 컨테이너를 어떻게 자동으로 운영할 것인가"이다. 이 질문에 대한 산업 표준 답이 바로 Kubernetes(이하 K8s)이며, 2014년 구글이 공개한 이래 클라우드 네이티브 인프라의 사실상 운영체제 역할을 맡고 있다. 본 글은 K8s가 왜 등장했고, 그 핵심 오브젝트가 무엇이며, 어떻게 첫 배포를 굴려 보는지를 정보처리기사 시험 범위와 입문 실전에 모두 닿도록 정리한다(출처: Kubernetes 공식 문서). 제가 학교 클라우드 네이티브 수업에서 Compose만 알던 시기에 처음 K8s를 본 인상은 솔직히 "왜 이렇게 복잡해" 한 마디였는데, 노드 한 대가 죽어도 자동으로 파드가 다른 노드에서 다시 살아나는 장면을 직접 보고 나서야 그 복잡도가 단순한 사치가 아니라 운영의 비용을 0으로 수렴시키기 위한 설계였다는 사실이 와닿았다.
K8s가 등장한 이유, Compose의 한계
Docker Compose가 한 호스트 위의 여러 컨테이너를 묶는 도구라면, K8s는 여러 호스트(노드)에 걸쳐 컨테이너를 분산하고 자동 관리하는 오케스트레이터다. 여기서 오케스트레이터란 다수의 컨테이너를 클러스터 단위로 자동 배치·복구·확장하는 상위 관리 시스템을 가리키며, 운영자는 "최종 상태가 어떠해야 한다"만 선언하면 K8s가 그 상태에 도달하도록 끊임없이 조정한다. Compose가 한 명의 셰프가 작은 주방에서 요리하는 그림이라면, K8s는 수십 명의 셰프가 동시에 일하는 대형 호텔 주방을 자동 관리하는 시스템에 가깝다.
K8s가 풀어 준 운영 문제는 크게 네 가지다. 첫째, 자가 치유(Self-Healing) 기능이다. 컨테이너가 죽거나 노드가 다운되면 K8s가 자동으로 다른 노드에서 같은 컨테이너를 다시 띄운다. 둘째, 수평 확장(Horizontal Scaling)이다. 트래픽이 늘면 같은 컨테이너의 복제본 수를 자동으로 늘리고, 줄면 다시 줄이는 흐름을 표준화했다. 셋째, 무중단 배포(Rolling Update)다. 새 버전의 컨테이너를 한 번에 다 갈아끼우지 않고, 일부씩 교체하면서 사용자 요청을 끊김 없이 받게 만든다. 넷째, 서비스 디스커버리와 로드 밸런싱이다. 같은 역할의 컨테이너 묶음에 안정된 가상 주소를 부여해, 내부 컨테이너가 IP 주소를 외울 필요 없이 이름만으로 통신하게 만든다.
K8s는 2015년 CNCF(Cloud Native Computing Foundation)에 기증되어 오픈 거버넌스로 운영되며, 현재는 모든 주요 클라우드 사업자(AWS·GCP·Azure)가 관리형 K8s 서비스를 제공한다(출처: CNCF Kubernetes). 솔직히 처음에는 "내 토이 프로젝트에 K8s가 필요할까"라는 의심이 많았는데, 실제로는 minikube 같은 단일 노드 로컬 K8s를 띄워 보는 학습 단계만 거쳐도 인프라 사고를 보는 시야가 한 단계 넓어진다는 점을 직접 체감했다.
핵심 오브젝트 — Pod, Service, Deployment
K8s를 입문하면서 가장 먼저 외워야 할 세 가지 오브젝트가 Pod·Service·Deployment다. 이 셋의 관계만 정확히 잡으면 나머지 개념(ConfigMap·Secret·Ingress 등)은 자연스럽게 따라온다. 정보처리기사 시험에서도 K8s 관련 출제가 늘고 있는 추세이므로, 각 오브젝트의 정의를 한 줄로 외워 두면 활용도가 높다.
Pod는 K8s의 가장 작은 배포 단위로, 한 개 이상의 컨테이너를 하나의 네트워크·저장소 컨텍스트에 묶어 함께 실행하는 그룹이다. 같은 Pod 안의 컨테이너들은 IP 주소와 localhost를 공유하기 때문에, 사이드카(sidecar) 패턴처럼 메인 컨테이너 옆에 보조 컨테이너(로그 수집기, 프록시 등)를 함께 두는 구성에 적합하다. 여기서 사이드카 패턴이란 메인 애플리케이션을 수정하지 않고도 기능을 보강하기 위해 보조 컨테이너를 같은 Pod에 끼워 넣는 운영 패턴을 가리킨다.
Service는 Pod 묶음에 안정된 가상 IP와 DNS 이름을 부여하는 추상화 계층이다. Pod는 죽었다 살아날 때마다 IP가 바뀌기 때문에 그 자체를 클라이언트가 직접 부르는 일은 거의 불가능하지만, Service는 그 변동성을 가려 주는 역할을 한다. Service의 종류는 ClusterIP(클러스터 내부 통신), NodePort(노드 포트로 외부 노출), LoadBalancer(클라우드 로드밸런서 연동), ExternalName(외부 DNS 매핑) 네 가지가 있으며, 입문 단계에서는 ClusterIP와 LoadBalancer 둘만 정확히 잡으면 충분하다.
Deployment는 같은 Pod의 복제본 수를 관리하고 무중단 배포를 책임지는 상위 컨트롤러이다. "이 컨테이너 이미지를 3개 복제로 유지해 줘, 새 버전이 들어오면 한 번에 하나씩 교체해 줘"라는 선언을 받아 그 상태를 유지한다. Deployment가 만든 Pod 묶음에 Service를 붙이면 안정된 진입점을 가진 확장형 워크로드가 완성되며, 이 셋의 결합이 K8s 입문의 거의 전부이다. 제 경험상 처음에는 Pod와 Deployment를 혼동해 둘 다 직접 만들려다 한참 헤맨 적이 있는데, "사용자는 Deployment만 만들고 Pod는 K8s가 알아서 만든다"라는 한 줄을 외운 뒤로는 사고가 사라졌다.
kubectl로 첫 배포 실행하기
K8s 클러스터를 조작하는 표준 명령줄 도구가 kubectl이다. 입문 단계에서는 minikube나 kind 같은 로컬 단일 노드 클러스터로 충분하며, 두 도구 모두 한 줄 설치 후 kubectl이 곧바로 클러스터를 가리키게 된다. 다음은 nginx 컨테이너 3개 복제본을 띄우고 외부에 노출하는 가장 단순한 예시다.
# nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 3
selector:
matchLabels: { app: nginx }
template:
metadata:
labels: { app: nginx }
spec:
containers:
- name: nginx
image: nginx:1.27
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
type: LoadBalancer
selector: { app: nginx }
ports:
- port: 80
targetPort: 80kubectl apply -f nginx.yaml 한 줄로 Deployment와 Service가 함께 생성되고, kubectl get pods로 떠 있는 Pod 3개를 확인할 수 있다. kubectl scale deployment nginx --replicas=10을 실행하면 즉시 10개로 확장되며, 이미지 버전을 바꿔 다시 apply하면 K8s가 알아서 무중단으로 롤링 업데이트를 진행한다. 여기서 매니페스트(manifest)란 클러스터의 원하는 상태를 YAML로 적어 둔 선언형 파일을 가리키며, K8s 운영의 거의 모든 변경은 이 매니페스트를 수정해 다시 apply하는 흐름으로 통일된다.
솔직히 이건 예상 밖이었는데, 제가 처음 minikube에서 위 예시를 굴려 본 후로는 K8s가 어렵다는 일반적인 통념이 사실 입문 단계가 아니라 운영 단계의 이야기라는 점을 알게 되었다. Pod·Service·Deployment 세 단어와 apply·get·scale 세 명령만 손에 익으면 학습 곡선의 가장 가파른 첫 언덕은 이미 넘는다는 의미이다. 다음 글에서는 이 기본 위에 ConfigMap·Secret·Ingress 같은 운영 필수 오브젝트를 얹어 가는 흐름을 다룰 예정이다.
메타 디스크립션: Kubernetes가 풀어 준 운영 문제(자가 치유·수평 확장·무중단 배포·서비스 디스커버리)와 핵심 오브젝트(Pod·Service·Deployment), 그리고 kubectl로 첫 배포를 굴려 보는 입문 흐름을 정리합니다.