Components
먼저 Master Node에는 etcd, kube-scheduler, kube-API서버가 있는데 일반적인 설치를 했을 때 이 Component들은 Pod의 형태를 띄어져서 구동중인 상태다.
/etc/kubernetes/manifests 라는 폴더를 보면 이 Component 생성에 대한 yaml 파일들이 있다. 쿠버네티스가 구동시에 이 파일들을 읽어서 Pod들을 static으로 띄운다.
Worker Node에는 쿠버네티스를 설치할 때 같이 설치하는 kubelet과 도커가 구동중인 상태이다.
사용자가 kubectl 명령어로 Pod를 생성요청을 날렸다고 가정한다면 먼저 Pod 생성 명령은 kube API 서버로 전달이 되고 kube API 서버는 etcd에 있는 이 Pod에 대한 입력 정보를 저장해둔다. etcd는 쿠버네티스에서 여러 데이터들을 저장하는 DB역할을 한다.
kube 스케줄러는 수시로 각각의 Node 자원들을 체크하고 있다. 그래서 만약에 현재 상태가 Node2에는 Container가 돌아가고 있어서 자원이 사용되고 있다는 것을 알고 있고 watch라는 기능으로 kube API 서버를 통해 etcd에 Pod 생성 요청이 들어온 것이 있는지 없는지 감시하고 있다.
그래서 Pod 생성 요청이 들어온 것을 발견하면 Node 자원 상태를 확인하고 이 Pod가 어느 Node로 갈지 판단하여 Pod에 Node 정보를 붙여준다.
각각의 Worker Node에 있는 kubelet을 보면 kube API 서버에 watch 기능이 붙어 있고 Pod에 자신의 Node 정보가 붙어있는지 체크하고 있다가 자신이 붙어있는 Pod를 발견하면 이 정보를 가져와서 Pod를 만든다.
Worker Node의 kubelet이 하는 일
kubelet은 Pod를 만들기 위해 2가지 일을 하는데 먼저 도커에게 Container를 만들라고 요청을 하면 도커에서 Container를 만들어준다.
manifests 폴더에 kube-proxy.yaml 이 있는데 이 yaml파일을 DaemonSet이라서 모든 Node에 kube-proxy가 생성되어 있다.
이 상태에서 kubelet은 kube-proxy에게 Network 생성 요청을 하고 kube-proxy가 새새로 생긴 Container에 통신이 되도록 도와준다.
다른 Component들과 마찬가지로 manifests 폴더에 kube-controller-manager.yaml 파일이 있어서 Controller Manager Pod가 띄워져 있고 이 안에 Controller에 대한 기능들이 각각 쓰레드 형태로 돌아가고 있다.
사용자가 Deployment를 생성하는 과정
이 상태에서 사용자가 kubectl 명령어로 Deployment에 replicas=2옵션을 줘서 생성했다고 가정하면 이 명령이 Kube API 서버로 연결이 되고 etcd에 Deployment에 대한 입력 정보를 저장한다.
한편 Controller Manager에 Deployment 쓰레드는 Kube API 서버에게 Deployment 관련 정보가 들어오면 알려달라고 Watch를 걸어 놓은 상태인데 Deployment가 들어왔기 때문에 Deployment 쓰레드가 이 내용을 읽고 ReplicaSet을 만들어 달라고 요청한다.
그러면 ReplicaSet이 ReplicaSet Object가 있는 Watch를 걸어 놓고 있는 상태라 이걸 또 감지를 하고 ReplicaSet안에 replicas가 몇개인지 체크한다음에 그 수 만큼 Pod를 만들라고 요청한다.
이 상황에서 kube 스케줄러는 Node가 할당되지 않은 Pod를 감지하고 현재 Node들의 자원을 고려해서 Pod들한테 스케줄링 될 Node를 할당해주고 각 Node에 있는 kubelet은 자신에게 할당된 Pod를 감지하고 도커에게 Container를 만들어달라고 요청한다.
그럼 도커가 Container들을 만들어주고 또 kubelet이 kube-proxy를 통해서 Container와의 통신을 연결해준다.
