Kubernetes 아주 조금만 알아보자 - 마스터, 노드

※ 개인적으로 받았던 Kubernetes 교육을 정리한 내용입니다.

1편 > Kubernetes 아주 조금만 알아보자 - Kubernetes란? : https://koocci-dev.tistory.com/3

2편 > Kubernetes 아주 조금만 알아보자 - Kubernetes의 흐름 : https://koocci-dev.tistory.com/5

3편 > Kubernetes 아주 조금만 알아보자 - 마스터, 노드 : 현재 Post

4편 > Kubernetes 아주 조금만 알아보자 - Model, Declared State, Pod  : https://koocci-dev.tistory.com/10

5편 > Kubernetes 아주 조금만 알아보자 - ReplicaSets,Deployments : https://koocci-dev.tistory.com/11

6편 > Kubernetes 아주 조금만 알아보자 - Service : https://koocci-dev.tistory.com/12

---

Master(Control Plane) 란?

Master에 대한 설명은 이전 Post 부터 진행했다.

Master는 1개만 떠도(Single-host master) 상관 없지만, 여러개 뜨는 것(Multi-host HA masters)이 이상적이며,

또한, 가장 Best practice는 Master에 App을 실행하지 않는 것이라는 것도 이야기 하였다.

 

그럼 한 번 정리해보도록 하자.

1. API Server
2. Cluster store
3. Controller Manager
4. Scheduler

앞선 포스트(2편 참조)에 첨부된 이미지 상으로 위 4가지가 속해있다는 것을 보았다.

 

API Server는 Control Plane의 FrontEnd이고, REST API Endpoint이며, 다음과 같은 일을 한다.

• POST manifest files
• Manifest 파일의 유효성을 검사한 후, 클러스터에 배포
• Cluster의 Brain

Cluster Store는 앞선 포스트에서 배웠던, Key/Value Store 다.

• 클러스터의 메모리
• 클러스터 컴포넌트의 유일한 Stateful
• etcd의 기반이며, 보호가 필요 (etcd가 kuberenetes 상, K/V Store다)

Controller manager (kube-controller-manager) 는 주기적으로 Kubelet과 통신하는 Operator다.

• Controller의 Controller
• Node controller, endpoint controller, namespace controller 등이 있음.
• 변경 사항을 관찰하고 클러스터의 현 상태(Actual State)가 원하는 상태(Desire State)와 일치하는지 확인

Scheduler (kube-scheduler)는 Affinity, anti-affinity, 제약 조건 및 리소스 관리를 기반으로 새로운 작업을 Node에 예약한다.

여기서, Affinity/anti-affinity는 그대로 번역하면 친화력/비 순응성 등으로 번역되는 데, 이를 쉽게 생각하면, "같이 뜰 것이다/안 뜰 것이다"를 말한다.

예를 들어, "메모리가 몇 이상일 때 뜰것이다.", "CPU Core가 몇 개 이상일 때 뜰 것이다." 등을 말한다.

---

Nodes(Formerly minions) 란?

Node는 다음과 같은 것들로 구성되어 있다. (Node를 쉽게 이해하기 위해서 하나의 리눅스 서버라고 보면 좋다. 여기서, 물리적인 단위가 아니라 VM에서도 올릴 수 있다는 것을 표현하기 위해 리눅스 서버라고 하였다)

• Kubelet
• Container runtime
• Kube-proxy

Kubelet은 서비스가 올라가는 하나의 Container가 확실히 동작하도록 관리하는 것이다.

Container runtime은 Container 엔진이며, Kube-proxy는 Container간의 Network다.

 

그럼 하나씩 알아보도록 하자.

 

Kubelet은 자주 설명하였지만, 다시 한 번 정리해보겠다.

• Kubernetes의 에이전트
• 모든 클러스터 노드에서 실행
• 새로운 작업이 할당되는지, API 서버를 확인
• kubelet이 특정 작업을 수행 할 수 없을 때 수행할 작업을 마스터에게 보고하고 Control Plane이 결정하도록 함.

Container runtime은 앞서, Container 엔진이라고 설명하였고, 컨테이너의 동작을 책임지는 소프트웨어이다.

예를 들면 다음과 같다.

• Image Pulling
• Start/Stop containers.
• etc.

마지막으로, Kube-proxy를 보자.

 

Kube-proxy 이해

Kube-proxy를 이해하기 위한 이미지를 위에 첨부하였다.

위 네트워크 흐름을 설명해보면, 실제를 각각의 Node를 통신하는 Network는 하단의 HW부분까지 통과해 진행되지만, 가상의 영역으로 볼 때, 물리적인 Network를 생각하지 않고, 성립이 되는 것을 볼 수 있다.

 

이러한 방식으로 터널링을 하는 것을, Overlay Network 라고 한다.

 

이러한 Network는 Kubernetes CNI(Container Network Interface) Plugin을 통해 구성되며, 이러한 내용으로 통신하게 해주는 것이 Kube-proxy 이다.

 

이렇게 가상화하는 이유는 어떤 Host에 있던지, Pod(아래에 간단히 설명)끼리 통신할 수 있게 한다는 것이다.

 

즉, Node가 죽었을 때, 가능한 곳을 찾아 이를 살려서 사용할 수 있다는 것이다.

 

추가로 하는 일을 정리해보면 다음과 같다.

 

• Kubernetes Networking의 Brain
• Pod IP address들 (Pod 안의 모든 Container들은 단일 IP를 공유한다)
• 서비스 안 모든 pod을 Load balance 한다.

계속해서 Pod 이라는 것이 나오는데, 일단 Kubernetes 스케줄링에서 사용하는 최소 단위로 생각하자.(Container와는 다르고, Container를 포함할 수 있는 Container 정도로 생각하자 / 1~2 포스트 후에 좀 더 자세히 알아볼 것이다.)

 

Pod간의 Network를 하는 것을 Pod-network라고 하며,(Overlay Network) 이 Pod-network를 구현하는 방식인 CNI Plugin은 여러 개이다.

 

여러 개라는 것은 선택해서 사용할 수 있다는 것이고, Docker swarm의 경우는 Built in 되어 있는 Plugin이 있지만, Kubernetes는 처음부터 정하여 구성해야 한다.

 

조금만 더 거시적으로 정리해보자.

 

Docker(Single Node)에서 내/외부 연결을 보면 다음과 같이 구현된다.

Docker의 통신

그렇다면, Kubernetes 내부 환경처럼 Multi Node가 된다면 어떻게 될 것인가?

Multi Node 에서 Kube-proxy

Kubernetes Cluster는 현재 버전까지는 같은 L2에 묶여있어야 한다.

각각의 Node는 Kube-proxy를 가지고 있고, Node 서로간의 통신을 Master 의 API Server를 통해 통신을 한다.

서로가 어디에 떠 있는지 알고, API Call을 통해, Pod-Network로 연결하며, Proxy가 Load balancing으로 여러 Node중 한 개를 선택해 Client의 Request를 해결한다.

 

위 이미지에서 L4와 연결되어 있는 부분은 Proxy들에 대한 Load-Balancing 처리도 한번 더 가능하다는 것이다.

 

위의 네트워크 부분은 내부적으로 NAT(Network Address Translation) 라던지, Docker에서의 네트워크부터 조금씩 알아가야 한다.

 

이부분은 이후에 서비스 등 추가적으로 설명해야 하는 부분이 있어 나중에 정리하도록 하고 이번 포스트를 마친다.