

쿠버네티스는 큰 단위로 따지면 마스터노드(Master Node)와 워커노드(Worker Node)두가지 영역으로 나눌 수 있다.

kubectl 이라는 클러스터에 명령을 내리는 명령어를 통하여 통신을 한다.
주로 워커노드에서 실행되는 컨테이너를 관리하는 역할을 한다. 즉 축구에서 선수가 아닌 감독의 역할을 한다고 보면 이해하기 쉽다.
쿠버네티스 클러스터의 중심역할을 하는 통로이다. 주로 상태 값을 저장하는 etcd와 통신하지만, 그 밖의 요소들 또한 API 서버를 중심에 두고 통신한다. 즉 쿠버네티스의 모든 요청들은 API Server를 통해서 수행한다고 보면 된다.
구성 요소들의 상태 값이 모두 저장되는 곳이다. kubernetes의 백업 저장소로 사용되는 일관되고 가용성이 높은 키 값 저장소이다. 또한 etcd를 복제해 여러 곳에 저장해 두면 하나의 etcd에서 장애가 나도 시스템의 가용성을 확보할 수 있다.
쿠버네티스의 오브젝트 상태를 관리한다. 예를 들어 워커 노드에서 통신이 되지 않는 경우, 상태 체크와 복구는 컨트롤러 매니저에 속한 노드 컨트롤러에서 이루어진다. 컨트롤러에는 다양한 유형이 있다.
- 노드 컨트롤: 노드가 다운되었을때 통지와 조치
- 네임스페이스 컨트롤: 새 네임스페이스 생성 시 기본 계정(Service Account)과 인증 토큰(Secret) 생성
- 서비스 컨트롤: 새 Service 생성 시 Pod의 주소를 갖고 있는 End Point 리소스 생성
- 파드 컨트롤: 지정된 파드 수가 항상 유지 되도록 통제
노드의 상태와 자원, 레이블, 요구 조건 등을 고려해 파드를 어떤 워커 노드에 생성할 것인지를 결정하고 할당한다. 파드를 조건에 맞는 워커 노드에 지정하고, 파드가 워커 노드에 할당되는 일정을 관리하는 역할을 한다.

워커 노드는 마스터 노드에 의해 관리되며 실제로 container를 실행하는 기능을 담당한다. 모든 클러스터 노드에는 kubelet과 kube-proxy 서비스가 실행된다.축구로 치면 감독과 선수중 선수라고 보면된다.
파드의 구성 내용을 받아서 컨테이너 런타임으로 전달하고, 파드 안의 컨테이너 들이 정상적으로 작동하는지 모니터링한다. 즉 파드에서 컨테이너가 확실하게 동작하도록 관리하는 것이다.
노드에 들어오는 네트워크 트래픽을 적절한 컨테이너로 라우팅하고, 로드밸런싱등 노드로 들오고 나가는 네트워크 트래픽을 프록시하고, 마스터노드와 워커노드 사이의 네트워크 통신을 관리한다.
파드를 이루는 컨테이너의 실행을 담당합니다. 파드 안에서 다양한 종류의 컨테이너가 문제 없이 작동하게 만드는 표준 인터페이스다.

kubectl을 통해 API Server에 파드 생성을 요청한다.
API 서버에 전달된 내용이 있으면 API 서버는 etcd에 전달된 내용을 모두 기록해 클러스터의 상태 값을 최신으로 유지한다. 따라서 각 요소가 상태를 업데이트 할때마다 모두 API 서버를 통해 etcd에 기록된다.
API 서버에 파드 생성이 요청된 것을 컨트롤러 매니저가 인지하면 컨트롤러 매니저는 파드를 생성하고, 이 상태를 API 서버에 전달한다. 아직 어떤 워커 노드에 파드를 적용할지 결정되지 않는 상태로 파드만 생성한다,
스케줄러는 생성된 파드를 어떤 워커 노드에 적용할지 조건을 고려해 결정하고 해당 워커 노드에 파드를 띄우도록 요청한다.
API 서버에 전달된 정보대로 지정한 워커 노드에 파드가 속해 있는지 스케줄러가 kubelet으로 확인 한다.
kubelet에서 컨테이너 런타임으로 파드 생성 요청한다.
파드가 생성된다.
파드가 사용 가능한 상태가 된다.
참고자료:
https://m.yes24.com/Goods/Detail/102099414
https://kubernetes.io/docs/concepts/overview/components/
https://no-easy-dev.tistory.com/entry/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90