Kubernetes - 쿠버네티스 기본 개념

in DEV on DevOps, Kubernetes, K8s, Docker, Container-orchestration, Cluster-architecture, Control-plane, Worker-node, Pod, Service, Ingress, Cni, Calico, Workload


이 포스트에서는 클라우드 네이티브 환경의 사실상 표준(De-facto Standard)으로 자리잡은 쿠버네티스의 기본 개념과 전체적인 구조에 대해 알아본다.

쿠버네티스는 도커보다 훨씬 방대하고 복잡한 시스템이다.
인프라의 규모가 커진 만큼 알아야 할 개념도 많기 때문에 처음 접할 때는 다소 어렵게 느껴질 수 있다.

따라서 한 번에 모든 것을 이해한다는 부담보다는 전체적인 숲을 보고 핵심 개념을 하나씩 익혀간다는 생각으로 접근하는 것이 도움이 될 것이다.

목차

개발 환경

  • Ubuntu 24.04.2 LTS
  • Mac Apple M3 Max
  • Memory 48 GB

1. 쿠버네티스(k8s, Kubernetes) 개념

쿠버네티스는 컨테이너화된 애플리케이션의 자동 배포(Deployment), 스케일링, 관리를 책임지는 오픈소스 플랫폼이다.

구글의 사내 프로젝트에서 시작되어 2014년에 대중에게 처음 발표되었다.
2016년에는 쿠버네티스 환경을 위한 패키지 관리 도구인 헬름(Helm)이 발표되었다.

헬름(Helm)은 쿠버네티스 리소스를 패키지 단위(Chart)로 관리할 수 있게 해주는 도구로 추후 다룰 예정입니다. (p. 228)

1.1. 쿠버네티스 역할

단일 서버에서 소수의 컨테이너를 운영할 때는 Docker 만으로도 충분하다.
하지만 서비스의 규모가 커져 수백대의 서버를 운영해야 한다면, 서로 다른 서버에 분산되어 작동하는 수많은 컨테이너를 사람이 일일이 관리하는 것은 사실상 불가능에 가깝다.

쿠버네티스는 바로 이러한 ‘수많은 컨테이너’를 효율적으로 관리(Orchestration)한다.

100개의 컨테이너를 실행할 때

  • Docker만 사용할 때
    • 운영자는 docker container run 명령어를 100번 입력해야 함
    • 운영 중 장애가 발생하면 특정 컨테이너가 죽었는지 수시로 확인하고, 다시 명령어를 입력해 복구해야 함
  • Kubernetes를 사용할 때
    • 쿠버네티스에게 ‘이 컨테이너를 100개 유지해’라고 선언하기만 하면 쿠버네티스가 알아서 100개의 컨테이너를 생성하고, 그 중 하나가 장애로 종료되면 즉시 새로운 컨테이너를 실행하여 100개라는 상태(State)를 자동으로 유지함

즉, 쿠버네티스는 여러 개의 컨테이너를 쉽고 안정적으로 생성, 관리, 확장할 수 있도록 돕는 자동화된 운영체제와 같다.

2. 쿠버네티스 구조

쿠버네티스는 Docker에 비해 훨씬 복잡하고 다양한 구성 요소로 이루어져 있다. 이는 단순한 컨테이너 실행을 넘어, 대규모 클러스터의 상태를 유지하고 관리해야 하기 때문이다.

여기서는 쿠버네티스를 구성하는 클러스터, 컨트롤 플레인, 노드, 워크로드, 네트워크, 스토리지에 대해 알아본다.

2.1. 쿠버네티스 클러스터(Cluster)

쿠버네티스는 단일 서버가 아닌 다수의 노드(Node)가 모여 하나의 시스템처럼 동작하는 클러스터(Cluster) 구조를 가진다.

클러스터는 크게 두 가지 역할로 나뉜다.

  • 마스터 노드(Master Node)
    • 클러스터 전체를 제어하고 관리(컨트롤 플레인)
  • 워커 노드(Worker Node)
    • 실제 애플리케이션(컨테이너)이 실행되는 곳

일반적으로 개발자(운영자)는 마스터 노드에 명령을 내려 클러스터를 관리하고, 실제 서비스를 이용하는 사용자는 인터넷을 통해 워커 노드에 배포된 애플리케이션에 접근한다.

쿠버네티스 구조(1)

이러한 분산 환경에서 마스터 노드와 워커 노드, 그리고 각 노드 내부의 컨테이너들이 유기적으로 통신하기 위해서는 CNI(Container Network Interface)가 필수적이다.

  • CNI(Container Network Interface)
    • 쿠버네티스 클러스터 내의 컨테이너 간 통신을 위한 표준 인터페이스
  • 네트워크 플러그인
    • CNI를 구현한 구현체로 Flannel, Calico, Weave등이 있음
    • 여기서는 보안 정책 설정 등 강력한 기능을 제공하며 널리 사용되는 Calico를 기준으로 설명함

2.2. 컨트롤 플레인(Control Plain)

컨트롤 플레인은 쿠버네티스 클러스터의 ‘두뇌’에 해당한다.
주로 마스터 노드에서 실행되며, 클러스터 전반적인 상태를 관리하고 스케줄링하는 역할을 담당한다.

컨트롤 플레인은 API 서버, etcd, 스케줄러, 컨트롤러 매니저 이렇게 4가지 핵심 컴포넌트로 구성된다.

