K8S(쿠버네티스)에 대한 이해 — Docker만으론 부족한 이유부터 핵심 개념까지

안녕하세요, 자바파커입니다.

"Docker로 컨테이너 띄우는 건 익숙한데, 쿠버네티스는 자꾸 미뤄두게 됩니다."

솔직히 저도 그랬습니다. docker run 한 줄이면 서비스가 뜨는데, 갑자기 Pod, Deployment, Service, Ingress… 용어부터 쏟아지니 부담스럽습니다. 공식 문서를 열면 YAML이 수십 줄씩 나오고, "이걸 꼭 써야 하나" 싶은 순간도 많습니다.

결론부터 말씀드리면 — K8S는 "컨테이너를 운영 수준으로 다루기 위한 운영체제"입니다. 단일 서버에서 컨테이너 몇 개 돌릴 때는 필요 없지만, 장애 복구·스케일링·배포 자동화가 필요한 순간부터는 사실상 표준입니다. 오늘은 쿠버네티스를 처음 접하는 분들을 위해, 개념과 핵심 오브젝트를 실전 감각으로 정리해보겠습니다.

K8S는 결국 뭔가? — 한 줄 정의

쿠버네티스(Kubernetes, 줄여서 K8s)는 컨테이너화된 애플리케이션의 배포·확장·운영을 자동화하는 오픈소스 플랫폼입니다.

비유하자면 이렇습니다.

Docker: 물건을 담는 컨테이너(박스)
Docker Compose: 한 창고 안에서 박스를 정리하는 정리 매뉴얼
Kubernetes: 여러 창고를 관리하며, 박스를 옮기고·복제하고·망가진 걸 다시 채워 넣는 자동화된 물류 시스템

혼자 쓰는 창고(단일 서버)라면 매뉴얼만 있어도 충분합니다. 하지만 창고가 여러 개(다중 서버)가 되고, 박스가 갑자기 쏟아져 들어오고(트래픽), 한 창고가 불이 나도 멈추면 안 되는(장애 복구) 순간부터는 K8S 같은 시스템이 필요해집니다.

K8S가 해결하는 문제 5가지

쿠버네티스가 왜 나왔는지 감을 잡는 가장 빠른 방법은, K8S 없이 운영할 때 생기는 문제를 보는 겁니다.

문제 상황	K8S 없이	K8S 사용 시
트래픽이 갑자기 2배	서버 수동 증설, 로드밸런서 재설정	`replicas` 값 변경 또는 HPA 자동 증설
컨테이너가 갑자기 죽음	모니터링 → 수동 재시작	자동 재시작 + 자동 스케줄링
무중단 배포	Blue-Green 직접 구성, 스크립트 관리	RollingUpdate 전략 기본 제공
서버 한 대가 장애	해당 서버 위 컨테이너 전부 사라짐	다른 노드로 자동 재배치
환경변수·설정 관리	`.env` 파일 복사·보안 관리 수동	ConfigMap / Secret으로 표준화

핵심 키워드는 **자가 치유(self-healing)**와 **선언적 운영(declarative)**입니다. "이런 상태를 원한다"고 YAML로 선언하면, K8S가 알아서 그 상태에 맞춰줍니다.

핵심 컴포넌트 — Control Plane과 Worker Node

K8S 클러스터는 크게 **Control Plane(두뇌)**과 Worker Node(실행 영역) 두 영역으로 나뉩니다.

K8S 클러스터 구조 — Control Plane(API Server·Scheduler·Controller Manager·etcd)과 Worker Node 3대

역할만 간단히 정리하면:

컴포넌트	역할
API Server	모든 요청의 창구 (`kubectl`이 말 거는 대상)
etcd	클러스터의 "진실의 원천" — 모든 상태 저장소
Scheduler	새 Pod를 어느 노드에 띄울지 결정
Controller Manager	실제 상태와 원하는 상태의 차이를 계속 맞춤
kubelet	각 노드의 에이전트 — 컨테이너를 실제로 띄우고 보고함

처음엔 외우지 말고, "API Server가 입구, etcd가 저장소" 정도만 기억해도 충분합니다.

꼭 알아야 할 오브젝트 5가지

K8S는 모든 것이 오브젝트(Object)입니다. 그중 입문자가 반드시 익혀야 할 5가지만 뽑았습니다.

1. Pod — 가장 작은 배포 단위

컨테이너 1개 이상을 묶은 실행 단위
같은 Pod 안의 컨테이너는 네트워크·스토리지를 공유
Pod는 언제든 죽을 수 있다는 전제로 설계됨 (그래서 단독으로 만드는 일은 드뭅니다)

2. Deployment — Pod의 "관리자"

Pod를 몇 개 띄울지, 어떻게 업데이트할지 선언
롤링 업데이트·롤백 기본 지원
실무에선 Pod를 직접 만들지 않고 Deployment로 만듭니다

3. Service — 접근 경로

Pod는 죽으면 IP가 바뀝니다. Service가 고정된 엔드포인트를 제공
타입별 차이:

타입	용도
`ClusterIP`	클러스터 내부 전용 (기본값)
`NodePort`	노드 IP:포트로 외부 노출 (개발용)
`LoadBalancer`	클라우드 LB 자동 생성 (운영용)

4. ConfigMap / Secret — 설정 분리

