쿠버네티스 개요, 기본 리소스 및 Docker와의 차이점

#kubernetes#쿠버네티스#docker#컨테이너#오케스트레이션

이 글은 AI가 작성했습니다.

개요

이 문서는 쿠버네티스(Kubernetes)가 무엇인지, 운영에서 자주 사용하는 기본 리소스(오브젝트)의 역할과 구조, 그리고 Docker와의 주요 차이점을 정리한다. 개발·운영 환경에서 컨테이너 기반 애플리케이션을 설계·배포·관리할 때 필요한 핵심 개념과 실무에서 참고할 기본 명령어 및 예시를 포함한다.

쿠버네티스란 무엇인가

쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장(스케일링), 복구(셀프-힐링), 네트워킹 및 서비스 디스커버리를 자동화하는 오케스트레이션 플랫폼이다. 선언적(Declarative) 방식의 구성(manifest)을 사용하여 원하는 시스템 상태를 정의하면 쿠버네티스가 이를 유지하도록 동작한다.

주요 특징:

  • 컨테이너 스케줄링: 워크로드를 클러스터의 노드에 배치하고 리소스 사용을 조정함.
  • 자동 복구: 실패한 컨테이너를 재시작하거나 재스케줄링함.
  • 서비스 디스커버리 및 로드밸런싱: 서비스 단위로 트래픽을 분배함.
  • 볼륨 및 스토리지 추상화: 다양한 스토리지 백엔드를 사용할 수 있음.
  • 확장성과 확장 자동화(Horizontal/Vertical scaling, autoscaling).

쿠버네티스는 단일 마스터(제어 평면)와 여러 워커 노드 구조를 취하며, 제어 평면은 API 서버, 스케줄러, 컨트롤러 매니저, etcd(상태 저장소)로 구성된다.

핵심 리소스(기본 리소스)

다음은 실무에서 자주 사용되는 쿠버네티스 기본 리소스와 간단한 설명이다.

Pod

  • 컨테이너의 최소 배포 단위. 하나 이상의 컨테이너가 같은 네트워크 네임스페이스와 볼륨을 공유한다.
  • 보통 직접 Pod를 생성하기보다 상위 리소스(Deployment, StatefulSet 등)를 통해 관리한다.
  • 예시 (간단한 Pod manifest): apiVersion: v1 kind: Pod metadata: name: example-pod spec: containers:
    • name: app image: nginx:latest ports:
      • containerPort: 80

Deployment

  • 선언적 업데이트(롤링 업데이트 등)와 복제(Replica) 관리를 제공한다.
  • ReplicaSet을 생성하여 지정한 개수만큼 Pod를 유지한다.
  • 주로 무상태(stateless) 애플리케이션에 사용한다.
  • 예시 (간단한 Deployment): apiVersion: apps/v1 kind: Deployment metadata: name: example-deployment spec: replicas: 3 selector: matchLabels: app: example template: metadata: labels: app: example spec: containers: - name: app image: nginx:latest

ReplicaSet

  • 지정한 수의 Pod 복제본을 유지하는 역할. 직접 사용하는 경우보다 Deployment가 관리하는 것이 일반적이다.

StatefulSet

  • 상태가 있는(stateful) 애플리케이션에 사용. 각 Pod에 고유하고 안정적인 네트워크 ID와 영구 스토리지를 제공한다.
  • 예: 데이터베이스 클러스터(예: MySQL, Cassandra).

DaemonSet

  • 클러스터의 각(또는 특정) 노드에 한 인스턴스의 Pod를 보장한다.
  • 노드별 에이전트(로깅, 모니터링, 노드 수준 서비스)에 사용됨.

Job / CronJob

  • Job: 한 번 또는 정해진 횟수만큼 완료되어야 하는 작업을 실행.
  • CronJob: 일정에 따라 Job을 주기적으로 생성.

