[1] 쿠버네티스: 아키텍쳐에 관하여

https://www.youtube.com/watch?v=SNA1sSNlmy0 

 

 

 

Desired State

 

상태를 체크하고, 차이점을 발견하고, 조치를 취한다. 그리고 이걸 루프를 돌린다.

 

Scheduler

1번 서버는 컨테이너 1개가 띄워져 있고, 2번 서버는 비어있어.

그러니까 컨테이너 요청이 오면 2번 서버에 새로운 컨테이너를 넣자.

라고 계속 컨테이너 상태를 체크하는 사람이 Scheduler야.

 

Controller

컨테이너 하나가 떠있었는지 안떠있었는지, 네트워크, 노드 체크하는 것들을 다 Controller라구 함

그래서 Desired State가 굉장히 많아질 수가 있다.

 

Replication Controller : 복제가 잘 됐는지만 확인하는 컨트롤러

Endpoint Controller : 로드밸런싱이 잘 됐는지만 확인하는 컨트롤러

Namespace Controller : 네임 스페이스 잘 됐는지 확인하는 컨트롤러

Custom Controller : 맘대루. 머신러닝, CI/CD, 등등 커스텀 가능

 

중간에 체크하고 실행하는 것을 Master

실제 실행되는 것을 Node

중간에서 교통정리 : API Server

상태를 저장하고 조회하는 데이터베이스 : Etcd

 

Etcd : 모든 상태와 데이터를 저장

분산 시스템으로 구성해서 안정성을 높임

(보통 3대 정도 동시에 띄워둬서 한 대가 죽어도 잘 작동되도록 함)

가볍고 빠르면서 정확하게 설계

(2개를 요청했는데 3개를 띄우면 안됨.)

Key-Value 형태로 데이터 저장

TTL, watch 부가 기능 제공

백업 필수

 

API Server : 상태를 바꾸거나 조회

etcd와 유일하게 통신하는 모듈

(모든 조회나 요청은 API Server를 통해서 함)

REST API 형태로 제공

권한을 체크해서 적절한 권한이 없을 경우 요청 차단

권리자 요청 뿐 아니라 다양한 내부 모듈과 통신

수평으로 확장되도록 디자인 (모든 요청을 얘를 통해서 하니까)

 

Scheduler : 새로 생성된 Pod을 감지하고 실행할 노드를 선택

노드의 현재 상태와 Pod의 요구사항을 체크

-노드에 라벨을 부여

-a zone, b zone, gpu-enabled, ...

특정 라벨에 해당하는 pod에 배포하고 이럴 수 있음

 

Contoller : 논리적으로 다양한 컨트롤러가 존재

-복제 컨트롤러

-노드 컨트롤러

-앤드포인트 컨트롤러

 

끊임없이 상태를 체크하고 원하는 상태를 유지

복잡성을 낮추기 위해 하나의 프로세스로 실행

 

---

조회 흐름

1. 정보 조회 (Controller -> API Server)

2. 정보 조회 권한 체크 (API Server)

3. 정보 조회 (API Server -> etcd) #etcd : 엣시디 라고 발음

 

기본 흐름

etcd에는 원하는 상태가 저장이 된다. 그런데 이게 변경이 된다구 하자.

 

1. 원하는 상태 변경 (etcd -> API Server)

2. 원하는 상태가 변경 되었음을 알림 (API Server -> Controller)

3. 원하는 상태로 리소스 변경 (Controller)

4. 변경 사항 전달 (Controller -> API Server)

5. 정보 갱신 권한 체크 (API Server)

6. 정보 갱신 (API Server -> etcd)

 

결국 이런 구성도가 됨.

 

 

Kubelet이 pod을 실행/중지하고 상태를 체크함

CRI (Container Runtime interface)

 

Proxy 서버 : 네트워크 프록시 & 부하 분산 역할

별도의 프록시 프로그램 대신 커널 레벨에서 iptables 또는 IPVS를 사용 (설정만 관리)

전체 아키텍쳐는 다음과 같다.

 

하나의 Pod(팟)이 생성되기 위해서 어떤 과정을 거쳐야 하는지 알아보자

 

1. 관리자가 Pod을 추가해달라구 요청. (관리자 -> API Server)

2. Pod 요청 (API Server -> etcd)

3. 새 Pod 확인 (API Server <--- Controller) #Controller가 새로 생긴 Pod이 있나 계속 체크함

그런데 새로운 Pod 요청이 있는걸 확인 했으니까

4. Pod 할당 (API Server <--- Controller) #Pod을 할당하는 요청을 다시 API Server에 하는거야

5. Pod 할당 요청 (API Server -> etcd) #"Pod을 할당 요청해라"로 상태를 바꿈

6. 새 Pod 할당 확인 (API Server <---> Scheduler) #Scheduler가 새로운 Pod 할당 요청이 있는지 API Server에 계속 체크함

7. Pod 노드 할당 (API Server <--- Scheduler)

근데 진짜 Pod 할당 요청이 들어왔네? 어느 노드에 띄울까 고민 하다가, 특정 노드에 저 Pod을 할당함.

8. Pod 노드 할당 (API Server -> etcd)

그리고 그걸 API Server가 받아서 etcd에 넘겨주는데, "특정 노드에 저 Pod을 할당한다,

근데 아직 미실행 상태다." 로 업데이트함.

9. 미실행 Pod 확인 (API Server <---> Kubelet) #Kubelet이 내 노드에 할당된 Pod중 아직 실행 안된 Pod이 있는지 계속 체크함

10. Pod 생성 (API Server <---> Kubelet) #실행 안된 Pod이 있네. 그럼 그 정보를 갖구 와서 Pod을 하나 생성

11. Pod 생성 (API Server -> etcd) Pod을 만들었다는 정보를 API Server가 etcd에 업데이트

 

최종적으로는 etcd에는 Pod이 특정 노드에 할당이 되어있고 실행중이다 라는 상태로 업데이트가 되어있음

다 끝나도 Scheduler <---> API Server

Controller <---> API Server

Kubelet <---> API Server는 계속 체크함

 

근데 더이상 변화하는게 없기 때문에, 체크만 하고 넘어가고 업데이트 하는 과정은 없는거야.

 

Addons

CNI (네트워크)

DNS (도메인, 서비스 디스커버리)

대시보드 (시각화)