ConfigMap: 일반 설정 (환경변수, 설정 파일)
Secret: 민감 정보 (API 키, 비밀번호) — Base64 인코딩 저장

코드와 설정을 분리해야 같은 이미지를 dev·staging·prod에 재사용할 수 있습니다.

5. Ingress — HTTP 라우팅의 진입점

도메인·경로 기반 라우팅 (api.example.com → api Service, /admin → admin Service)
TLS 종단 처리
Nginx·Traefik 같은 Ingress Controller가 실제 트래픽 처리

이 오브젝트들이 실제 요청을 처리하는 흐름은 다음과 같습니다.

K8S 오브젝트 흐름도 — 외부 요청이 Ingress → Service → Deployment → Pod로 전달되는 과정

실전 예시 — nginx를 K8S에 띄우기

이론만으론 감이 안 옵니다. nginx 하나를 Deployment + Service로 띄우는 최소 YAML을 보겠습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
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-svc
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80

적용과 확인은 세 줄로 끝납니다.

kubectl apply -f nginx.yaml
kubectl get pods -l app=nginx
kubectl port-forward svc/nginx-svc 8080:80

이제 http://localhost:8080으로 접속하면 nginx가 응답합니다. Pod 하나를 강제로 삭제해봐도 곧바로 새 Pod가 올라오는 걸 확인할 수 있습니다 — 이게 자가 치유입니다.

# Pod 하나 강제 삭제
kubectl delete pod <pod-name>

# 몇 초 뒤 확인해보면 새 Pod가 자동 생성됨
kubectl get pods -l app=nginx

전체 자가 치유 과정을 시각화하면 이렇습니다.

운영자 개입 없이 컨트롤러가 **원하는 상태(desired state)**를 기준으로 차이를 감지하고 복구합니다. 이 선언적 운영 모델이 K8S의 가장 강력한 장점입니다.

K8S를 도입해야 할 때 vs 안 해도 될 때

솔직히 말씀드리면, 모든 프로젝트에 K8S가 필요한 건 아닙니다.

도입을 추천하는 경우

서비스 수가 10개 이상이거나 앞으로 늘어날 계획
트래픽 변동폭이 커서 오토스케일링이 필요
무중단 배포·카나리 배포가 요구사항
여러 환경(dev/staging/prod)을 일관되게 운영해야 함
팀에 인프라/DevOps 담당자가 있다

도입을 재고해야 하는 경우

단일 서비스, 트래픽 안정적, 작은 팀
운영 인력 없이 개발자 1~2명
Docker Compose나 관리형 PaaS(Cloud Run, ECS Fargate 등)로 충분한 규모

K8S는 강력한 만큼 복잡합니다. 러닝 커브와 운영 비용을 지불할 준비가 됐을 때 도입하는 게 맞습니다. 처음부터 "일단 K8S"는 오히려 생산성을 떨어뜨리는 경우가 많습니다.

FAQ

Q. Docker Swarm과 K8S 중 뭘 써야 하나요?

사실상 K8S가 표준입니다. Docker Swarm은 설정이 간단한 대신 생태계가 얇고, 클라우드 3사(AWS·GCP·Azure)가 모두 관리형 K8S(EKS·GKE·AKS)를 제공합니다. 학습 리소스, 채용 시장, 도구 생태계 모두 K8S 중심으로 움직입니다.

Q. 공부는 로컬에서 어떻게 시작하나요?

가볍게 시작할 수 있는 옵션이 많습니다.

Docker Desktop의 Kubernetes: 클릭 한 번으로 활성화
minikube: 단일 노드 로컬 클러스터
kind: Docker 컨테이너로 K8S 노드를 띄우는 방식, CI에도 유용

실습은 kubectl 명령어 익숙해지는 것부터 시작하시면 됩니다.

Q. 직접 구축 vs 관리형 서비스, 뭘 써야 하나요?

처음엔 무조건 관리형(EKS/GKE/AKS)입니다. 직접 구축(self-hosted)은 Control Plane 운영·업그레이드·백업까지 직접 책임져야 하고, 보안 이슈도 많습니다. 비용이 문제라면 단일 노드 K3s 같은 경량 대안도 있지만, 이건 규모를 충분히 이해한 다음 선택하는 게 맞습니다.

마무리 — 다음 단계

오늘 정리한 내용은 K8S 전체의 입구일 뿐입니다. 핵심만 다시 짚으면:

K8S는 컨테이너 운영을 자동화하는 플랫폼, Docker의 상위 개념이 아니라 운영 레이어입니다
Pod → Deployment → Service → Ingress 흐름이 가장 기본
선언적 YAML과 자가 치유가 K8S를 쓰는 진짜 이유
작은 프로젝트엔 과합니다 — 규모와 팀 상황에 맞게 판단하세요

앞으로는 이 시리즈로 다음 주제들을 이어갈 예정입니다.

kubectl 실전 명령어 모음
Helm으로 패키지 관리하기
HPA·VPA로 오토스케일링 구성
Ingress + cert-manager로 HTTPS 자동화
ArgoCD로 GitOps 배포 파이프라인

여러분은 K8S를 처음 접했을 때 어떤 부분이 가장 헷갈리셨나요? 댓글로 공유해주시면 다음 포스팅 주제에 반영하겠습니다.