Udemy CKA 강의 정리 11: Cluster Architecture

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests  강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.

⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.

---

이 강의에서는 쿠버네티스 클러스터 아키텍처의 기본 개요를 다룹니다. 먼저 아키텍처를 대략적으로 살펴보고, 각 구성 요소를 드릴다운 하겠습니다. 각 구성요소의 역할, 책임, 어떻게 구성되어 있는지를 보겠습니다. 그리고 마지막으로 기존 클러스터를 확인하는 테스트와 다양한 세부 사항을 식별하도록 묻는 테스트를 통과하면 됩니다.

Kubernetes Architecture

클러스터의 구성 요소를 설명하기 위해 선박(ship)을 비유로 사용하겠습니다. 쿠버네티스의 목적은 자동화된 방식으로 컨테이너 형태로 애플리케이션을 호스팅하여 애플리케이션 내의 서로 다른 서비스 간에 쉽게 통신 가능하고, 애플리케이션의 많은 인스턴스를 쉽게 배포할 수 있도록 하는 것입니다. 이 목적을 달성하기 위해 함께 작동하는 많은 것들이 있습니다.

쿠버네티스 아키텍처를 10,000피트 정도 떨어져서 본다고 합시다. 두 종류의 선박이 있다고 가정합니다. 하나는 실제 바다를 건너 컨테이너를 운반하는 화물선 선박이고, 다른 하나는 모니터링하고 화물선을 관리하는 control(제어) 선박 입니다.

쿠버네티스 클러스터는 일련의 노드로 구성됩니다. 이 노드는 물리적일 수도 있고, 가상일 수도 있습니다. 온프레미스일 수도 있고 클라우드일 수도 있습니다. 노드들은 컨테이너 형태로 애플리케이션을 호스팅합니다.

Master Nodes

클러스터의 워커 노드는 컨테이너를 실을 수 있는 선박입니다. 하지만 누군가가 컨테이너를 실어주어야 합니다. 단순히 싣는 것 뿐만이 아니라 컨테이너를 싣는 방법을 계획하고, 올바른 선박을 식별하고, 선박에 대한 정보를 저장하고, 선박에 들어간 컨테이너의 위치를 모니터링하고 추적하는 등 전체 선적 프로세스를 관리하는 역할이 필요합니다. 이 역할을 수행하는 것이 제어 선박(마스터 노드)입니다.

제어 선박은 서로 다른 사무실과 부서, 모니터링 장비, 통신 장비, 선박 사이에서 컨테이너를 옮기는 크레인 등을 호스팅합니다. 제어 선박은 쿠버네티스 클러스터의 마스터 노드와 관련이 있습니다. 마스터 노드의 역할은 쿠버네티스 클러스터를 관리하고, 다른 노드에 대한 정보를 저장하고, 어떤 컨테이너가 어디로 갈지 계획하고, 노드와 컨테이너들을 모니터링 합니다. 마스터 노드는 이 모든 작업들을 control playing components 라고 알려진 컴포넌트들의 집합을 사용하여 수행합니다.

ETCD Cluster

이제 마스터노드의 각 컴포넌트들을 살펴보겠습니다. 매일 많은 컨테이너가 적재되고 내려지고 있습니다. 이 때 다른 선박들에 대해서, 그리고 어떤 컨테이너가 어떤 선박에 있는 지, 적재된 시간 등 모든 정보를 유지관리해야 합니다. 이 정보들은 etcd라는 highly available key value store에 있습니다. etcd는 정보를 키 값 형식으로 저장하는 데이터베이스입니다. etcd 클러스터가 실제로 무엇인지 뒤에 올 강의에서 자세히 살펴보겠습니다.

kube-scheduler

선박이 도착하면 크레인을 사용하여 컨테이너를 적재합니다. 크레인은 배에 실어야 할 컨테이너를 골라냅니다. 또한 크레인은 선박의 크기, 용량, 선박에 이미 있는 컨테이너의 수, 배의 목적지, 실을 수 있는 컨테이너의 유형 등을 고려하여 올바른 선박을 고릅니다.

이 비유에서의 크레인은 쿠버네티스 클러스터의 스케쥴러입니다. 스케쥴러는 containers resource requirements, 워커 노드 용량, taints와 같은 기타 정책이나 제약조건 & 허용조건, 노드 우선순위 규칙 을 참고하여 컨테이너를 배치할 올바른 노드를 선택합니다. 우리는 뒷부분에 있는 예제와 모의 테스트를 통해 스케쥴러에 대해 더 자세히 살펴볼 것입니다. 스케쥴링만 다루는 섹션이 하나 있습니다.

Controller-Manager

부두(dock)에는 특별한 작업이나 부서에 할당된 사무실들이 있습니다. 예를 들어 운영팀은 선박 취급, 교통 통제 등 피해와 관련된 문제와 다른 배가 가는 경로 등을 다루고 있으며, 화물팀은 컨테이너가 훼손된 경우 새 컨테이너를 사용할 수 있는지 확인합니다. 서비스팀은 다른 선박 간의 IT 통신을 관리합니다.

Node-Controller

