[kubernetes] 쿠버네티스 아키텍처 (1)

https://youtu.be/SNA1sSNlmy0?list=PLIUCBpK1dpsNf1m-2kiosmfn2nXfljQgb 

 

 

---

 

생성 및 모니터링

 

Desired State 

 

상태체크(Observe) -> 차이점 발견(Diff) -> 조치(Act)

현재상태와 원하는 상태가 같은지 체크 후 -> 현재 상태와 원하는 상태가 다를 경우 -> 현재 상태를 원하는 상태로 바꿈

 

이 흐름의 Loop

 

 

 

 

 

스케쥴러와 컨트롤러들을 추가

 

 

 

 

 

컨트롤러들

 

 

 

 

Master 의 설계

 

etcd : 상태를 저장하고 조회한다, 모든 상태와 데이터를 저장한다. 데이터를 관리함

모든 상태와 데이터를 저장한다

분산 시스템으로 구성하여 안전성을 높인다(고가용성)

가볍고 빠르고 정확하게 설계한다 (일관성)

Key(directory)-Value 형태로 데이터를 저장한다

TTL(time to live), watch같은 부가 기능제공

백업은 필수<<<<

 

 

API server

상태를 바꾸거나 조회

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

REST API 형태로 제공

권한을 체크하여 적절한 권한이 없을 경우 요청차단

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

수평으로 확장할 수 있도록 디자인됨

 

 

Scheduler

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

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

( 노드에 라벨 부여 : 아마존의 경우 a-zone,b-zone 또는 gpu-enabled..)

 

 

Master -> Controller

논리적으로 다양한 컨트롤러가 존재(복제, 노드, 엔드포인트 등등 여러개의 논리 컨트롤러)

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

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

 

 

 

 

Master 의 조회흐름

 

1. Controller -> API Server 정보 조회

2. APIServer 정보 조회 및 권한 체크

3. APIServer -> etcd 정보조회

4. etcd -> APIServer 원하는 상태로 변경 후 알림

5. APIServer -> Controller 상태 변경 알림

6. Controller 변경 대로 리소스 변경

7. Controller -> API Server 변경 된 사항 전달

8. APIServer 변경 사항에 대한 정보 갱신 권한 체크

9. APIServer -> etcd 정보갱신 요청

 

 

API 서버 통신

 

 

 

 

 

Node 의 설계

 

 

 

kublet : 컨테이너의 관리가 중점

각 노드에서 실행

Pod을 실행/중지하고 상태를 체크

CRI(Container Runtime Interface) -> docker, Containerd, CRI-O 등 << 컨테이너의 개념들 이를 pod으로 감싸서 관리함

 

 

proxy : 내/외부 통신 설정

네트워크 프록시와 부하 분산 역할

성능상의 이유로 별도의 프록시 프로그램 대신 iptables, IPVS를 사용하여 설정만 관리한다

 

 

 

 

 

 

부가적이지만 필수 컨퍼런트

Addons

CNI (네트워크)

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

대시보드 (시각화)