쿠버네티스 이해하기

컨테이너 인프라 환경이란?

컨테이너 인프라 환경이란 리눅스 운영 체제의 커널 하나에서 여러 개의 컨테이너가 격리된 상태로 실행되는 인프라 환경이다. 여기서 컨테이너는 하나 이상의 목적을 위해 독립적으로 작동하는 프로세스이다.

컨테이너 오케스트레이션을 위한 다양한 솔루션

• 도커 스웜: 간단하게 설치할 수 있고 사용하기도 용이. 그러나 기능이 다양하지 않아 대규모 환경에 적용하려면 사용자 환경을 변경해야 할 수 있다.
• 메소스: 기능을 충분히 활용하려면 분산 관리 시스템과 연동해야 한다. 따라서 여러 가지 솔루션을 유기적으로 구성해야 하는 부담이 있다.
• 노매드: 도커 스웜과 마찬가지로 기능이 부족하므로 복잡하게 여러 기능을 사용하는 환경이 아닌 가볍고 간단한 기능만 필요한 환경에서 사용하기를 권장.
• 쿠버네티스: 다른 오케스트레이션 솔루션보다 시작하는 데 어려움이 있지만, 쉽게 사용할 수 있도록 도와주는 도구들이 있어서 설치가 쉬워지는 추세이다. 거의 모든 벤더와 오픈소스 진영 모두에서 쿠버네티스를 지원하고 그에 맞게 통합 개발하고 있다. 따라서 컨테이너 오케이스트레이션을 학습하거나 도입하려고 한다면 쿠버네티스를 우선적으로 고려해야 한다.

쿠버네티스 구성 방법

1. 퍼블릭 클라우드 업체에서 제공하는 관리형 쿠버네티스인 EKS,AKS,GKE 등을 사용하는 방법. 구성이 이미 다 갖춰져 있고 마스터 노드를 클라우드 업체에서 관리하기 때문에 학습용으로는 적합하지 않다.
2. 수세의 Rancher, 레드햇의 OpenShift와 같은 플랫폼에서 제공하는 설치형 쿠버네티스를 사용하는 경우. 유료라 접근하기 어렵다.
3. 사용하는 시스템에 쿠버네티스 클러스터를 자동으로 구성해주는 솔루션을 사용. 주요 솔루션으로는 kubeadm, kops, KRIB, kubespray가 있다.

쿠버네티스 구성하기

마스터 노드

• kubectl: 쿠버네티스 클러스터에 명령을 내리는 역할. 다른 구성 요소들과 다르게 바로 실행되는 명령 형태인 바이너리로 배포되기 때문에 마스터 노드에 있을 필요는 없다. 하지만 통상적으로 API 서버와 주로 통신하므로 API 서버가 위치한 마스터 노드에 구성
• API 서버: 쿠버네티스 클러스터의 중심 역할을 하는 통로. 주로 상태 값을 저장하는 etcd와 통신하지만, 그 밖의 요소들 또한 API 서버를 중심에 두고 통신하므로 API 서버의 역할이 매우 중요하다.
• etcd: 구성 요소들의 상태 값이 모두 저장되는 곳. 그러므로 etcd 정보만 백업돼 있다면 긴급한 장애 상황에서도 쿠버네티스 클러스터는 복구할 수 있다.
• 컨트롤러 매니저: 쿠버네티스 클러스터의 오브젝트 상태를 관리. 예를 들어 워커 노드에서 통신이 되지 않는 경우, 상태 체크와 복구는 컨트롤러 매니저에 속한 노드 컨트롤러에서 이루어진다.
• 스케줄러: 노드의 상태와 자원, 레이블, 요구 조건 등을 고려해 파드를 어떤 워커 노드에 생성 할 것인지 결정하고 할당한다.

워커 노드

• kubelet: 파드의 구성 내용을 받아서 컨테이너 런타임으로 전달하고, 파드 안의 컨테이너들이 정상적으로 작동하는지 모니터링한다.
• 컨테이너 런타임: 파드를 이루는 컨테이너의 실행을 담당한다. 파드 안에서 다양한 종류의 컨테이너가 문제 없이 작동하게 만드는 표준 인터페이스.
• 파드: 한 개 이상의 컨테이너로 단일 목적의 일을 하기 위해서 모인 단위이다. 즉, 웹 서버 역할을 할 수도 있고 로그나 데이터를 분속할 수도 있다. 파드는 언제라도 죽을 수 있는 존재이다.

선택 가능한 구성요소

• 네트워크 플러그인: 쿠버네티스 클러스터의 통신을 위해서 네트워크 플러그인을 선택하고 구성해야 한다.
• CoreDNS: 클라우드 네이티브 컴퓨팅 재단에서 보증하는 프로젝트로, 빠르고 유연한 DNS서버이다. 쿠버네티스 클러스터에서 도메인 이름을 이용해 통신하는 데 사용한다.

사용자가 배포된 파드에 접속할 때

1. kube-proxy: 쿠버네티스 클러스터는 파드가 위차한 노드에 kube-proxy를 통해 파드가 통신할 수 있는 네트워크를 설정한다.
2. 파드: 이미 배포된 파드에 접속하고 필요한 내용을 전달 받는다. 이때 대부분 사용자는 파드가 어느 워커 노드에 위치하는지 신경 쓰지 않아도 된다.

파드의 생명 주기

1. kubectl을 통해 API 서버에 파드 생성을 요청한다.
2. API 서버에 전달된 내용이 있으면 API서버는 etcd에 전달된 내용을 모두 기록해 클러스터의 상태 값을 최신으로 유지한다. 따라서 각 요소가 상태를 업데이트 할 때마다 모두 API 서버를 통해 etcd에 기록된다.
3. API 서버에 파드 생성이 요청된 것을 컨트롤러 매니저가 인지하면 컨트롤러 매니저는 파드를 생성하고, 이 상태를 API 서버에 전달한다.
4. API 서버에 파드가 생성됐다는 정보를 스케줄러가 인지. 스케줄러는 생성된 파드를 어떤 워커 노드에 적용할지 조건을 고려해 결정하고 해당 워커 노드에 파드를 띄우도록 요청한다.
5. API 서버에 전달된 정보대로 지정한 워커 노드에 파드가 속해 있는지 스케줄러가 kubelet으로 확인한다.
6. kubelet에서 컨테이너 런타임으로 파드 생성을 요청
7. 파드가 생성
8. 파드가 사용 가능한 상태가 된다.

쿠버네티스는 작업을 순서대로 진행하는 워크플로 구조가 아니라 선언적인 시스템 구조를 가지고 있다. 즉, 각 요소가 추구하는 상태를 선언하면 현재 상태와 맞는지 점검하고 그것에 맞추려고 노력하는 구조로 돼 있다.