마찬가지로 쿠버네티스에는 다양한 영역을 관리하는 컨트롤러가 있습니다. 노드 컨트롤러는 노드를 관리합니다. 새 노드를 클러스터에 온보딩하는 일을 담당하거나, 노드를 사용할 수 없거나 파괴되는 상황을 다룹니다.

Replication-Controller

replication 컨트롤러는 항상 원하는 수의 컨테이너가 replication 그룹에서 실행중이라는 것을 보장합니다.

kube-apiserver

사무실, 선박, 데이터 저장소, 크레인 등 서로 다른 컴포넌트들은 어떻게 통신할까요? 이런 컴포넌트들을 누가 하이레벨에서 관리할까요? Kube API 서버는 쿠버네티스의 기본 관리 컴포넌트입니다.

Kube API 서버는 클러스터 내의 모든 작업을 오케스트레이션합니다. Kube API 서버는 클러스터에서 관리 작업을 수행하기 위해 외부 사용자가 사용하는 쿠버네티스 API를 노출합니다. 뿐만 아니라, 클러스터의 상태를 모니터링하고 필요에 따라 필요한 사항을 변경하기 위해 다양한 컨트롤러들도 노출합니다. 그리고 워커노드가 서버와 통신합니다.

지금 우리는 컨테이너로 작업하고 있습니다. 컨테이너는 어디에나 있으며 우리는 모든 것을 컨테이너와 호환해야 합니다. 우리의 애플리케이션은 컨테이너 형태입니다. 마스터 노드의 전체 관리 시스템에 있는 다양한 컴포넌트들은 컨테이너 형태로 호스팅 될 수 있습니다. DNS서비스 네트워킹 솔루션은 모두 컨테이너 형태로 배포될 수 있습니다.

따라서 컨테이너를 실행(run)할 수 있는 소프트웨어가 필요합니다. 이것이 컨테이너 런타임 엔진입니다. 그 중 인기 있는 것이 도커 입니다. 따라서 제어 컴포넌트를 컨테이너로 호스팅하기 위해서는 마스터 노드를 포함한 클러스터의 모든 노드에 도커나 다른 지원되는 런타임 엔진이 필요합니다. 항상 도커일 필요는 없습니다. 쿠버네티스는 ContainerD, Rocket과 같은 다른 런타임 엔진도 지원합니다.

Worker Nodes

이제 화물선 선박(워커 노드)에 초점을 맞추겠습니다.

kubelet

모든 배에는 선장이 있습니다. 선장은 선박의 모든 활동을 관리합니다. 마스터 선박과의 연락을 담당하여 선장의 선박이 그룹 참여에 관심이 있다는 것을 마스터 선박(제어 선박)에 알게하고, 선박에 적제되는 컨테이너에 대한 정보 수신, 필요에 따라 적절한 컨테이너를 적재하고 마스터 선박에게 이 배의 상태와 선박의 컨테이너 상태에 대한 보고서를 다시 보내는 등을 가능하게 합니다.

배의 선장은 Kubernetes의 Kubelet입니다. kubelet은 클러스터의 각 노드에서 실행되는 에이전트입니다. Kube API 서버의 지시를 수신하고 필요에 따라 노드에 컨테이너를 배포하거나 제거합니다. KubeAPI서버는 kubelet으로부터 노드와 컨테이너의상태를 모니터링한 상태 보고서를 주기적으로 가져옵니다.

kube-proxy

kubelet이 컨테이너를 관리하는 선박의 선장의 역할을 하지만, 워커 노드에서 실행되는 어플리케이션들도 서로 소통해야 합니다. 예를 들어 한 컨테이너의 노드중 하나에서 웹 서버가 실행중이라고 합시다. 그리고 데이터베이스 서버가 다른 컨테이너의 다른 노드에서 실행 중입니다. 웹 서버는 어떻게 다른 노드에 있는 데이터베이스 서버에 접근할 수 있을까요? 워커 노드 간 통신이 워커 노드에 있는 다른 컴포넌트인 Kube Proxy Service 에 의해 가능합니다. Kube Proxy Service는 그 워커 노드에 있는 컨테이너들이 서로 접근 할 수 있도록 하는 필수 규칙이 워커 노드에 있는지를 확인합니다.

요약하자면, 마스터 노드와 워커 노드가 있습니다.

마스터 노드에는 ETCD클러스터가 있습니다. ETCD클러스터는 클러스터에 대한 정보를 저장합니다. 마스터 노드에는 kube-scheduler도 있었습니다. kube-scheduler는 노드들의 어플리케이션이나 컨테이너들을 스케쥴링합니다. 또한 노드 컨트롤러, replication 컨트롤러 등 다양한 기능을 하는 다양한 컨트롤러가 있었습니다. 또한 클러스터 내의 모든 작업을 오케스트레이션하는 KubeAPI서버도 있었습니다.

워커 노드에는 KubeAPI의 지시를 대기하는 kubelet이 있습니다. kubelet은 컨테이너들과 Kube proxy를 관리하기도 합니다. Kube proxy는 클러스터 내의 서비스 간 통신을 가능하게 도와줍니다. 이것이 다양한 컴포넌트에 대한 개요입니다. 다음 강의들에서 각 컴포넌트를 드릴다운하겠습니다.