목차
- Desired State
- Kubernetes Architecture
- Master
- Node
- API server
- etcd
- Master 구성
- Node 구성
- Pod이 생성되기 위해 거치는 순서
1. Desired State
Desire(요청)이 들어오면, 어떤 상태인지 체크를 하고, 그 요청과 현재 상태의 차이점을 발견하고, 그리고 요청을 해결한다.
이 프로세스가 루프를 돌면서 이루어진다.
이런 Desired state가 굉장히 많아질 수도 있다.
복제가 잘 됐는지, 로드밸런싱이 잘 되었는지 등의 Controller를 만들 수 있다.
2. Kubernetes Architecture
- Master : 중간에서 체크하고 실행되는 부분
- Node : 실제로 컨테이너가 실행되는 부분
- API server : 중간에서 교통정리 하는 부분
- etcd : 상태를 저장하고 조회하는 곳
3.1. Master - etcd
- 모든 상태와 데이터를 저장한다.
- 분산 시스템으로 구성하여 안전성을 높인다. (고가용성)
- 가볍고 빠르면서 정확하게 설계 (일관성)
- Key(directory)-Value 형태로 데이터 저장
- TTL(time to live), watch같은 부가 기능 제공
- 백업은 필수!
3.2. Master - API server
- 상태를 바꾸거나 조회
- etcd와 유일하게 통신하는 모듈
- REST API 형태로 제공
- 권한을 체크하여 적절한 권한이 없을 경우 요청을 차단
- 관리자 요청 뿐 아니라 다양한 내부 모듈과 통신
- 수평으로 확장되도록 디자인
3.3. Master - Scheduler
- 새로 생성된 Pod을 감지하고 실행할 노드를 선택
- 노드의 현재 상태와 Pod의 요구사항을 체크
- 노드에 라벨을 부여
- ex) a-zone, b-zone 또는 gpu-enabled, ...
3.4. Master - Controller
- 논리적으로 다양한 컨트롤러가 존재
- 복제 컨트롤러
- 노드 컨트롤러
- 엔드포인트 컨트롤러...
- 끊임 없이 상태를 체크하고 원하는 상태를 유지
- 복잡성을 낮추기 위해 하나의 프로세스로 실행
4.1. Node - Kublet
- 각 노드에서 실행한다. 모든 노드에 떠있다.
- Pod을 실행/중지하고 상태를 체크한다
- CRI (Container Runtime Interface)
- docker
- Containerd
- CRI-O
4.2. Node - Proxy
- 네트워크 프록시와 부하 분산 역할
- 성능상의 이유로 별도의 프록시 프로그램 대신 iptables 또는 IPVS를 사용(설정만 관리)
5. Pod이 생성되기 위해서 거쳐지는 순서
- User : "API server에 Pod을 추가해줘!"
- API server는 etcd에 그 정보를 넣는다. "Pod을 생성하라는 요청이 들어왔어!"
- Controller가 항시 대기함. "새로 생긴 요청이 있나~? 어! 새로운 Pod이 있네?!"
- Controller가 API server에 실제 Pod을 할당하는 요청을 한다.
- 그럼 API server는 그 요청을 받아서 etcd에 "Pod을 할당 요청해라" 라고 상태를 바꾼다.
- Scheduler는 계속 할당 요청이 들어온 Pod이 있는지 확인한다.
- 그러면 Scheduler는 어디에 띄울까 고민하다가 특정 노드에 저 Pod을 할당한다.
- 그럼 API server가 다시 받아서 이 Pod을 특정노드에 할당하는데 상태는 아직 실행되기 전 상태이다 라고 업데이트 한다.
- 그럼 Kublet이 "아직 실행이 안된 Pod이 있나?" 하면서 계속 체크
- 그 정보를 확인했으면 Kublet이 Pod을 생성한다.
- 그러면 그 정보를 다시 API server가 etcd에 업데이트 한다.
- 현재 etcd에는 Pod이 특정 노드에 할당이 되어 있고 실행 중이다! 라는 상태로 최종 업데이트 한다.
'🚦 Server > Kubernetes' 카테고리의 다른 글
| Kubernetes 란 (0) | 2022.03.10 |
|---|