Kubernetes Architecture

 

CKA 준비에 앞서 Kubernetes의 기본적인 architecture에 대해 알아보고자 한다.

 

 

위의 work flow에서 크게 3가지로 구분을 하면

1. 사용자가 kubernetes에 명령을 전달하기 위해 사용하는 Console
2. console을 통해 들어온 명령을 해석하고 각 node에 전달하는 Master Server
3. Master Server에서 송신한 명령을 수신하여 알맞게 처리하는 Worker node

각각의 역할에 대해 자세히 알아보고자 한다.

---

1. Console

commend line을 통해 kubernetes를 사용하고자 하는 사용자가 명령을 전달해 줄 수 있도록 도와주는 장비를 일컫는다.

---

2. Master Server

Api Server

kubernetes에 들어온 명령들을 총괄 컨트롤 하는 Component이다.

 

Controller

쉽게 설명하자면 사용자가 설정한 환경을 유지해 주는 Component이다.

 

ex)

사용자가 console을 통해 nginx pod 2대를 Running 시켜라 라는 명령을 전달하면 Controller는 반드시 2개의 pod를 보장할 수 있도록 work node들을 지켜보고 있는다.

또한 nginx pod 1개가 Shutdown될 경우 etcd와 schduler, kubelet를 통해 다시 1개의 nginx pod를 띄우는 방식으로 무조건 2개의 pod가 띄워져 있는 것을 보장할 수 있도록 한다.

 

schduler

etcd에 저장되어 있는 각 worker node의 정보를 토대로 어느 worker node에 명령을 받은 pod를 몇 대 띄울 것인지를 판단하여 API Server에 전달하는 역할을 수행한다.

 

node가 배정되지 않은 새로 생성된 pod를 감지하고 실행할 node를 선택하는 역할을 수행한다.

 

etcd

각 worker node들의 kubelet에 내장되어 있는 C-Advisor를 통해 <KEY, VALUE> 형태로 worker node의 리소스 값이나 컨테이너 이미지 정보 등과 같은 정보들이 저장되는 저장소이다.

 

coreDNS

service name과 Cluster IP mapping 정보를 저장한다.

 

- Cluster IP(End Point) : 하나의 Cluster에 속해있는 모든 node들의 IP 정보가 들어간다.

 

NIC

Host와 network간 데이터를 송수신할 수 있도록 도와주는 인터페이스

 

CNI

컨테이너끼리 통신할 수 있도록 지원해주는 컨테이너 네트워크 인터페이스

 

---

3. Worker node

kubelet

kubernetes를 설치하게 되면 자동으로 kubelet deamon이 start 하게 된다.

master에서 명령 받은 대로 pod에서 컨테이너가 확실하게 동작하도록 관리를 수행한다.

 

c-Advisor : docker 엔진 기반 하에 현재 이 시스템이 가지고 있는 하드웨어 리소스의 사용률, 컨테이너 이미지들이 얼마나 다운로드가 되었는지 만약 동작 중인 컨테이너가 있다면 그 컨테이너들은 지금 어떻게 동작 중인지 등 이러한 정보들을 전부 수집하는 모니터링 툴

 

kube-proxy

각 node에서 실행되는 네트워크 proxy로 node의 네트워크 규칙을 유지 관리 한다.

해당 규칙을 통해 내부 network 세션이나 cluster 바깥에서 pod로 네트워크 통신을 할 수 있도록 해준다.

 

Container Engine

외부 혹은 내부 레지스트리에서 명령에 해당하는 컨테이너 엔진을 찾고 pull download를 받은 역할을 수행한다.

---

 

명령이 수행되는 과정

ex) nginx pod 2개 실행시켜줘~!

 

1. 사용자가 console 장비에서 kubelet 명령어를 통해 명령을 Master Server로 전달
2. 6443 port를 통해 API Server는 해당 명령을 수신하게 되고 명령을 요청한 user에 대한 권한 확인을 진행
3. ETCD에 저장되어 있는 worker node 1, 2의 정보를 꺼내와서 해당 정보들을 토대로 Schduler가 nginx pod 2대를 어느 node에 배치하면 좋을지 판단을 진행
4. Schduler는 판단 결과 값을 API Server에 전달해 주고 API Server는 해당 정보를 ETCD에 저장
5. API Server는 명령을 각 worker node의 kubelet에 전달
6. 각 worker node의 kubelet은 Container Engine에 해당 명령을 전달
7. Container Engine는 nginx 컨테이너를 외부 혹은 내부 레지스트리에서 Pull Download
8. nginx 컨테이너 pod 실행
9. Controller는 nginx pod 2대가 Running 상태인지 지속적으로 watch