컨테이너 오케스트레이션의 등장

하나의 물리적인 컴퓨터에서 여러 애플리케이션을 실행하고자 가상화 방식이 도입되었고, 그보다 격리 속성을 완화하여 애플리케이션 간 OS를 공유하는 컨테이너 방식이 등장하였다. 이로써 여러 애플리케이션을 손쉽게 실행하고 중지시킬 수 있게 되었다. 각 애플리케이션을 컨테이너 단위로 운영할 수 있게 되었지만, 이들을 어떻게 통제할 것인가에 대한 고민이 생겼다.

전통적인 컴퓨터 위에서 OS가 여러 애플리케이션을 조작하기 위해 각 애플리케이션의 생명주기를 담당했었듯, 컨테이너들의 생명주기를 관리할 수 있는 무엇인가가 필요한 시점이 온 것이다.

[출처: 쿠버네티스 어나더 클래스 강의]

컨테이너 오케스트레이션은 이러한 필요성 때문에 등장하였으며, 이를 한마디로 정의하면 ‘컨테이너를 지원하는 일종의 운영체제’라고 할 수 있겠다.

컨테이너 오케스트레이션 도구로 docker swarm, kubernetes, Nomad 등이 존재했다. 그 중 쿠버네티스(K8s, Kubernetes)가 현재 압도적인 시장 점유율을 차지하고 있으며, 현재 표준을 넘어 여러 분야에서 활용되고 있다. 따라서 쿠버네티스와 인터페이스가 잘 맞는 컨테이너 환경을 개발하는 것이 중요해졌다.

도커 컨테이너를 클러스터로써 관리하기 위해 필요한 기능적 요건

• 물리적인 호스트의 자원부족을 해결하는 방법으로 여러 서버를 병렬 확장하여 클러스터로 구성
• 새로운 서버, 컨테이너 추가에 대한 탐지
• 컨테이너 스케줄링 기능
• 서버 다운 시 고가용성 보장

쿠버네티스는 ‘조타수(숙련된 선원)’라는 뜻을 갖는 그리스어다.

쿠버네티스는 구글이 내부에서 사용하던 컨테이너 관리 시스템에서 파생되었다. 2014년 오픈소스로 제공되었으며, 현재는 CNCF(Cloud Native Computing Foundation)에서 관리하고 있다.

• 주요 개념
  • 클러스터(Cluster): 컨테이너화된 애플리케이션을 실행하기 위한 물리적 또는 가상 컴퓨팅 리소스(노드)의 모음으로, 일반적으로 Control plane(마스터 노드)와 Data plane(워커 노드)로 구분한다.
  • 파드(Pod): 배포와 관리의 기본 단위로, 네트워크와 스토리지를 공유하는 하나 이상의 컨테이너 세트이다.
    • pod당 하나의 IP 할당
    • 스케줄링 최소 단위
    • 특정 네임스페이스에 launch
  • 네임스페이스(Namespace): 하나의 클러스터를 여러 개의 논리적인 단위로 나눠서 사용하게 될 때의 단위이며, 일반적으로 용도에 따라 실행해야 하는 앱을 구분할 때 사용한다. 네임스페이스 삭제 시 내부 자원들도 모두 삭제된다.
  • 볼륨(Volume): 컨테이너는 기본적으로 휘발성 스토리지를 사용하기 때문에 Pod가 재시작되면 데이터가 사라진다. 이를 보완하기 위해 쿠버네스는 데이터 영속화(Storage) 메커니즘을 제공한다.
  • API version: Kubernetes 리소스 및 기능이 어떻게 변경되고 발전하는지 관리하기 위해 사용되는 체계로, kubernetes object 정의시 api version이 필요하다. 각 리소스나 기능은 특정 API 그룹에 속하며, 이 그룹은 API 버전으로 구분된다. 주요 api 버전으로는 v1, alpha, beta, stable이 있다.

🤔개념

구성요소

[출처: 쿠버네티스 공식 홈페이지]

Control Plane(Master node)

Date Plane들의 상태를 관리하고 제어하는 노드로, 하나 또는 하나 이상으로 구성 가능하다. 이 노드에는 4인방(Static Pod)이 존재한다.

API server

쿠버네티스 클러스터의 모든 명령과 요청을 처리하는 중앙 통제소

• 특징
  • 모든 요청을 수신하는 역할을 한다.
  • K8s API를 사용하도록 요청을 받고 요청이 유효한지 검사한다.
  • 클러스터의 현재 상태를 etcd에 저장하고, 이를 바탕으로 상태를 관리한다.
  • 복수개 허용(active-active)

Scheduler

• 특징
  • 클러스터의 리소스 사용 현황을 모니터링하고, Pod를 배치할 노드(Data Plane)를 선택한다.
  • API를 통해 업데이트된 파드 상태를 etcd에 전송한다.
  • API를 통해 Kubelet에 통보하고, 통보받은 Data Plane 내의 Kubelet이 해당 노드에서 파드를 생성한다.
  • 다중 스케줄러 사용 가능
  • active-standby

