쿠버네티스 구성 요소 확인(+EKS,AKS,GKE 관리형 쿠버네티스)
구역을 나누는 네임스페이스
이제까지 실습했던 거는 default라는 네임스페이스 안에 있었음.
쿠버네티스를 이루는 것들은 kube system이라는 네임스페이스 안에 있음.
즉, 네임스페이스는 서로의 구역이 나누어져있는 단위라고 할 수 있다.
네이티브 쿠버네티스 구성 요소 확인
- kube-system 요소 확인
AWS - EKS(Elastic Kubernetes Service)
EKS에서도 kube-system이 있는 것을 확인함
Azure - AKS(Azure Kubernetes Service)
AKS에서도 kube-system이 있는 것을 확인함
GCP - GKE(Google Kubernetes Engine)
GKE에서도 kube-system이 있는 것을 확인함
쿠버네티스의 기본 철학
쿠버네티스의 기본 철학
- 마이크로서비스 아키텍처 형태로 구성되어 있음 - 하는 일들이 개별적으로 나누어져 있음
파드가 배포되면?
- 사용자들이 kubectl create pod 명령을 내림
- 파드 생성 요청이 API 서버 & etcd로 넘어감
- API 서버가 파드의 생성을 감시한다.
- 컨트롤러 매니저는 파드를 생성한다.
- 새로운 파드가 워커 노드에 들어갔는지 API 서버에서 감시한다.
- 스케줄러가 새로운 파드를 워커 노드에 넣도록 스케쥴한다.
- API 서버는 새로운 파드가 노드에 잘 소속되어 있는지 감시한다.
- kubelet은 파드의 동작을 관리한다.
- 컨테이너 런타임이 컨테이너를 생성한다.
- kubelet이 API 서버에 파드의 상태 정보를 전달한다.
선언적인 시스템
추구하는 상태(API 서버에 선언한 상태)와 현재 상태를 맞추려고 하는 것이 쿠버네티스의 가장 기본적인 알고리즘이다.
그래서 계속 감시를 하고, 차이를 발견하면 상태를 변경하는 루틴이다.
API 서버와 ETCD
API 서버는 가지고 있는 현재 상태, 그리고 추구하는 값(클러스터의 업데이트된 정보)들을 가지고 있는데 이 값들을 etcd에 기록한다. 즉, 구성 정보를 백업한다.
ETCD는 매번 API 서버에 업데이트가 되었음을 알려준다.
API 서버는 굉장히 중요한 존재이고, 모든 것의 중심이다.
가보자고