[K8S] Control Plane(Master Node), Worker Node

2023.09.27 - [Infra Architecture/Kubernetes] - [K8S] Kubernetes(쿠버네티스)

[K8S] Kubernetes(쿠버네티스)

 

꽤된 포스팅인데 친절하게 작성했던거 같다. 요즘은 빨리 빨리 작성해야하니 다나까로 바꾸겠다.

무튼, 이전에는 쿠버네티스의 역할, 왜 사용해야하는지 어떤건지에 대해 알아보았다.

 

CKA의 자격증을 공부하면서 이론 부분도 다시 머리속에 재 정립하고자 하는 공부하는 글이다.

최대한, 공식문서를 참고하여 실생활의 메타포를 곁드려 작성할 생각이니.... 어울리지 않더라도 많은 양해바란다.

 

컨테이너 오케스트레이션은 컨테이너를 관리하는 것이다. 그러면 어떻게 관리를 하지?

 

관리 방법을 알아보기 이전에 쿠버네티스를 배포하면 어떤 일들이 일어나는지 확인해보자.

쿠버네티스를 구축하게 되면 클러스터를 얻게 된다.

※ Cluster 사전적 의미로는 군체, 집속체, 무리 등등 밀접해있는 다수의 무언가를 총칭하는 단어이다. 뉴스에도 반도체 클러스터니 이런 이야기들이 나오는데 다 반도체 사업을 위한 모든 서비스들을 한쪽에 군집화해서 구축하다는 것이다. 즉, 쿠버네티스를 구축하게되면 일종의 군집화가 생김을 의미한다는 것이다.

 

 쿠버네티스 Cluster를 구축하게되면 워커머신(컨테이너화된 애플리케이션)의 집합인 노드가 생기고 모든 클러스터는 최고 한 개의 이상의 노드가 생기는데 우리는 이를 "워커노드" 라고 부른다. (일해라 노드야)

 

워커노드는 어플리케이션의 구성요소인 파드를 호스트한다. Pod는 나중에도 나오겠지만 가장 쿠버네티스 클러스터의 가장 최소 단위중 하나이다. pod보다 작은 단위는 없다.

 

워커노드가 있으면 관리자가 있어야하지 않겠나? 우리는 이 관리자 역할을 하는 노드를 마스터 노드 혹은 Control Plane이라고 한다. 마스터 노드는 어원이 좋지않아 요즘은 Control Plane이라고 한다. 

 

우리가 앞선 포스팅에서 내결함성과 고가용성 확보라고 표현을 하였는데 실무에서  Control Plane과 Worker노드가 이를 확보한다. 워커노드는 클러스터에서 일반적으로 여러 노드가 실행되고 Control Plane은 여러 컴퓨터에 걸쳐서 실행되기 때문이다.

※ 내결함성 & 고가용성 내결함성은 시스템의 일부 구성요소가 작동하지 않더라도 계속 작동할 수 있는 속성을 이야기한다. 즉 손가락이 부러져도 우리는 누워만 있지는 않는다. 움직일 수 있다. 고가용성은 얼마나 지속적으로 서비스를 운영이 가능하냐의 속성을 이야기한다. 잠 안자고 공부를 계속하면 나는 고가용성이 높은 인간일지도.... 계속자기만 하면 고가용성이 떨어지겠지

 

이번에 알아볼 것은 Control Plane의 구성요소에 대해서 알아볼 것이다.

 

---

# Control Plane

Cluster의 전반적인 결정을 수행하는 역할을 한다. 클러스터에서 발생하는 이벤트들을 감지하고 반응하는 역할을 하게된다.

 

# kube-apiserver

kube-apiserver는 쿠버네티스 컨트롤 플레인의 컴포넌트중 하나이다. 클러스터의 모든 통신은 apiserver를 거쳐서 들어온다. 클러스터 입장에서 보았을때 프론트앤드와 같다. 또한 apiserver는 수평적 스케일링을 위해 설계되었기때문에 더 많은 인스턴스 배포가 가능하다.

# etcd

지속적이고 고가용성의 key -value 저장소로 클러스터의 데이터를 저장한다. key -value 저장소하면 개발자들은 redis가 먼저 생각날 것이다. 나 역시 그랬다. etcd를 제대로 알기 위해 한번 두가지를 비교하자.

 

