[ k8s ] kubernetes 개념 (node, control plane)

Node란?

kubernetest는 pod내에 container를 배치하고, pod는 언제나 Node상에서 동작합니다 (workload를 구성).

쿠버네티스에서 가장 큰 단위인 클러스터내에서 존재하는 가상의 서버로 컴퓨팅 엔진 단위라고 생각할 수 있습니다.

또한 노드는 쿠버네티스에서 워커 머신을 말하며 클러스터에 따라 가상 또는 물리 머신일 수 있습니다.

각 노드는 컨트롤 플레인(컨테이너의 라이프사이클을 정의, 배포, 관리하기 위한 API와 인터페이스들을 노출하는 컨테이너 오케스트레이션 레이어)에 의해 관리되며, Pod를 실행하는데 필요한 서비스를 포함합니다.

하나의 노드는 여러 개의 파드를 가질 수 있고, 쿠버네티스 컨트롤 플레인은 클러스터 내 노드를 통해서 파드에 대한 스케쥴링을 자동으로 처리합니다. 컨트롤 플레인의 자동 스케줄링은 각 노드의 사용 가능한 리소스를 모두 고려한다고 합니다.

• 마스터 노드: 전체 쿠버네티스 시스템을 관리 및 통제하는 쿠버네티스 컨트롤 플레인을 관장
• 워커 노드: 배포하고자 하는 어플리케이션의 실제 실행을 수행 (노드 컴포넌트)

 

Worker Node Components

 

Kubelet: 노드에서 컨테이너가 동작하도록 관리해주는 핵심 요소입니다. 각 노드에서 파드를 생성하고 정상적으로 동작하는지 관리하는 역할을 담당하며, 실제로 우리가 쿠버네티스 워크로드를 관리하기 위해 내려지는 명령은 kubelet을 통해 수행된다고 볼 수 있습니다.

우리가 쿠버네티스 파드를 관리하기 위해 작성하는 YAML을 쿠버네티스 클러스터에 적용하기 위해 kubectl 명령어를 사용할 때, 이 YAML이 kube-apiserver로 전송된 후 kubelet으로 전달됩니다. kubelet은 이 YAML을 통해 전달된 파드를 생성 혹은 변경하고, 이후 이 YAML에 명시된 컨테이너가 정상적으로 실행되고 있는지 확인합니다.

 

container runtime: 컨테이너 런타임은 파드에 포함된 컨테이너 실행을 실질적으로 담당하는 애플리케이션을 의미합니다. 단, 컨테이너 런타임은 쿠버네티스 구성 요소에 기본적으로 포함되어 있거나, 특정 소프트웨어를 지칭하는 것은 아닙니다. 쿠버네티스가 컨테이너를 제어하기 위해 제공하는 표준 규약인 컨테이너 런타임 인터페이스(CRI)를 준수하여 쿠버네티스와 함께 사용할 수 있는 외부 애플리케이션들을 의미합니다. ex) containerd, CRI-O

간단히 말해서 레지스트리에서 컨테이너 이미지를 가져와 묶여 있는 것을 풀고 애플리케이션을 동작시키는 책임

 

kube-proxy:  kube-proxy는 쿠버네티스 클러스터 내부의 각 노드에서 네트워크 요청을 전달하는 역할을 합니다. 쿠버네티스에서 Service라 불리는 객체의 IP 및 port로 들어온 내/외부 트래픽을 Service endpoint에 해당 하는 Pod중 어떤 Pod로 포워딩할 것인지에 대한 규칙을 생성하고 관리하는 역할을 합니다. 이를 위해 kubeadm은 모든 노드에 kube-proxy pod를 daemonset으로 배포합니다. (daemonset이라 프로세스가 죽어도 다시 살아남)

pod ip를 어떤 서비스의 endpoint로 정하는 것은 가능하지만, pod가 새로 생성되었을 때 그 주소가 같을 것이라고는 보장하지 못합니다. 이러한 이유로 Service가 필요합니다.

 

쿠버네티스에서 파드들은 그 자체로 반영속적(ephemeral)입니다. 필요에 따라 파드들이 각기 다른 노드들에 배치되기도 하며, 때로는 특정 노드가 죽으면서 기존의 파드들이 다른 노드로 옮겨지기도 합니다. 이처럼 노드와 파드의 상태는 언제나 유동적이므로 네트워크 상에서 접근 가능한 IP도 항상 바뀌게 됩니다. 이런 환경에서 파드들 간의 상호 네트워킹을 보장할 수 있는 방법이 바로 서비스(Service)를 이용하는 것입니다.

 

쿠버네티스에서 서비스(Service)는 Pod들을 통해 실행되고 있는 application을 네트워크에 노출시키는 가상의 컴포넌트를 의미합니다. 서비스는 파드나 컨테이너처럼 구체적인 실체가 없고, 오직 파드들 간의 네트워크 중계만을 수행합니다.

노드/파드들의 목록을 관리하며 필요한 쪽으로 트래픽을 전달해주는 프록시 역할의 구현체라고 보면 욉니다. 이를 위해 서비스 역시 클러스터로부터 내부 IP를 할당 받으며, 파드들 간의 연결을 담당하는 게이트웨이와 같은 역할을 하게 됩니다. 이러한 역할을 하는 서비스로 파드들이 접근 가능하도록 해주는 프로세스가 kube-proxy인 것이다.

 