Service

  • Pod 집합에 대한 네트워크 접근을 추상화(클러스터 내부/외부)한다.
  • 타입: ClusterIP(클러스터 내부), NodePort, LoadBalancer(클라우드 제공자 연동), ExternalName.
  • 내부 로드밸런싱과 서비스 디스커버리를 제공.

Ingress

  • HTTP/HTTPS 레벨의 라우팅 규칙을 정의하여 외부로부터의 트래픽을 서비스로 라우팅한다.
  • Ingress Controller(예: nginx, Traefik)가 필요하다.

ConfigMap / Secret

  • ConfigMap: 설정 데이터를 키-값 형태로 저장하여 Pod에 주입(환경변수, 볼륨 등).
  • Secret: 민감 정보(암호, 토큰 등)를 저장. ConfigMap보다 저장 방식과 접근 제어를 강화할 수 있지만, 기본적으로는 base64로 인코딩되어 저장되므로 추가 보호(암호화 등)가 필요하다.

Volume / PersistentVolume(PV) / PersistentVolumeClaim(PVC)

  • Volume: Pod 라이프사이클 동안 컨테이너 간 데이터 공유를 위한 추상화.
  • PersistentVolume: 클러스터 수준에서 프로비저닝된 스토리지 리소스(관리자가 수동으로 또는 동적 프로비저닝 제공).
  • PersistentVolumeClaim: 사용자가 요구하는 스토리지 요청(크기, 접근 모드 등). PV와 바인딩되어 영구 스토리지를 제공.

Namespace

  • 클러스터 내 가상적인 분할(다중 테넌시, 리소스 격리, 네임 충돌 방지).
  • 리소스 쿼터 및 RBAC 정책 적용에 사용.

NetworkPolicy

  • Pod 간 트래픽 흐름을 제어하는 규칙을 정의. 기본적으로 모든 Pod 간 통신 허용인 경우가 많으므로 필요한 경우 제한을 적용한다.

기본 작업과 명령어

  • kubectl: 쿠버네티스 API와 상호작용하는 CLI 도구.

    • kubectl apply -f <file.yaml> : 선언적 리소스 적용/갱신
    • kubectl get pods, deployments, svc : 리소스 목록 조회
    • kubectl describe pod : 상세 정보 확인
    • kubectl logs [-c ] : 로그 확인
    • kubectl exec -it — : Pod 내부에서 명령 실행
    • kubectl scale deployment/ —replicas= : 수동 스케일
    • kubectl port-forward : : 로컬에서 포트 포워딩

  • 매니페스트는 주로 YAML로 작성되며, 선언적 방식으로 리소스의 원하는 상태를 기술한다. 라벨(labels)과 셀렉터(selectors)는 리소스 간 관계를 설정하는 기본 수단이다.

Docker와의 차이점