redis와 etcd의 가장 큰 차이점은 목적에 있다. redis의 목적은 빠른 시간에 데이터에 접근하는 것이 가장 큰 목적이지만, etcd는 고가용성을 목적으로 동작한다.

 

목적 자체가 다르기때문에 데이터 저장하는 방식만 똑같지 관리하는 방법자체가 다르다. etcd는 높은 신뢰성을 제공하기 위해서 가진 데이터를 여러 서버에 분산하여 replica를 한다.

 

etcd는 key-value store 오픈소스 중 하나인데 여기서 다루기에는 방대한 양을 갖고 있으니 아래 자료를 참고하면 좋을거같다.

https://tech.kakao.com/2021/12/20/kubernetes-etcd/

Kubernetes 운영을 위한 etcd 기본 동작 원리의 이해

# kube-scheduler

Node가 배정되지 않는 생성된 Pod를 감지하고 어디 노드에 올릴지 선택하는 컴포넌트중 하나이다. 스케듈링은 결정할때는 여러 요소들이 고려되는데 요구사항, 하드웨어, 소프트웨어의 정책적 제약, 어피니티, 안티어피니티 명세 데이터의 지역성, 워크로드간의 간섭, 데드라인을 포함한다. 더 자세한건... 나중에 실습하면서

# kube-controller-manager

여러개의 컨트롤러들이 있고 그 컨트롤러 각각 분리되어 다른 프로세스들은 담담하고 있다.

• 노드컨트롤러
• job 컨트롤러
• 엔드포인트슬라이스 컨트롤러
• 서비스어카운트 컨트롤러

---

마스터 노드가 명령을 하달하고 가장 작은 단위인 Pods를 운용하는 Worker Node의 컴포넌트에 대해서 알아보겠다.

 

# Kubelet

유데미의 뭄샤드 형의 강의에서 Kubelet은 향해사로 비유되어 있다. (worker node는 배다.) 공식문서에 따르면 Pods에서 컨테이너(응용어플리케이션)이 확실하게 동작하도록 관리한다. yaml에서 spec의 집합을 받아 컨테이너가 해당 파드에서 healthy하게 동작하도록 하는것이다.

뭄샤드 형이 향해사라고 한 이유는 어쨋든 배(worker node)에 실은 컨테이너를 관리하는게 향해사의 역할이 아닌가.

 

# Kubel-proxy

각 노드에서 실행되는 네트워크 프록시로, tcp, udp 등과 같은 네트워크 프로토콜을 수행하며 각 노도마다 apiserver에 정의된 service를 반영한다. 실습을 진행하다보면 알겠지만 pod는 끊임없이 생겼다가 삭제되었다가 새롭게 올라온다. 그럴때마다 사실 인터넷 프로토콜이 새롭게 만들어지는데 ip기반으로 통신이 불가하다. 그래서 kube-proxy를 사용한다. (이는 나중에 나올 Service 오브젝트와 관련되어있다.)

 

# Container-rumtime

pods안에 컨테이너로 말려있다면, 어쨋든 컨테이너를 까서 뭐 짐을 옮기든 더 넣던 해야하는 것이 필요하지 않을까? 그게 컨테이너 런타임이다. docker, containerd와 같은 것들

 

위에 세개가 워커노드를 구성하는 3가지인데 워커노드 마다 하나씩 다 있다는 것을 명심해야한다. 실제로 on-premise에 구축할때 마스터노드랑 워커노드랑 연결해두고 워커노드에 컨테이너 런타임인 docker나 containerd를 설치하지 않고 삽질하는 경우가 있다.(그게 나야)

 

---

뭄샤드 형의 강의에서는 하나씩 실행시켜보면서 어떤 것들로 구성되어있는지 알아본다. 사실 etcd가 엄청난 오픈소스인것도 알고 너무나도 뜯어보고 싶기도 하다.

 

어떻게 설계했길래 쿠버네티스의 고가용성과 내결함성을 중점으로 설계한 것인가에 대해

 

일단, CKA를 땄기로 먹고 시험을 신청해두었으니 일단, 시험통과의 위주로 집중을 해야할거 같다. 일단 따야한다! 미친듯이 공부해서