16-20. kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, kube-proxy

kube-apiserver

API 요청을 authenticate하고, 검증하고, etcd 클러스터에서 데이터를 뽑아서 전달한다

• etcd와 상호작용하는 유일한 컴포넌트시스템 컴포넌트들의 상태를 주기적으로 확인하고, 문제가 있을 경우 해결을 시도한다
  다양한 컴포넌트를 체크하는 Controller들이 kube-controller-manager에 올인원으로 들어가 있다
• kube-controller-manager
• 예 - Node Controller의 경우:
  • 5초에 한 번씩 kube-apiserver를 통해 워커노드의 kubelet을 호출, 상황을 확인함
    • 노드에서 heartbeat가 오지 않는 경우 40초 후에 unreachable 처리
    • 5분 후에도 복구되지 않은 경우 해당 노드에 할당된 Pod을 제거
• 예 - Replication Controller의 경우:
  • Replica 선언에 맞춰 필요한 수의 Pod이 사용 가능한지 체크
    • ReplicaSet 하에 있는 Pod이 죽으면, 새로운 Pod을 생성(하도록 kube-apiserver에 요청)

kube-scheduler

kube-scheduler는 kube-apiserver로부터 노드가 할당되지 않은 Pod를 확인한 뒤, 스케줄링 알고리즘에 따라 해당 Pod을 노드에 배치하도록 kubelet에 명령을 내린다 (kube-apiserver를 통해)

• 실제로 Pod을 디플로이하는 것은 각 노드의 kubelet임
• 모든 Pod에는 원래 spec 아래에 nodeName 필드가 있다
• 스케줄러는 Pod 전체를 순회하면서 이 프로퍼티가 설정되지 않은 Pod을 찾는다
  • 이것이 스케줄링될 후보가 된다
• 그 다음 스케줄링 알고리즘에 따라 그 Pod을 어느 노드에 놓을지를 찾는다
• 괜찮은 노드를 찾았다면, Live Configuration의 nodeName: 필드를 찾은 노드 이름으로 채운다

만약 스케줄러가 없다면? 영원히 Pending 상태에 머물것

• 하지만 Pod을 수동으로 node에 할당하는 것이 가능하다
• 예를 들어, 그냥 yaml 파일에 nodeName을 수동으로 넣어줄 수 있다

하지만, 일단 Pod이 생성되었다면 그 다음에는 수동으로 nodeName을 건드릴 수가 없다

• 대안: Pod의 Binding Object을 생성한 뒤에, Pod의 Binding API에 POST요청을 보낸다 
• apiVersion: v1 kind: Binding metadata: name: nginx target: apiVersion: v1 kind: Node name: node02

curl --header "Content-Type:application/json" --request POST data '{"apiVersion":"v1", "kind": "binding", ...}' http://$SERVER/api/v1/namespaces/default/pods/$PODNAME/binding/

 

Kubelet

Worker node의 대장 역할

• 클러스터에 해당 노드를 register
• Heartbeat 요청 시 해당 노드 내부의 정보를 파악해서 돌려줌
• Pod가 할당되면 컨테이너 런타임(CRI-O, ContainerD, Docker)에 요청하여 이미지를 pull하고 컨테이너를 생성, 구동
• Pod의 상태를 확인하고 kube-apiserver에 보고

kubeadm으로 클러스터를 구성한 경우에는, kubelet은 설치되지 않음

• 따로 설치해줘야 함