Kubernetes 구성 요소

쿠버네티스 컨트롤 플레인 구성 요소에 대해서 알아보겠습니다. 

 

먼저 쿠버테니스를 배포하면, 클러스터를 얻습니다. 

 

클러스터란?

애플리케이션 컨테이너를 실행하기 위한 일련의 노드 머신입니다. 최소 수준에서 클러스터는 컨트롤 플레인 및 하나 이상의 노드라는 워커 머신의 집합을 가지고 있습니다. 

 

워커 노드란?

애플리케이션의 구성 요소인 파드를 호스트 합니다. (파드는 다음 포스팅에서 설명하겠습니다.)

 

출처: https://kubernetes.io

위의 사진을 보며, 컨트롤 플레인의 구성 요소 살펴보겠습니다.

1. Control Plane Component

1. kube-apiserver

kube-apiserver는 마치 웹 애플리케이션에서 프런트 엔드가 있듯이 컨트롤 플레인에서의 프런트 엔드입니다. 즉 마스터 노드의 중심에서 모든 클라이언트, 컴포넌트로부터 오는 요청을 전부 받아냅니다. api server는 복잡한 컴포넌트는 아니고, 단순한 API Server의 동작을 수행합니다. 그렇다면 어디에 위치에 있는지 확인해 보겠습니다. 

 

아래의 명령어를 통해서 namespace를 확인합니다. (namespace란 간단하게 클러스터 내에서의 논리적인 분리 단위입니다. 완전히 같지는 않지만 VM처럼 리소스를 나눠서 사용합니다.)

kubectl get namespace

 

저 같은 경우 default, kube-node-lease, kube-system 등등 여러 가지 namespace가 존재하고, 저희가 살펴볼 곳은 kube-system입니다. 

 

kube-system에 존재하는 pod를 살펴보겠습니다. 

kubectl get pod -n namespace

 

여기서 api-server를 발견할 수 있습니다. 

명령어를 통해 api-server에 대한 정보를 볼 수 있습니다. 

kubectl describe pod kube-apiserver-minikube -n kube-system

 

2. etcd

etcd는 모든 클러스터 데이터를 담는 뒷단의 저장소 입니다. 일관성과 고가용성을 갖추었고, 키-값으로 저장돼 있습니다. 클러스터의 데이터를 담기 때문에 클러스터에서 문제가 생겼을 때 백업을 해놨다면, 클러스터를 복구할 수 있습니다. etcd의 정보를 보겠습니다. 

모든 정보를 볼 수는 없고, 어디에 저장되는지 보겠습니다.

kubectl describe pod etcd-minikube -n kube-system

 

 

저는 minikube로 쿠버네티스를 가동하고 있습니다. /var/lib/minikube/etcd를 가면 데이터를 볼 수 있습니다. 

먼저 데이터가 저장되는지 확인하기 위해 백업을 위한 스냅샷을 만들어보겠습니다. 

minikube는 docker 컨테이너로 동작하므로 마스터 노드의 컨테이너에 접속 -> etcd를 실행하는 container로 접속해 줍니다. 

 

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 snapshot save snapshotdb

 문서에 기입된 것 처럼 위의 명령어로 실행하였으나 

위에서 진행되지 않았습니다. 따라서 pod의 로그를 확인해 봤습니다. 

kubectl logs etcd-minikube -n kube-system


// 로그
{"level":"warn","ts":"2023-01-07T10:37:35.670Z","caller":"embed/config_logging.go:169","msg":"rejected connection","remote-addr":"127.0.0.1:36060","server-name":"","error":"remote error: tls: bad certificate"}

https로 호출하는 것이 문제로 파악했습니다. 따라서 http로 변경한 후에 호출했습니다. 

 

그래도 실행이 안 되기에 log를 다시 확인해 봤습니다. 

{"level":"warn","ts":"2023-01-07T10:40:50.192Z","caller":"embed/config_logging.go:169","msg":"rejected connection","remote-addr":"127.0.0.1:33186","server-name":"","error":"tls: first record does not look like a TLS handshake"}

tls 인증서 문제이므로 cacert, cert, key 정보를 추가하고, 다시 https로 변경했습니다. 해당 정보는 etcd pod를 describe 해서 얻을 수 있습니다. 

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/var/lib/minikube/certs/etcd/ca.crt --cert=/var/lib/minikube/certs/etcd/server.crt --key=/var/lib/minikube/certs/etcd/server.key snapshot save snapthot.db

 

 

로그를 확인해보니, 정상 저장돼었으므로 확인해 줍니다. minikube로 컨테이너로 접속해서 /var/lib/minikube/member/snap

 

스냅숏이 생성된 것을 볼 수 있습니다. 이처럼 etcd는 저장소를 담당하는 중요한 역할입니다.

 

3. kube-scheduler

마찬가지로 kube-system에 위치합니다.

노드가 배정되지 않은 새로 생성된 파드를 감지하고, 실행할 노드를 선택하는 역할을 합니다. 

스케쥴링을 하며, 여러 가지 고려되는 요소들도 있습니다. affinity, taint, 명세 등등 이것은 파드에 대해서 알아볼 때 자세히 알아보겠습니다.

 

4. kube-controller-manager

API server를 통해 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 만들 수 있게 하는 컴포넌트입니다. 

논리적으로, 각 컨트롤러(노드, 잡, 엔트포인트 등등)는 분리된 프로세스지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고, 단일 프로세스 내에서 실행됩니다. 몇 가지의 컨트롤러에 대해서 알아보겠습니다. 

 

Node Controller: 노드가 다운 됐을 때 통지와 대응

Job Controller: 일회성 작업인 잡 오브젝트를 감시하고, 작업을 완료할 대까지 동작하는 파드를 생성

EndPoint Controller: 엔드포인트 오브잭트를 채운다(Service와 Pod를 연결함)

 

여기까지 컨트롤 플레인 컴포넌트에 대해서 알아봤습니다. 이제 노드 컴포넌트에 대해서 알아보겠습니다.

2. Node Component

1. kubelet

클러스터의 각 노드에서 실행되는 에이전트로서 파드에서 컨테이너가 확실하게 동작할 수 있도록 관리해 줍니다. 위에서 사용한 kubectl 같은 명령어들이 api-server로 전송된 후 kubelet으로 전송됩니다. kubelet은 명령어를 수행하고, 컨테이너가 있다면, 정상적으로 수행하는지 확인합니다.

 

2. container runtime

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

 

3. kube-proxy

쿠버네티스 클러스터의 각 노드에서 실행되는 네트워크 프락시로, 네트워크 요청을 전달하는 역할입니다. kube-proxy라는 오브젝트를 통해서 고정적으로 파드에 접근할 수 있는 방법을 제공합니다.

 

다음은 Pod에 대해서 알아보겠습니다. 감사합니다.