K8S 아키텍처 정리 (Kube-scheduler, Kubelet, Kube-proxy)

1. Kube-Scheduler

 

 스케줄러는 어떤 포드가 어떤 노드로 갈지를 결정하는 등 스케줄을 짠다. 

 

하지만 스케줄을 짤 뿐, 실제로 노드 위에 포드를 놓지는 않는다. 

(노드 위에 포드를 할당하는 것은 Kubelet의 역할)

 

스케줄러는 오직 포드를 어떤 노드로 옮길 것인지만 결정한다.  

 

그렇다면 스케줄러는 어떻게 적당한 노드를 선택하고 포드를 옮길까?

 

스케줄러는 먼저 포드들을 관찰하면서 포드가 할당되기 좋은 최적의 노드를 결정한다. 

 

예를 들어 다음과 같이 CPU 10을 필요로 하는 포드를

CPU 4, CPU 4, CPU 12, CPU 16를 리소스를 갖는 노드에 배포한다고 해보자.   

 

 

이 때 다음과 같은 과정을 통해 최적의 노드를 결정한다.

 

1) Filter Nodes 

해당 포드에 적합하지 않는 노드는 먼저 제외된다. 

즉 CPU 4, CPU 4인 노드는 제외된다. 

 

2) Rank Nodes

필터링되지 않은 노드 중에서 priority function을 이용하여 어떤 노드가 적합한지 노드 우선순위를 정한다. 

이 때 CPU가 16인 노드는 6의 CPU의 여유가 있고, CPU가 12인 노드는 2의 CPU가 남으므로 

CPU가 더 많이 남은 CPU16노드가 우선순위가 더 높으므로 CPU 16인 노드가 적합한 노드가 된다. 

 

물론 이러한 옵션들은 예시이며 이는 custom이 가능하다. 

 

 

 

 

 

2. Kubelet

 

kubelet은 워커 노드에서 선장과 같다.

 

 

kubelet은 워커 노드에서 다음과 같은 일들을 한다.

 

1) Register Node

워커 노드의 kubelet은 먼저 노드를 K8S 클러스터의 노드로 등록한다.

 

2) Create Pods

kube api server로부터 포드를 생성하라는 요청이 들어오면

docker engine에게 container생성을 요청한다. 

 

3) Monitor Node & Pods

노드와 포드를 모니터링하고 Kube-api server에게 주기적으로 상황을 보고한다. 

 

 

 

참고로 kubeadm은 Kubelet을 배포하지 않으므로 따로 설치해주어야 한다. 

 

 

 

 

 

3. Kube-proxy

 

클러스터 내의 한 포드에서는 클러스터의 모든 포드로 요청을 보낼 수 있다.

 

이는 kube-proxy가 있기 때문에 가능한 것인데 다음 예시를 통해 kube-proxy의 역할을 더 자세히 알아보자. 

 

 

왼쪽 노드에 web 앱, 오른쪽 노드에 database가 있다고 하자.

 

일반적으로 web에 db를 attach할 때는 ip를 통해서 접근한다. 

 

하지만 Ip가 항상 같은 형태를 유지할 것이라는 보장이 없기 때문에 

db에 대한 service object를 만들어 이를 dns name으로 접근하게 한다면 ip gurrantee 문제는 해결된다. 

 

여기서 service의 원리를 살펴보자.

어떻게 pods에 접근하게하고 IP를 어떻게 할당됐을까?

 

사실상 service는 actual thing이 아니며 이를 가능하게 하는 것이 바로 Kube-proxy이다. 

 

Kube-proxy는 새로운 서비스를 찾고, 찾을 때 마다 각 포드로 갈 수 있는 rule을 형성해준다.

 

또한 kube-proxy는 처음 생성될 때 demonset으로 배포되어 있기 때문에

클러스터 내의 모든 포드에서 요청과 응답이 가능한 것이다. 

 

 

 

다음은 마스터 노드에서 생성되어 있는 kube-proxy