etcd

쿠버네티스 클러스터의 모든 데이터(설정 및 상태 정보)를 저장하는 분산 키-값 저장소

• 특징
  • 분산된 환경에서 데이터의 일관성과 신뢰성을 보장한다.
  • 여러 복제본을 유지하여 데이터 손실을 방지하고 고가용성을 제공한다.

Cloud controller manager (optional)

클라우드에 쿠버네티스 구축 시 클라우드 서비스 제공자(CSP)의 스토리지, 네트워크 등의 서비스 간의 상호 작용을 관리하는 역할

• 특징
  • pod를 관찰하며 개수를 보장한다.
  • active-standby

Data Plane(Worker node)

도커 플랫폼을 통해 컨테이너를 동작시키며 실제로 서비스를 제공하는 노드이다. 이 노드에는 3인방이 존재한다.

Kubelet

한마디로 ‘자신의 노드 내 pod와 컨테이너의 생명주기를 관리하는 통제소’라 할 수 있겠다.

• 특징
  • API 서버로부터 Pod 사양을 받아서 해당 노드에서 실행되는 컨테이너를 시작하고 모니터링한다.
  • 각 Pod와 컨테이너의 상태를 지속적으로 확인하고, 문제가 발생하면 재시작하거나 복구 조치를 취한다.
  • 노드의 상태 정보를 API 서버에 보고하여 클러스터 단위로의 관리를 가능하게 한다.

Kube-proxy

쿠버네티스 클러스터의 네트워킹을 관리하여, 서비스 간의 통신을 가능하게 한다. API 서버와 상호작용하여 서비스와 엔드포인트 간의 네트워크 트래픽을 라우팅한다.

• 특징
  • 서비스에 대한 요청(부하)을 여러 Pod에 분산한다(로드 밸런싱).
  • IP주소 및 포트를 관리한다.
  • 트래픽 처리: 서비스의 ClusterIP와 NodePort를 관리하여 외부 및 내부 트래픽을 처리한다.
  • 네트워크 규칙 관리: iptables 또는 IPVS를 사용하여 클러스터 내의 네트워크 규칙을 관리한다. 이러한 규칙은 서비스와 엔드포인트 간의 트래픽 흐름을 정의하며, kube-proxy는 이 규칙들을 동적으로 업데이트하여 클러스터 상태의 변화를 반영한다.
    • 엔드포인트 연결을 위한 iptables를 구성 ⇒ 클라이언트의 service API 요청 시 iptables rule이 생성된다.
      

Container run time

컨테이너의 실제 실행을 담당하는 소프트웨어이다.

ex) Containerd(docker에서 분리되어 나옴), CRI(Container Runtime Interface)-O 등

• CRI(Container Runtime Interface): Kubelet과 컨테이너 런타임 간의 통신 규격이다. 이 규격 덕분에 쿠버네티스는 특정 런타임에 종속되지 않는다.
• 역할
  • 컨테이너 관리: 컨테이너의 생성, 실행, 중지 등을 담당한다.
  • 이미지 관리: 컨테이너 이미지를 다운로드하고 저장하며, 이를 기반으로 컨테이너를 실행한다.

주요 배포 전략

배포 전략	설명	활용되는 경우	장점	단점
Recreate	모든 기존 파드를 먼저 종료 후 새 파드를 생성하는 방식	다운타임이 허용되는 단순 업데이트 시 주로 사용됨.	간단하고 명확	전체 애플리케이션의 다운타임이 존재함.
롤링 업데이트	새 버전의 파드를 순차적으로 교체하여 다운타임을 최소화하고 애플리케이션의 가용성을 유지.		가용성 유지 / 점진적 업데이트 / 다운타임 최소화	업데이트 중 문제가 발생 시 전체 클러스터가 영향 받을 수 있음.
Blue-Green 배포	두 개의 환경 Blue, Green을 사용하여 배포하는 방식으로, Green 환경에 새 버전을 배포하고 테스트한 후, 트래픽을 Green 환경으로 전환. 문제가 발생하면 Blue 환경으로 롤백.		무중단 배포 / 빠른 롤백 가능	두 배의 리소스 필요 / 복잡한 트래픽 전환 전략 필요
Canary 배포	새 버전의 일부 파드를 배포하여 트래픽의 일부를 해당 파드로 보내고, 문제가 없으면 점진적으로 전체 배포를 진행하는 방식.		점진적 업데이트 / 문제 발생 시 빠른 롤백 가능	배포 관리 복잡성 증가 / 트래픽 라우팅 필요
A/B Testing	두 가지 버전을 제공하여 사용자들에게 제공하고, 그 결과를 바탕으로 한 가지 버전을 선택하여 배포하는 방식.	주로 UI/UX 개선 테스트에 사용됨.	사용자 반응 테스트 가능 / 데이터 기반 의사결정 가능	테스트 설정 복잡성 증가 / 분석 도구 필요

도움되는 사이트
쿠버네티스 플레이그라운드: Killercoda Interactive Environments

참고자료
쿠버네티스란 무엇인가?