[k8s] ETCD, kube-apiserver, Kube Controller Manager, Kube Scheduler, Kubelet, Kube-proxy

Jisun-Rea·2021년 4월 2일
0
post-thumbnail

ETCD

distributed reliable key-value store

kubectl get 명령으로 보는 모든 정보가 ETCD server로부터 온 것이다.
cluster에 만든 모든 변화들이 이곳에 기록된다.

cluster을 어떻게 배포하느냐에 따라서 ETCD도 다르게 배포된다.
1. scratch
2. kubeadm (CKA 환경)

kubeadm으로 cluster을 구성하게 되면,
ETCD server은 kube-system namespace에 POD 형태로 배포된다.

kube-apiserver

primary management component in kubernetes

kubectl 명령어를 치면, kubectl utility가 kube-apiserver로 전달된다. 그러면, kube-apiserver은 첫번째로 요청을 인증하고 검증한다. 그리고 ETCD cluster로부터 데이터를 가져와서 돌려준다.

Pod를 하나 만드는 과정을 살펴보면 명확하다.
1. user을 인증한다.
2. request 검증한다.
3. apiserver이 pod 객체를 만들고(아직 node에 할당하기 전) 이 사실을ETCD server에 업데이트하고 user에게 pod가 생성되었음을 알린다.
4. scheduler은 apiserver을 지속적으로 모니터링하고있다가 새로운 pod가 생긴것(node에는 할당되지 않은)을 알아차린다.
5. scheduler이 pod를 위치시킬 적당한 node를 확인하고 kube-apiserver에게 알리고 kube-apiserver은 이 사실을 ETCD cluster에 업데이트한다.
6. 그리곤 kube-apiserver은 해당 worker node에 있는 kubelet에 해당 정보를 전달하고
7. 그러면 kubelet이 해당 node에 pod를 생성하고 container runtime engine에게 application image를 배포하도록 시킨다.
8. 그리고 다시 kubelet은 status를 apiserver에게 전달하고 apiserver은 정보를 다시 ETCD cluster에 업데이트한다.

Kube Controller Manager

manages various controllers in kubernetes

Controller

process that continuously monitors the state of various components within the system
and works towards bringing the whole system to the desired functioning state

예를들면, node controller은 node의 상태를 검사하고 application이 running할 수 있게 만들어야하는 의무를 가지고 있다.
단, 이러한 action은 kube-apiserver을 통해 수행한다.

kubernetes에서 나오는 모든 개념, namespaces, replicasets, deployment 모두는 controller으로부터 나온다.

이런 여러 controller을 하나의 패키지로 담은 것이 kube controller manager인 셈이다.

Kube Scheduler

deciding which pod goes on which node
** 실제로 pod를 node에 위치시키는건 kubelet

Kubelet

register node, create pods, monitor node&pods

특이점은 kubeadm tool을 사용하면 자동적으로 설치되었던 다른 component와는 달리, kubelet은 자동으로 배포되지 않는다.
항상 직접 worker node에 kubelet을 설치해야 한다.

Kube-proxy

process that runs on each node in the kubernetes cluster to look for new services and every time a new service is created, it creates the appropriate rules on each node to forward traffic to those services to the backend pods

예를들면, web pod와 db pod가 있다고 할 때, web pod는 db pod에 접근하기 위해 db pod의 ip에 직접 접근하는 것이 아니라(ip가 변할 수 있는 등의 이유 때문), db service를 통해 db pod(backend pod)에 접근한다.
여기서 kube-proxy는 iptables rule을 통해 각 node에 iptable을 만들어서 트래픽을 보낼 수 있게 만든다.

profile
호기심 많고 걱정도 많은 사람👻 @DevOps @Cloud

0개의 댓글