> For the complete documentation index, see [llms.txt](https://hidaehyunlee.gitbook.io/fork-my-brain/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hidaehyunlee.gitbook.io/fork-my-brain/kubernetes/1..md).

# \[쿠버네티스 아키텍처] 1. 구성 및 설계

현재 상태와 Desired State(원하는 상태)를 계속 체크하고(ex.컨테이너 하나가 떠있어야 되는데 잘 떠있는지), 만약 문제가 있다면 조치를 한다. 이 단순한 작업을 잘 반복하면 서버 관리에 문제가 없을 것이다.

> 44BIT님의 [\[초보를 위한 쿠버네티스 안내서\] 쿠버네티스 아키텍처](https://youtu.be/SNA1sSNlmy0) 강의를 듣고 정리한 내용입니다.

## 1. 쿠버네티스(kubernetes)?

쿠버네티스가 무엇인지, 그냥 컨테이너를 개발하고 배포하는 것과 무엇이 다른지는 공식 문서 [쿠버네티스란 무엇인가?](https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/)에 잘 설명되어 있다. 본격적으로 공부하기 전에 어떤 느낌인지 이해한 바로는, 쿠버네티스는 기존 분산 시스템을 좀 더 탄력적으로 실행할 수 있도록 도와주고(유연성), 제공되는 프레임워크, 배포 패턴 등에서 서비스의 규모에 맞게 실행할 수 있도록 개발자의 선택지가 더 다양한 것 같다(선택권).

즉, 쿠버네티스는 사용자의 **선택권**과 **유연성**을 지켜주면서 **확장**과 **이식**이 용이한 컨테이너 관리 오픈소스 플랫폼이다.

## 2. 관련 용어 정리

* 하드웨어 유닛
  * `노드(node)` : 쿠버네티스에서 최소 단위의 컴퓨팅 하드웨어
  * `클러스터(cluster)` : 효율적인 리소스 공유와 균형 배분을 위해 여러 노드를 묶은 그룹
* 소프트웨어 유닛
  * `컨테이너(container)` : 하나 이상의 프로세스 모음. 실행에 필요한 파일도 모두 들어있어 머신 간 이식이 가능.
  * `포드(pod)` :  하나 이상의 컨테이너 모음. 리소스 공유의 장점을 극대화하기 위해 패키지로 묶여 있음.

**✅ 쿠버네티스에서 포드를 사용하는 이유**

> 포드와 클러스터의 관계 때문에 쿠버네티스는 직접 컨테이너를 실행하지 않는다. 그 대신 포드를 실행하면서 포드 속의 각 컨테이너가 동일한 리소스 및 로컬 네트워크를 공유하게 한다. 이렇게 컨테이너를 포드로 구성하는 것이 쿠버네티스의 유명한 기능, 바로 **복제(Replication)**의 토대가 된다.
>
> 컨테이너를 모아 포드를 만들면, 어떤 포드 하나가 과부하 상태가 되었을 때 쿠버네티스는 자동으로 이를 복제한 다음 클러스터에 배포할 수 있는 것이다.

출처 : [쿠버네티스 포드란?](https://www.redhat.com/ko/topics/containers/what-is-kubernetes-pod)

## 3. Desired State

쿠버네티스 구조를 공부하기 전, 먼저 **Desired State** 개념을 이해하면 좋다. 서버 관리에서 중요한 개념이자 쿠버네티스의 근간을 아우르는 시스템이다. **현재 상태**와 **Desired State(원하는 상태)**를 계속 체크하고(컨테이너 하나가 떠있어야 되는데 잘 떠있는지 등), 만약 문제가 있다면 조치를 하고. 이 단순한 작업을 잘 반복하면 서버 관리에 문제가 없을 것이다.

![](https://github.com/hidaehyunlee/Fork-my-brain/tree/4f7d19f4487fe8d450e22a9b6451bbed865ce125/images/37580034-108043101-006bf080-7084-11eb-80c6-bc8b6b6ad5a6.png)

## 4. 구성 및 설계

![](https://github.com/hidaehyunlee/Fork-my-brain/tree/4f7d19f4487fe8d450e22a9b6451bbed865ce125/images/37580034-108056956-4f6e5180-7095-11eb-9553-bea739757a79.png)

쿠버네티스의 구조는 위 그림과 같다. 강의 제일 끝부분에 나오는데, 미리 캡쳐를 해봤다. 크게 보면 **Master**와 **Node**라는 구조 속에서 서버 관리 흐름이 진행되는 것이다. 위 그림처럼 처음 보는 용어가 가득한 결론은 잠시 다시 잊고, 각각의 개념을 강의 순서대로 익혀보자.

### 4.1. 마스터(master)

#### 1) Controller

서버 관리에서 state(상태)의 종류는 다양할 수 있다. 쿠버네티스에서는 클러스터 상태의 각 특정한 부분을 관리하는 많은 **컨트롤러** 를 사용한다. 쿠버네티스 디자인 원리의 핵심이기도 한데, 상태를 제어할 때 루프가 하나로 연결되어 있는 모놀리식(monolithic) 집합보다 간단하게 컨트롤러를 여러 개 사용하는게 편리하기 때문이다.

컨트롤러 개념 덕분에 위에서 배운 **Desired State 루프**가 아래 그림처럼 굉장히 많아질 수 있다.

![](https://github.com/hidaehyunlee/Fork-my-brain/tree/4f7d19f4487fe8d450e22a9b6451bbed865ce125/images/37580034-108045429-cb14d200-7086-11eb-9ddf-7f70905092b2.png)

* 기능별로 쪼개고 추상화했기 때문에 각각의 기능을 관리하기가 편해지는 것이고, 이를 통해 관리 자동화를 실현할 수 있게 된다. 

#### 2) Scheduler

CPU 또는 메모리와 같은 포드(컨테이너의의 집합이자 쿠버네티스 애플리케이션의 최소 단위)의 리소스 요구 사항과 함께 클러스터의 상태를 고려한다. 그런 다음 **포드를 적절한 컴퓨팅 노드에 예약**한다. 쉽게 말해서 여유있는 서버를 찾아 컨테이너를 어디에 띄울지 결정하는 것.

#### 3) etcd

상태를 저장하고 조회하는 DB인 **엣지디(etcd)**가 있다. etcd는 모든 상태와 데이터를 확실하게 저장해야한다. 따라서 백업은 필수이며, 아래 같은 특징을 가지고 있다.

* 고가용성 : 분산 시스템으로 구성하여(보통 엣지디를 3대정도 띄운다고 한다) 안정성을 높임
* 일관성 : 가볍고 빠르면서 정확하게 설계
* key-value 형태로 데이터 저장
* TTL(time to live), watch 등 부가기능 제공

#### 4) API server

마스터의 조율자 역할을 하는 **API Server** 이다. 데이터와 상태를 조회하거나 변경하는 요청은 모두 API 서버를 통해(거쳐서) 이뤄진다. 아래와 같은 특징을 가지고 있다.

* 상태를 바꾸거나 조회
* ectd와 유일하게 통신하는 모듈
* 권한 체크 (권한이 없으면 요청 거부)
* REST API 

### 4.2. 노드(node)

노드에는 크게 두 가지 컴포넌트가 떠있는데, **프록시(Proxy)**와 **큐블릿(Kubelet)** 이다. 이 두 컴포넌트도 마스터와 통신을 할 때 API Server를 통해서만 요청와 응답를 얻을 수 있다.

#### 1) Proxy

네트워크 프록시 역할(부하 분산)을 하긴 하지만 실제로 요청/응답을 받는 프록시가 떠있는 개념은 아니고, 내외부 통신 설정만 관리하는 역할을 한다.

iptables 또는 IPVS를 사용한다.

#### 2) Kubelet

각 노드에서 실행되며, pod를 실행하거나 중지하고 상태를 체크한다. 도커 등 아니라 다양한 CRI(Container Runtime Interface), 즉 컨테이너를 pod로 감싸 확실하게 관리하는 임무를 가지고 있는 것이다.