k8s: 구조 및 구성 요소

쿠버네티스를 설치 할 때 kubelet, kubeadam kubectl과 같은 구성 요소들을 설치하게 된다. 각 구성 요소들에 대해 간략히 알아보게 된다면, 전체적인 구조를 이해하는데 도움이 될 것 같아 정리하고자 한다.

 

 

구조

출처 : https://www.guru99.com/kubernetes-tutorial.html

 쿠버네티스의 전체적인 구조는 위의 그림과 같이 하나의 Master와 다수의 Worker 노드로 구성되어 있다. 그림에서는 local 환경에서 쿠버네티스를 구축한 경우이다. 본 글에서는 로컬 환경에 쿠버네티스를 구성할 경우를 중점으로 각 구성요소들을 설명하고자 한다.

 

Master Node

 마스터 노드의 경우 워커 노드를 관리, 모니터링 하며 Pod가 실행되는 적절한 Worker Node를 스케줄링하는 역할 등과 같이 전반적으로 노드와 Pod를 관리하는 역할을 수행한다.

 (Pod : 하나 또는 다수의 컨테이너가 실행 될 수 있는 쿠버네티스의 오브젝트, 다음 글에서 자세히 다루고자 한다.)

 

 마스터 노드의 구성 요소 중 핵심은 다음과 같다.

• ETCD
• API-server
• Controller-Manager
• Scheduler

 

Worker Node

 요청된 Pod들이 실행될 수 있는 환경을 제공하며, Pod의 상태와 노드의 상태를 주기적으로 마스터 노드와 통신하여 Pod가 요청에 맞게 잘 실행되며 이를 관리하는 역할을 수행한다.

 

 

 워커 노드의 구성 요소 중 핵심은 다음과 같다.

• kublet
• proxy
• Container Engine

---

구성 요소

 앞 절에서 간략히 각 노드 별로 구성되는 요소들을 확인하였다. 각 구성 요소들의 기능에 대해 마스터 노드, 워커 노드 순으로 알아보고자 한다.

 

Master Node Component

ETCD

 ETCD는 key-value 방식으로 정보를 저장한다. 쿠버네티스에서는 클러스터와 관련된 전반적인 정보를 저장한다. 예를 들면 노드, Pod, 설정 정보 등이 있을 수 있다. ETCD의 정보들은 kubectl get 명령을 통해 확인할 수 있다. 

 

 (key-value : key 값을 통해 value를 찾을 수 있는 저장 방식, 전통적인 저장 방식은 아니지만, 설정과 상태 정보를 관리하기에 효율적인 방식이다.)

 

API Server

 API server는 그림에서도 볼 수 있는 것과 같이 kubectl로 부터 명령을 받아, 인증 과정을 거쳐 원하는 기능을 수행하기 위해 각 컴포넌트에 전달하는 방식을 통해 작업을 수행한다. 어떤 한 작업을 할 건지, 특정 컴포넌트에서 결정되면 워커 노드의 kublet으로 전달하여 작업이 진행될 수 있도록 한다. 즉, API Server를 통해 각 노드들과 통신을 한다.

 

Controller

 kube-Controller-Manager는 다양한 구성 요소들을 관리하는 역할을 담당한다. Deployment, Namespace, Endpoint, CronJob, Service 등 다양한 요소들을 관리한다. 그 중 Node Controller에 대해 간략히 알아보면 다음과 같다.

 

 Node Controller는 API server를 통해 특정 시간 마다 hear beat를 보내 워커 노드들의 상태를 확인한다. 만약 일정 시간 동안 응답이 없을 경우, 해당 노드가 사용 불가능한 것으로 간주한다.

 

Scheduler

 특정 Pod가 어떤 노드에 실행 될지를 결정한다. 이는 Node Controller를 통해 각 워커 노드의 상태를 파악하고 있기에, 워커 노드의 상태에 따라 적절히 Pod를 할당할 수 있다. 스케줄러는 각 워커 노드의 사용 가능한 시스템 자원에 따라 등급을 부여하여, Pod의 요청된 시스템 자원에 따라 가장 적합한 노드를 선택하는 방식을 사용한다.

 

 

쿠버네티스 노드 별 구성 요소들

 

Worker Node Component

kublet

 워커 노드를 관리하는 역할을 하며,  클러스터에 Regiseter 하거나 노드, Pod 상태를 모니터링 하는 역할을 담당한다.

 

proxcy

 서로 다른 노드에 존재하는 Pod들은 동일한 네트워크 상에 있어 서로 접근할 수 있다. 하지만 Pod의 경우 외부에서는 접속할 수 없다는 특징을 가지고 있다. 이에 서비스를 만들어 외부에서 접근할 수 있는 IP를 지정하고, 해당 서비스에서 특정 Pod로 접근할 수 있도록 하는 방식을 사용한다.

 

 여기서 드는 의문점은 서비스의 경우 어떤 방식으로 Pod에 접근하는지이다. 서비스의 경우 Pod와 동일한 네트워크를 사용하지 않으며, Proxy를 통해 Pod에 접근한다. Proxy는 각 노드에 실행되며, 서비스가 생성될 때 관련된 Pod로 접근 가능한 규칙들을 생성하여 Pod에 접근할 수 있도록 한다.

 

 즉, 생성된 서비스의 IP가 192.168.0.7이고, Pod의 IP가 10.32.0.7이라면 192.168.0.7 → 10.32.0.7로 통신할 수 있도록 경로에 대한 정보를 유지한다고 보면 된다.