Service가 생겨난 요구 사항 3가지: 첫 째로 proxy server는 스스로 내구성이 있어야 하며 장애에 대응이 가능해야 합니다. 두 번째로는 트래픽을 전달할 서버 리스트를 갖고 있으며, 마지막으로 해당 서버가 정상적인지 확인할 수 있어야 합니다.

 

 

 

Control plane이란? (Master Node)

쿠버네티스 클러스터 기능 제어를 전체적으로 담당하는 역할을 수행하며, 다음과 같은 구성요소로 이루어져 있습니다.

• API Server
• Scheduler
• Controller Manager
• etcd

kube-apiserver: 공식 문서에서는 kube-apiserver를 ‘쿠버네티스 컨트롤 플레인의 프론트 엔드’ 라고 소개하고 있습니다. 쿠버네티스 클러스터로 들어오는 request를 가장 앞에서 접수하는 역할을 하며 일례로 kubectl을 사용해 각종 명령을 수행할 경우 이 명령은 kube-apiserver로 전송됩니다. 이렇게 전달된 요청들은 처리 흐름에 따라 적절한 컴포넌트로 전달하는 역할까지 맡고 있습니다. (모든 구성요소는 API서버로만 통신한다.)

1. API 서버가 먼저 파드 객체를 생성한다.
2. API 서버는 etcd에 새 파드가 생성되었음을 업데이트한다.
3. 스케줄러는 API 서버를 모니터링하여, 새 파드가 생겼음을 인지하고 이를 배포할 노드를 확인한다.
4. API 서버는 etcd에 정보를 업데이트한다.
5. API 서버가 해당 정보를 적합한 노드의 kubelet에 전달한다.
6. kubelet이 해당 노드에 파드를 생성하고, 컨테이너 런타임 엔진에 해당 애플리케이션 이미지를 배포하도록 지시한다.
7. kubelet은 API 서버에 상태를 업데이트시키고, API 서버는 이 상태 데이터를 etcd에 저장한다.

 

etcd: 쿠버네티스 클러스터가 동작하기 위해서는 클러스터 및 리소스의 구성 정보, 상태 정보 및 명세 정보 등이 필요합니다. etcd는 이를 키-값(key-value) 형태로 저장하는 저장소로 계층적 key구조로 쿠버네티스의 데이터를 저장합니다. (/registy아래에 모든 데이터를 저장)

쿠버네티스에서 생성된 모든 오브젝트는 상태와 메니페스트를 영속적으로 유지해야 합니다. 안정정인 동작을 위해 etcd는 분산된 아키텍처 형태를 가질 수 있으며 이를 통해 고가용성 및 빠른 성능을 제공합니다.

마찬가지로 etcd와 통신하기 위해서는 apiserver를 거쳐야 하며 이를 통해 데이터 유효성 검사, 낙관성 동시성 제어를 지원할 수 있습니다.

# 분산된 etcd 클러스터는 RAFT 합의 알고리즘에 의해 데이터 일관성을 유지합니다. 

 

kube-scheduler: 쿠버네티스 클러스터는 여러 노드로 구성되어 있습니다. 그리고, 기본적인 작업 단위라고 할 수 있는 Pod는 여러 노드 중 특정 노드에 배치되어 동작하게 됩니다. 이때 새로 생성된 파드를 감지하여 어떤 노드로 배치할지 결정하는 작업을 스케쥴링이라고 하며 이를 담당하는 컴포넌트가 kube-scheduler입니다.

스케줄링을 위해 노드 및 파드의 각종 요구사항과 제약사항을 종합적으로 판단할 필요가 있는데, 이러한 판단 또한 kube-scheduler의 역할입니다. (어떤 노드에 스케쥴링 될지 결정하고 pod의 spec을 변경하고 이를 apiserver에 전달 -> 최종적으로 apiserver는 kubelet에게 이 정보를 보냄으로써 pod가 해당 노드에서 실행됩니다.)

 

kube-controller-manager: kube-controller-manager는 다운된 노드가 없는지, 파드가 의도한 복제(Replicas) 숫자를 유지하고 있는지, 서비스와 파드는 적절하게 연결되어 있는지, 네임스페이스에 대한 기본 계정과 토큰이 생성되어 있는지를 확인하고 적절하지 않다면 적절한 수준을 유지하기 위해 조치하는 역할.

쿠버네티스의 컨트롤러를 실행 및 관리하는 역할이며 컨트롤러는 API 서버를 통해 리소스의 변경을 감시하고 변경하는 작업을 담당합니다. 클라이언트가 선언한 Spec으로 조정하며 새롭게 변경된 상태를 Status에 저장합니다. 쿠버네티스에는 기본적으로 제공되는 다양한 Controller가 존재합니다. (ex. Deployment, ReplicaSet, StatefulSet 등)

 

DNS Server: 클러스터 안에서 특정 도메인을 찾을 때 사용되는 네임 서버

 

ex) deployment를 통한 pod생성 순서

1. 요청을 보내게 되면 Deployment Controller가 새롭게 생성된 Deployment Manifest를 발견하고 해당 정보를 통해 ReplicaSet을 생성합니다.
2. ReplicaSet의 생성이 감지되면 ReplicaSet Controller는 ReplicaSet의 Pod Template을 기반으로 Pod을 생성합니다.
3. Scheduler는 적합한 노드에 Pod을 스케줄링합니다.
4. Kubelet은 Pod의 컨테이너 런타임과 이미지를 통해 컨테이너를 실행합니다.