https://www.youtube.com/watch?v=Iue9TC13vPQ&list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&index=7
- 쿠버네티스 동작 과정(원리)
- 컴포넌트 종류와 구성
- 애드온
k8s 컨테이너 동작 flow
(선생님의 초상권을 보호해 드렸습니다.🤸)
- 개발자/운영자가 필요한 여러 컨테이너를 빌드한다.
- 도커 명령으로 도커 허브에 push해서 저장한다.
- k8s 명령을 통해 도커 허브에 있는 이미지를 실행한다.
- 컨트롤 플레인이 요청을 받는다
- 실제 컨테이너가 돌아가는 노드들을 살펴보고 스케쥴러를 통해 어떤 노드에 실행하면 좋을지 확인하고 전달받은 노드의 kubelet에 요청을 전달한다.
- 받은 요청을 도커 명령으로 바꿔서 도커에게 실제 컨테이너 실행 요청을 한다.
- 도커는 받은 요청대로 실제 도커 허브에 이미지가 존재하는지 체크하고 실행시킨다.
k8s는 이렇게 실행된 컨테이너를 pod로 관리한다.
kubectl으로 진행된 요청은 컨트롤 플레인의 API가 받아 처리한다.
요청에 대한 문법, 권한이 합당하면 실행한다.
etcd - 키:값 형태로 저장된다. 워커 노드에 대한 상태 정보들이 저장된다. 컨테이너 동작 상태 다운로드 상태.
어떻게 저장하는가? kubelet이라는 컴포넌트가 있는데 이는 데몬이다. cAdviser라는 컨테이너 모니터링 툴이 있다. 컨테이너 기반의 상태정보를 모니터링하고 하드웨어 정보를 모니터링한다. 이정보를 마스터에게 전달하여 etcd에 저장시킨다.
디플로이먼트 생성 요청이 들어가면, API는 etcd의 상태 정보를 체크하고 스케쥴러에게 물어본다. nginx 컨테이너 실행 할건데 어느 노드가 가장 합당하겠는지 확인하고 응답을 해준다.
그정보를 가지고 API는 node2의 kubelet에게 nginx컨테이너 실행 요청을 전달한다.
kubelet은 요청을 받아 docker에게 docker 명령어로 요청을 또 전달한다. 이어서 docker는 docker hub를 통해 실행하게 된다.
이때 controller가 활약하는데 1개를 실행중이기 때문에 그 개수를 보장해준다. 만약 node2가 다운되면, controller가 모니터링하다가 nginx 컨테이너가 실행되고 있지 않음을 확인하고 API에게 nginx 컨테이너 1개 실행 요청을 하게 된다. 그럼 역시 API는 스케쥴러를 통해 새 nginx 컨테이너를 실행하게 된다.
메인컴포넌트 - 마스터 컴포넌트의 API, controller, scheduler, etcd
addon PGM - coreDNS, CNI
kubeproxy는 실제 k8s의 네트워크를 담당해 준다.
컨테이너 런타임으로는 docker를 사용한다. docker말고도 다른 tool이 있기는 하다.
