본문 바로가기

운영체제 및 플랫폼/Docker(도커)

쿠버네티스(Kubernetes) 입문 — 도커와 무엇이 다른지 쉽게 정리

728x90
반응형

한 줄 요약

쿠버네티스는 여러 서버에 걸쳐 컨테이너를 배치하고, 정해 둔 상태를 자동으로 유지해 주는 오픈소스 플랫폼이에요. 도커가 컨테이너를 만들고 실행한다면, 쿠버네티스는 많은 컨테이너를 운영하고 관리해요.


1. 핵심 개념

1.1 쿠버네티스란

쿠버네티스 공식 문서는 쿠버네티스를 컨테이너화된 워크로드와 서비스를 관리하는, 이식성과 확장성을 갖춘 오픈소스 플랫폼으로 정의해요. 선언적 구성과 자동화를 지원해요.

  • 줄여서 K8s라고도 불러요. K와 s 사이에 글자가 8개라서예요.
  • 구글이 2014년에 오픈소스로 공개했어요.

워크로드: 쿠버네티스 위에서 실행되는 애플리케이션이에요.

선언적 구성: "어떻게 하라"가 아니라 "이런 상태여야 한다"를 적어 두는 방식이에요.

 

1.2 주요 기능

공식 문서가 소개하는 쿠버네티스의 기능은 이래요.

기능 설명

서비스 디스커버리와 로드 밸런싱 컨테이너를 이름으로 찾게 하고, 트래픽을 나눠 보내요
스토리지 오케스트레이션 원하는 저장소를 자동으로 연결해요
자동 롤아웃과 롤백 원하는 상태로 점진적으로 바꾸고, 필요하면 되돌려요
자동 빈 패킹 자원 요구량에 맞춰 컨테이너를 서버에 배치해요
자동 복구 실패한 컨테이너를 재시작하거나 교체해요
시크릿과 구성 관리 비밀번호, 설정 값을 이미지와 분리해 관리해요
수평 확장 컨테이너 개수를 늘리거나 줄여요

오케스트레이션: 여러 구성 요소를 조율해 원하는 방식으로 함께 동작하게 하는 일이에요.

 

1.3 왜 중요한가

컨테이너가 몇 개일 때는 직접 관리할 수 있어요. 하지만 서버와 컨테이너가 늘어나면 다음 일이 어려워져요.

  • 어느 서버에 어떤 컨테이너를 띄울지 정하기
  • 멈춘 컨테이너를 찾아 다시 실행하기
  • 트래픽에 맞춰 개수를 조절하기

쿠버네티스는 이 작업을 원하는 상태를 선언하면 자동으로 맞추는 방식으로 처리해요.


2. 쉽게 이해하기

쿠버네티스를 물류 센터 관리 시스템에 비유해 볼게요.

  • 컨테이너는 택배 상자예요.
  • 도커는 상자를 포장하고 옮기는 도구예요.
  • 쿠버네티스는 물류 센터 전체를 관리하는 시스템이에요.
    • "A 상품은 항상 3개 진열"이라고 정해 두면
    • 하나가 빠질 때 자동으로 채워 넣어요.
    • 창고(서버)에 빈자리를 보고 알아서 배치해요.

3. 기본 용어

용어 설명

클러스터(Cluster) 쿠버네티스가 관리하는 서버 전체 묶음이에요
노드(Node) 클러스터를 구성하는 서버 한 대예요
컨트롤 플레인(Control Plane) 클러스터 전체 상태를 관리하고 결정하는 부분이에요
파드(Pod) 쿠버네티스가 배포하는 가장 작은 단위예요. 컨테이너 하나 이상을 담아요
디플로이먼트(Deployment) 파드의 개수와 버전을 관리해요
서비스(Service) 여러 파드에 하나의 접속 주소를 제공해요

 

쿠버네티스는 컨테이너를 직접 다루지 않고 파드 단위로 관리해요.


4. 도커와 쿠버네티스 비교

항목 도커 쿠버네티스

주요 역할 이미지 빌드, 컨테이너 실행 여러 서버의 컨테이너 운영·관리
관리 범위 주로 단일 호스트 여러 노드로 된 클러스터
관리 단위 컨테이너 파드
장애 대응 재시작 정책 설정 원하는 상태를 유지하도록 자동 복구

 

둘은 경쟁 관계가 아니에요. 도커로 만든 이미지를 쿠버네티스에서 실행하는 방식이 일반적이에요.

 

4.1 "쿠버네티스가 도커 지원을 중단했다"는 의미

쿠버네티스는 v1.24에서 dockershim을 제거했어요.

dockershim: 쿠버네티스가 Docker Engine을 컨테이너 런타임으로 쓰기 위해 두었던 중간 연결 부품이에요.

 

이 변경은 노드에서 컨테이너를 실행하는 방식에 관한 것이에요. 쿠버네티스 공식 FAQ에 따르면 docker build로 만든 이미지는 모든 CRI 구현체에서 그대로 동작해요. 개발할 때 도커로 이미지를 만드는 방식은 계속 쓸 수 있어요.

CRI: 쿠버네티스가 다양한 컨테이너 런타임과 연결하기 위해 정한 표준 인터페이스예요. containerd, CRI-O가 대표적인 구현체예요.


5. 간단한 예시

5.1 Deployment 파일

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80
  • replicas: 3: 파드를 항상 3개 유지해요.
  • template: 만들 파드의 모양이에요.
  • image: 사용할 컨테이너 이미지예요.

 

5.2 적용과 확인

kubectl apply -f deployment.yaml
kubectl get pods

kubectl: 쿠버네티스 클러스터에 명령을 보내는 공식 명령줄 도구예요.

 

5.3 자동 복구 확인

kubectl delete pod <파드 이름>
kubectl get pods

 

파드 하나를 지워도 Deployment가 replicas: 3 상태를 맞추기 위해 새 파드를 만들어요.


6. 핵심 정리

  • 쿠버네티스는 컨테이너화된 워크로드를 관리하는 오픈소스 플랫폼이에요.
  • 원하는 상태를 선언하면, 그 상태를 자동으로 유지해요.
  • 쿠버네티스는 컨테이너를 파드 단위로 관리해요.
  • 도커는 이미지를 만들고 실행하는 도구이고, 쿠버네티스는 여러 서버에서 컨테이너를 운영하는 도구예요.
  • dockershim 제거 이후에도 도커로 만든 이미지는 쿠버네티스에서 실행돼요.

7. 추가 정보

쿠버네티스가 하지 않는 일

공식 문서는 쿠버네티스가 전통적인 PaaS가 아니라고 설명해요. 예를 들어 소스 코드를 배포하거나 애플리케이션을 빌드하지 않아요. 빌드와 배포 파이프라인은 CI/CD 도구와 함께 구성해요.

PaaS: 애플리케이션 실행 환경을 통째로 제공하는 클라우드 서비스 형태예요.

 

학습 환경

공식 문서는 로컬에서 쿠버네티스를 실행하는 도구로 kind, minikube 등을 안내해요. Docker Desktop에도 쿠버네티스 기능이 포함되어 있어요.

 

도입 전 확인할 점

  • 쿠버네티스는 구성 요소가 많아 학습과 운영에 시간이 필요해요.
  • 서버 규모, 운영 인력, 필요한 기능을 기준으로 도입 여부를 판단해야 해요. 특정 규모 이상에서 반드시 필요하다는 공식 기준은 명확히 확인되지 않아요.

 

관련 글

 

반응형