[쿠버네티스 인 액션] Ch1. 쿠버네티스 소개

쿠버네티스란?

 쿠버네티스는 컨테이너화된 애플리케이션을 쉽게 배포하고 관리할 수 있게 해주는 소프트웨어 시스템이다. 쿠버네티스를 사용해 애플리케이션을 배포한다면, 애플리케이션에 포함되어 있는 각각의 기능은 각각의 컨테이너에서 수행되어 동일한 서버에서 실행되더라도 다른 애플레케이션에 영향을 주지 않는다는 특징을 가지고 있다. 쿠버네티스는 컨테이너화하여 애플리케이션을 관리하기 때문에 클러스터에 수천 개의 노드가 있던지 수만 개의 노드가 있던지 쿠버네티스에 애플리케이션을 배포하는 방식은 동일하다. 

 

쿠버네티스 시스템 이해하기

마스터 노드와 워커 노드로 구성된다. 아래 그림에서 마스터 노드는 Control plane, 워커 노드는 Compute machines로 표현되어 있다.

쿠버네티스 클러스터 구성 요소 ❘ 출처: RedHat

 

✔️ 마스터 노드

 마스터 노드는 전체 쿠버네티스 시스템을 제어하고 관리하는 쿠버네티스의 컨트롤 플레인(Control plane)을 실행한다. 컨트롤 플레인은 쿠버네티스의 고가용성을 보장하기 위해 여러 컴포넌트로 구성된다.

 

 1. kube-apiserver: 컨트롤 플레인의 프론트엔드로, 사용자와 컨트롤 플레인 구성 요소와 통신한다. 내부 및 외부 요청을 처리할 때 요청이 유효한지 판별하고 유효한 요청을 처리한다.

2. kube-scheduler: 애플리케이션의 배포를 담당하는 구성 요소로, cpu 또는 메모리와 같은 파드의 리소스 요구 사항과 함께 클러스터의 상태를 고려하고, 적절한 워커 노드에 파드를 예약한다.

3. kube-controller-manager: 클러스터단의 기능을 수행하는 구성 요소로, 워커 노드 추적, 노드 장애 처리, 구성 요소 복제본과 같은 여러 컨트롤러 기능을 수행한다.

4. etcd: 분산 데이터 저장소로, 쿠버네티스의 설정 데이터와 클러스터 상태에 대한 정보를 키-값 데이터로 저장한다.

 

 

✔️ 워커 노드

 워커 노드는 컨테이너화된 애플리케이션을 실행하는 시스템으로, 쿠버네티스는 일반적으로 여러 개의 워커 노드를 가지고 있다. 워커 노드는 애플리케이션을 실행하고 서비스를 제공하는 작업을 위해 여러 컴포넌트로 구성되어 있다.

 

1. pod: 쿠버네티스에서 가장 작은 단위로, 애플리케이션의 단일 인스턴스를 나타낸다. 파드는 노드에서 실행되도록 예약되고 오케스트레이션된다.

2. container runtime: 컨테이너 실행을 위해 각 컴퓨팅 노드에 docker, rkt과 같은 컨테이너 런타임이 존재한다.

3. kubelet: 컨트롤 플레인과 통신하고, 컨테이너가 파드에서 실행되도록 한다. 컨트롤 플레인에서 노드에 작업을 요청하면 kubelet이 작업을 실행한다.

4. kube-proxy: 애플리케이션 구성 요소 간에 네트워크 트래픽을 로드밸런싱 한다.

---

쿠버네티스에서 애플리케이션 실행하기

애플리케이션을 하나 이상의 컨테이너 이미지로 패키징하기 -> 해당 컨테이너 이미지를 이미지 레지스트리로 푸시하기 -> 쿠버네티스 api 서버에 애플리케이션 디스크립션(yaml) 게시하기

 

YAML파일로 컨테이너 실행하기

1️⃣ 스케줄러는 각 컨테이너에 필요한 리소스를 계산한다. 

2️⃣ 해당 시점에 각 노드에 할당되지 않은 리소스를 기반으로 사용 가능한 워커 노드에 지정된 컨테이너를 할당한다.

3️⃣ 해당 노드의 kubelet은 컨테이너 런타임에 필요한 컨테이너 이미지를 가져와 컨테이너를 실행하도록 지시한다.

 

출처: 쿠버네티스 인 액션

 위의 그림을 보자. YAML파일(앱 디스크립터)은 세 개 세트(세 개 파드)로 그룹화된 네 개의 컨테이너를 가진다. 3번째 세트는 2개의 컨테이너를 가지기 때문에 이 두 컨테이너는 함께 배치해야 한다.

 애플리케이션이 실행되면 쿠버네티스는 애플리케이션의 배포 상태가 사용자가 제공한 YAML 파일과 일치하는지 지속적으로 확인한다. 예를 들어 항상 다섯 개의 웹 서버 인스턴스를 실행하도록 지정하면 쿠버네티스는 항상 다섯 개의 인스턴스를 계속 실행한다. 만약 프로세스가 중단되거나 응답이 중지될 때처럼 인스턴스가 제대로 작동하지 않는다면 쿠버네티스는 자동으로 다시 시작한다. 마찬가지로 워커 노드 전체가 종료되거나 액세스가 불가하게 되면 쿠버네티스는 이 노드에서 실행 중인 모든 컨테이너의 노드를 새롭게 스케줄링하고 새로 선택한 노드에서 실행한다.

 

이동한 애플리케이션에 접근하기

 실행 중인 노드가 정지되거나 컨테이너가 노드에서 제거되면 쿠버네티스는 컨테이너를 클러스터 안에서 이동시킬 수 있다. 그런데 컨테이너가 클러스터에서 지속적으로 이동한다면 컨테어는 어떻게 적절히 사용될 수 있을까?

 클라이언트가 특정 서비스를 제공하는 컨테이너를 쉽게 찾을 수 있게 쿠버네티스에게 동일한 서비스를 제공하는 컨테이너를 알려주면 쿠버네티스느 하나의 고정 ip로 모든 컨테이너를 노출하고 해당 주소를 클러스터에서 실행 중인 모든 애플리케이션에 노출한다. 서비스의 ip주소는 항상 일정하게 유지되므로 클라이언트는 컨테이너가 클러스터 내에서 이동해도 항상 컨테이너에 연결될 수 있다.