쿠버네티스와 Docker는 목적과 범위에서 차이가 있다. 주요 차이점을 정리하면 다음과 같다.

  • 역할과 범위

    • Docker: 주로 컨테이너 이미지 생성, 배포, 런타임(예: Docker Engine) 관리, Docker CLI와 Docker Compose 같은 도구로 단일 호스트 또는 개발 환경에서 컨테이너를 실행하고 연결한다.
    • Kubernetes: 여러 호스트(노드)를 가진 클러스터에서 컨테이너화된 애플리케이션을 오케스트레이션(배포·스케줄링·확장·복구·네트워크·스토리지 관리)한다.

  • 동작 방식

    • Docker는 컨테이너 런타임으로서 이미지를 실행하고 관리한다.
    • 쿠버네티스는 컨테이너 런타임(CRI를 만족하는 여러 구현: containerd, CRI-O 등)을 사용하여 컨테이너를 생성·관리한다. 과거에는 Docker Engine이 런타임으로 자주 사용되었으나, 현재는 컨테이너 런타임 인터페이스(CRI) 호환 런타임을 직접 사용하는 경향이 있다.

  • 구성 방식

    • Docker Compose: 여러 컨테이너를 하나의 호스트에서 정의·연결하는 도구로, 주로 개발 및 소규모 배포에 적합하다.
    • Kubernetes: 수천 노드에 이르는 클러스터 수준의 워크로드 배포와 고가용성, 자동화된 롤아웃/롤백, 서비스 디스커버리 등을 지원한다.

  • 네트워킹 및 서비스 디스커버리

    • Docker 기본 네트워크는 호스트, 브리지, 오버레이 등을 제공하지만, 멀티호스트와 클러스터 수준의 복잡한 네트워크 정책·서비스 디스커버리 기능은 제한적이다.
    • 쿠버네티스는 Pod IP 모델, Service 추상화, NetworkPolicy, Ingress 등을 통해 복잡한 네트워크 요구사항을 처리한다. 멀티호스트 네트워킹을 위해 CNI 플러그인(Calico, Flannel 등)을 사용한다.

  • 스케줄링 및 자원 관리

    • Docker 자체에는 클러스터 스케줄러가 내장되어 있지 않으며, Docker Swarm은 별도의 오케스트레이션 솔루션이다.
    • 쿠버네티스는 리소스 요청/제한, QoS 클래스, 노드 셀렉터, 토폴로지 기반 스케줄링 등 세부적인 스케줄링 정책을 제공한다.

  • 스토리지 및 상태 관리

    • Docker만으로는 영구 스토리지를 클러스터 단위로 관리하는 데 한계가 있다.
    • 쿠버네티스는 PV/PVC, 스토리지 클래스(StorageClass)를 통해 다양한 스토리지 백엔드를 추상화하고 동적 프로비저닝을 지원한다. StatefulSet은 상태 저장 워크로드에 필요한 안정적 네트워킹과 스토리지 바인딩을 제공한다.

  • 운영/관리 측면

    • Docker는 단일 호스트 중심의 운영에 적합하며 설정과 사용이 상대적으로 단순하다.
    • 쿠버네티스는 기능이 풍부하나 구성, 운영, 모니터링, 보안 설정이 더 복잡하다. 운영 자동화와 모니터링(예: Prometheus, Fluentd, Grafana) 체계가 필요하다.

관계와 보완

  • Docker 이미지와 쿠버네티스는 상호 배타적이지 않다. 쿠버네티스는 Docker 형식의 컨테이너 이미지를 실행할 수 있으며, 빌드된 이미지를 레지스트리에 올려 쿠버네티스에서 사용한다.
  • Docker Desktop은 로컬 개발용으로 Kubernetes를 통합 제공하기도 한다(환경 설정에 따라 사용 가능).
  • 프로덕션 환경에서는 Docker Engine 대신 containerd, CRI-O 등 CRI 호환 런타임을 사용하는 경우가 일반적이다.

요약

  • 쿠버네티스는 컨테이너화된 애플리케이션의 클러스터 수준 오케스트레이션 플랫폼이다. 선언적 구성으로 배포·확장·복구·네트워크·스토리지를 관리한다.
  • 기본 리소스(Pod, Deployment, Service, ConfigMap, Secret, PV/PVC, StatefulSet, DaemonSet, Job/CronJob 등)는 각각의 목적이 있으며 이들을 조합해 애플리케이션을 설계한다.
  • Docker는 컨테이너 이미지 생성과 런타임을 제공하는 도구군이며, 쿠버네티스는 이런 컨테이너를 대규모로 관리·오케스트레이션하는 역할을 수행한다.
  • 실무에서는 Docker로 이미지를 빌드하고, 쿠버네티스에서 그 이미지를 배포·운영하는 식으로 두 기술을 함께 사용한다.

필요하면 각 리소스의 상세 YAML 템플릿, 실무 예제(무상태/유상태 애플리케이션 배포), 또는 쿠버네티스 클러스터 구성(제어 평면 구성, 고가용성 등)에 대한 추가 정보를 제공하겠다.