Kubernetes의 목적
1. 자동화된 방식으로 컨테이너 형태로 애플리케이션을 호스팅하는 것
2. 애플리케이션 내의 서로 다른 서비스 간에 필요한 만큼 애플리케이션의 인스턴스를 쉽게 배포하고 통신을 쉽게 활성화
Kubernetes의 아키텍처는 선박에 비유할 수 있다.
예를 들어 두 종류의 배를 가지고 있다.
1. 컨테이너를 바다로 운반하고 제어하는 실제 작업을 수행하는 화물선
2. 화물선의 감시 및 관리를 담당하는 선박
컨테이너 형태로 애플리케이션을 호스팅하는 클라우드는 화물선으로 볼 수 있다.
클러스터의 작업자 노드는 컨테이너를 적재 할 수 있는 선박이다.
여기서 모니터링 장비를 제공하는 제어 선박은
1. 선박에 컨테이너를 적재
2. 적재 방법 계획
3. 선박에 대한 정보를 저장
4. 선박의 컨테이너 위치를 모니터링하고 추적
등과 같은 선박의 적재에 관련한 모든 프로세스를 관리한다.
# Control plane 구성요소
다른 노드에 대한 정보를 저장하는 클러스터는 어떤 컨테이너가 모니터링을 유발하는지 계획하고
메모 및 컨테이너 등. 마스터 노드는 구성 요소 집합을 함께 사용하여 이 모든 작업을 수행한다.
ETCD Cluster
ETCD 는 키 - 값 형식으로 정보를 저장하는 데이터 베이스이다.
매일 많은 컨테이너가 배에서 싣고 내린다 따라서 다른 선박에 대한 정보를 유지해야 하며 어떤 컨체이너가 선백에 있는지, 적재된 시간 등을 고가용성 키 값 저장소에 저장된다.
Kube-scheduler
선박이 도착하면 크레인을 사용하여 컨테이너를 적재하고 크레인은 선박에 적재해야 할 컨테이너를 식별한다.
이미 선적된 컨테이너의 수, 선박의 목적지, 운반할 수 있는 컨테이너 유형 등을 고려하여 컨테이너의 크기에 따라 적합한 배를 고른다.
scheduler는 컨테이너를 기준으로 컨테이너를 배치할 올바른 장소를 메모하고
스케줄러는 컨테이너를 기준으로 컨테이너를 배치할 올바른 노트를 식별한다. 작업자 노드가 요구하는 리소스와 기타 정책 또는 제약 조건을 고려하여 스케줄링 한다.
Controller-Manager
Node-Controller는 노드를 관리한다. 새로운 노드의 승선(onboarding) 작업을 책임진다. 노드를 사용할 수 없게 되면 제거하여 복제한다. Replication-Controller는 원하는 수의 컨테이너가 항상 실행되도록 보장한다.
그러나 이것들은 어떻게 서로 통신을 할까?
한 사무실이 다른 사무실에 어떻게 연결되고 누가 이들을 관리를 할까?
Kube-apiserver
Kubernetes 의 기본 관리 구성요소인 Kube-apiserver는 클러스터 내의 모든 작업을 조정(orchestration)한다.
외부 사용자가 관리 작업을 수행하는데 사용하는 Kubernetes API 를 노출한다. 클러스터뿐만 아니라 클러스터 상태를 모니터링 하고 필요한 서버와 통신하기 위해 작업자 노드가 필요에 따라 변경한다.
클러스터뿐만 아니라 클러스터 상태를 모니터링하고, 필요에 따라 필요한 변경을 수행할 수 있는 다양한 컨트롤러와 서버와 통신하는 작업자 노드가 필요하다. 컨테이너는 어디에나 있기 때문에 컨테이너 호환을 위해 모든 것이 필요하다. 애플리케이션은 전체 관리 시스템을 구성하는 다양한 구성 요소의 컨테이너 형태로 제공된다. Master Node에서 컨테이너 형태로 제공 될 수 있다. DNS service, networking solution 모두 컨테이너 형태로 배포될 수 있다.
그래서 우리는 컨테이너를 구동할 수 있는 소프트웨어가 필요하다. 그것이 컨테이너 런타임 엔진( Container Runtime Engine)이다.
가장 인기있는것은 Docker 이다. 따라서 마스터 노드를 포함하여 클러스터의 모든 노드에 Docker 또는 Docker의 기능이 지원되는 소프트웨어가 설치되어 있어야 한다.
Control-Plane 구성 요소를 컨테이너로 제공하려는 경우, 꼭 Docker 를 사용 할 필요는 없다. Kubernetes는 ContainerD 또는 Rocket과 같은 다른 런타임 엔진도 지원한다.
다시 화물선으로 초점을 맞춰보자
모든 배에는 선장이 있다. 선장은 선박의 모든 활동을 관리할 책임이 있다.
선장은 Master 선박에게 연락을 한다.
선박에 적재할 컨테이너에 대한 정보를 받고 필요에 따라 적절한 컨테이너를 적재하는 그룹에 참여하는 데 관심이 있다는 것을 알고, 이 선박의 상태와 선박에 있는 컨테이너의 상태에 대한 보고서를 마스터에게 보낸다.
이제 그 배의 선장은 Kubernetes에 있는 kubelet 이다. kubelet 은 클러스터의 각 노드에서 실행되는 에이전트이다. kubelet은 필요에 따라 kube-api 서버의 지시를 듣고 노드에서 컨테이너를 배포하거나 제거한다.
kube-api 서버는 정기적으로 kubelet에서 상태 보고서를 가져와 노드 및 컨테이너의 상태를 모니터링한다.
kubelet은 선박의 컨테이너를 관리하는 선장에 가깝다. 그러나 작업자 노드에서 실행되는 응용프로그램은 서로 통신할 수 있어야 한다.
예를 들어, 노드 중 하나의 컨테이너에서 웹 서버가 실행되고 다른 컨테이너에서 데이터베이스 서버가 실행되고 있을 수 있다.
웹서버와 데이터베이스 서버가 다른 노드에 있다면, 웹 서버가 다른 노드의 데이터베이스 서버에 어떻게 도달할까?
작업자 노드 간의 통신은 Kube-proxy 서비스로 알려진 작업자 노드에서 실행되는 다른 구성 요소에 의해 활성화된다.
Kube-proxy 서비스는 Worker Node에서 실행 중인 컨테이너가 서로 연결될 수 있도록 필요한 규칙을 Worker Node에 적용한다.
요약하면 Master에는
1. Master Node와 Worker Node가 있다.
2. 클러스터에 대한 정보를 저장하는 ETCD 클러스터가 있다.
3. 노드에서 애플리케이션이나 컨테이너를 예약하는 Kube-scheduler가 있습니다
4. 노드 제어, 복제, 그리고 같은 다양한 기능을 처리하는 서로 다른 컨트롤러가 있다.
5. 클러스터 내의 모든 작업을 조정하는 Kube API 서버를 보유하고 있다.
6. Worker Node에서 Kube-apiserver의 지시를 듣고 컨테이너와 클러스터 내의 서비스 간 통신이 가능하게 하는 Kube-proxy를 관리하는 Kubelet을 가지고 있다.
'DevOps > 쿠버네티스(Kubernetes)' 카테고리의 다른 글
| [CKA] Kubernetes Kube-API Server (0) | 2022.09.03 |
|---|---|
| [CKA] Kubernetes에서의 ETCD의 역할 (0) | 2022.09.03 |
| 쿠버네티스 Node IP 설정 (0) | 2022.06.03 |
| 스펙을 지정해 오브젝트 생성하기(.yaml) (0) | 2022.06.03 |
| 쿠버네티스 레플리카셋(Replica Set) (0) | 2022.06.03 |