쿠버네티스 구조(2)

  • API 서버(kube-apiserver)
    • 쿠버네티스 컨트롤 플레인의 프런트엔드 역할을 함
    • 사용자가 kubectl 명령어를 사용하거나, 내부 컴포넌트들이 서로 통신할 때 모든 요청을 이 API 서버를 거쳐감
  • etcd
    • 클러스터의 모든 설정 데이터와 상태 정보를 저장하는 고가용성 key-value 저장소
    • 쿠버네티스의 모든 데이터가 이곳에 저장되므로, etcd의 백업과 관리는 매우 중요함
  • 스케줄러(kube-scheduler)
    • 새로 생성된 Pod를 감지하고, 이를 어떤 노드(Node)에 배치할 지 결정함
    • 노드의 자원 상태(CPU, 메모리)와 제약 조건을 고려하여 최적의 노드를 선정함
  • 컨트롤러 매니저(kube-controller-manager)
    • 클러스터의 상태를 모니터링하고, 원하는 상태를 유지하려고 노력하는 무한 루프 데몬임
    • 논리적으로 다양한 컨트롤러(Deployment, ReplicaSet, 서비스 컨트롤러 등)가 포함되어 있으며, 각 리소스가 의도한 대로 동작하도록 관리함

2.3. 노드(Node)

실제 애플리케이션이 동작하는 워커 노드(Worker Node)의 핵심 구성 요소를 알아본다.

  • Kubelet(쿠블릿)
    • 모든 노드에서 실행되는 에이전트
    • API 서버의 명령을 받아 Pod를 생성/관리하며, 자신의 노드 상태를 마스터에게 보고함
    • Pod 상태에 이상이 있다면 해당 Pod를 재배포함
  • Kube-Proxy(쿠베 프록시)
    • 노드의 네트워크 규칙을 관리함
    • 클러스터 내부나 외부에서 Pod로 네트워크 통신이 가능하도록 함
  • 컨테이너 런타임(Container Runtime)
    • 실제로 컨테이너를 실행하는 소프트웨어
    • 컨테이너 런타임으로 과거에는 도커가 주류였으나, 현재는 containerd, CRI-O등이 사용되며, 여기서는 보편적인 containerd를 사용함
  • Pod(파드)
    • 쿠버네티스의 최소 배포 단위
      • 도커는 ‘컨테이너’가 단위였지만, 쿠버네티스는 ‘Pod’가 단위임
    • Pod는 하나 이상의 컨테이너 그룹임
    • 특징
      • 단일 노드 할당: 하나의 Pod는 반드시 하나의 노드에 존재함(여러 노드에 걸쳐 쪼개지지 않음)
      • 일시적 존재(Ephemeral): Pod는 영구적이지 않음, 재생성될 때마다 새로운 IP를 할당받음
      • 자원 공유: 같은 Pod 내의 컨테이너들은 IP와 저장소(Volume)을 공유함

2.4. 워크로드(Workload)

워크로드는 쿠버네티스 위에서 실행되는 애플리케이션의 형태를 정의한다.
단순히 Pod 하나를 띄우는 것이 아니라 Pod를 어떻게 관리하고 복제할지를 결정하는 상위 개념이다.

워크로드의 종류는 아래와 같다.

  • 레플리카셋(ReplicaSet)
    • 지정된 수(Replicas)만큼의 Pod가 항상 실행되도록 보장함
  • 디플로이먼트(Deployment)
    • 가장 널리 사용되는 워크로드임
    • 레플리카셋을 관리하며 애플리케이션의 배포(업데이트, 롤백)관리에 특화되어 있음
  • 스테이트풀셋(StatefulSet)
    • DB와 같이 상태(State)가 있는 애플리케이션을 위해 사용함
    • Pod의 순서와 고유한 ID(네트워크 식별자)를 보장함
  • 데몬셋(DaemonSet)
    • 모든 노드(또는 특정 노드들)에 Pod가 하나씩 실행되도록 보장함
    • 주로 로그 수집기(Fluentd), 모니터링 에이전트(Prometheus Node Exporter) 등 시스템 관리용으로 사용됨
  • 잡과 크론잡(Job and Cronjob)
    • 잡과 크론잡은 작업(Task)이 정상적으로 완료되고 종료되는 것을 담당함
    • Job
      • 작업이 성공적으로 완료되면 종료되는 일회성 작업 처리
    • CronJob
      • 스케줄에 따라 주기적으로 Job 생성(예: 매일 밤 데이터 백업)

2.5. 네트워크(Network)

쿠버네티스 환경에서 외부와 통신하거나 내부 Pod끼리 통신하기 위한 추상화된 개념이다.

  • 서비스(Service)
  • Pod는 일시적이어서 IP가 계속 변경됨. 서비스는 고정된 IP와 DNS를 제공하여, 여러 Pod를 하나의 논리적인 그룹으로 묶어 접근할 수 있도록 해줌(로드밸런싱 역할)
  • 실행 중인 Pod를 수정하지 않고도 외부로 노출할 수 있는 장점이 있음
  • 인그레스(Ingress)
    • 클러스터 외부에서 내부의 서비스로 접근하는 요청(HTTP/HTTPS)을 처리하는 규칙의 모음
    • 도메인 기반 라우팅, SSL 인증서 처리 등을 담당함

2.6. 스토리지(Storage)

컨테이너의 가장 큰 특징 중 하나는 휘발성이다.
컨테이너가 삭제되거나 재시작되면 내부 데이터도 함께 사라진다.

  • 데이터베이스나 로그 파일처럼 데이터를 영구적으로 보존해야 할 때 쿠버네티스 스토리지(Persistent Volume 등)를 사용함
  • 이를 통해 Pod의 생명주기와 무관하게 데이터를 안전하게 보관할 수 있음

참고 사이트 & 함께 보면 좋은 사이트

본 포스트는 장철원 저자의 한 권으로 배우는 도커&쿠버네티스를 기반으로 스터디하며 정리한 내용들입니다.




© 2020.08. by assu10

Powered by assu10