[Kubernetes] 04. 쿠버네티스 구성 요소 확인(+EKS, AKS, GKE)과 파드 배포 흐름

01. 쿠버네티스 구성 요소 확인

이전 시간에 쿠버네티스를 설치하고 Pod를 배포하는 과정을 진행 하였지만, 정작 쿠버네티스가 어떻게 구성이 되어 있는지 알아보지 않았다. 이번 시간에는 조금 더 쿠버네티스의 라이프 사이클을 이해하기 위해 쿠버네티스의 구성 요소에 대해 알아보자.

01-1. 쿠버네티스의 구성 요소

현재 쿠버네티스의 구성 요소는 다음 사진과 같이 구성이 되어있다.

이번 시간에는 대략 이러한 구성요소가 존재한다는 것만 인지하고 넘어가자.

01-2. 구역을 나누는 네임스페이스

쿠버네티스는 구역을 나누는 네임스페이스를 가지고 있다. 즉, 각각의 영역을 네임 스페이스를 기준으로 구분하여 구성이 되있다는 말이다. 이 말만 듣고서는 이해가 쉽지는 않을 것 같으니 하나의 예를 들어보자.

 

오피스텔에는 102호, 103호, 202호 등의 호수가 존재한다. 여기서 102호에 거주하고 있는 사람들은 103호에서 일어나는 일을 알수가 없고, 202호 사람들도 103호에서 일어나는 일을 알 수없는 것은 마찬가지다. 이렇듯 네임스페이스는 각각의 구역을 독립적으로 격리 시키기 위한 하나의 단위라고 생각하면 좋을 것 같다.

01-3. 쿠버네티스의 구성 요소 확인

kubectl get po -n kube-system
NAME                                       READY   STATUS    RESTARTS   AGE
calico-kube-controllers-744cfdf676-kq77l   1/1     Running   1          23h
calico-node-46z26                          1/1     Running   1          23h
calico-node-72rt8                          1/1     Running   1          23h
calico-node-ttbpb                          1/1     Running   1          23h
calico-node-w7rmn                          1/1     Running   1          23h
coredns-74ff55c5b-pbxzx                    1/1     Running   1          23h
coredns-74ff55c5b-w6npr                    1/1     Running   1          23h
etcd-m-k8s                                 1/1     Running   1          23h
kube-apiserver-m-k8s                       1/1     Running   1          23h
kube-controller-manager-m-k8s              1/1     Running   1          23h
kube-proxy-bhtlg                           1/1     Running   1          23h
kube-proxy-cvxnj                           1/1     Running   1          23h
kube-proxy-j49fm                           1/1     Running   1          23h
kube-proxy-vf5zl                           1/1     Running   1          23h
kube-scheduler-m-k8s                       1/1     Running   1          23h

• 해당 명령어를 통해 kubernetes의 구성 요소 확인이 가능하다
• 관리형 쿠버네티스 서비스 역시 kube-system에 구성요소 확인이 가능하다
  • EKS, AKS, GKE 역시 흡사하게 kube-system에 해당 구성요소가 존재
  • 해당 내용은 이번 장에서는 생략하고 넘어감

02. 쿠버네티스의 기본 철학

이전 시간에 네임스페이스를 통해 구역을 나누는 개념이 있다고 확인 하였다. 또한 지금까지 쿠버네티스를 구성하는 주요 개념들이 kube-system 밑에 있어서 실습 과정중에 하나도 보이지 않는 것을 확인 하였으며, kube-system에 갔더니 주요 개념들이 보이는 것을 확인 하였다. 이번 시간에는 이러한 주요 요소들이 어떠한 역할을 담당하는지 알아보자.

02-1. 기본 철학

쿠버네티스의 기본 철학은 MSA(Microservices Architecture)로 구성이 되어있다.

쉽게 말해 하는일들이 개별적으로 모두 나눠져있다고 생각하면 될 것 같다. 다음 예를 한 번 살펴보자.

자동차를 만드는 공장이 존재한다

두 개의 자동차 공장이 있다고 가정 해보자.

 

A 공장은 컨베이어 벨트를 통해 자동차를 생산하고 B 공장은 한 명의 사람이

하나의 자동차의 모든 부품을 넣고 만드는 곳이라고 가정 해보자.

A 공장

함수형 프로그래밍(FP)의 특성에 대해 생각해보면 좋을 것 같다

• 컨베이어 벨트를 통해 자동차의 생산을 순차적으로 진행 한다
• 각 영역(공장)에서는 하나의 일만 수행한다
• 각 영역(공장)은 다른 영역에 의존하거나 참견하지 않는다

B 공장

그림에서는 3명의 사람이지만, 한 명이 존재한다고 가정 해보자

• 한 명의 사람이 모든 부품을 채워넣고 조립한다
• 한 명의 사람이 모든 일을 수행한다
• 한 명의 사람은 다른 영역에 참견해야만 한다

🙂 결론은 쿠버네티스 역시 A 공장과 마찬가지로 하나의 서비스(API, Controller..)가 하나의 역할만 수행하는 MSA 아키텍처의 사상과 비슷한 철학을 가지고 있다는점을 알았으면 좋겠다.

쿠버네티스의 각 서비스가 하나의 역할만 담당한다는 것은 이해가 되었다.

그렇다면 파드가 배포되는 경우 서비스들이 어떻게 명령을 처리하는지 다음 그림을 통해 알아보자.

02-2. 파드가 배포되면?

쿠버네티스의 구성 요소에 명령어를 요청한 상황을 가정한다

kubectl을 통해 파드 생성을 요청한다

# 사용자가 해당 명령어를 통해 파드 생성 명령을 요청한다
kubectl create pod nginx --image=nginx

1. 해당 명령어는 API 서버 & etcd로 넘어가게 된다. 위 그림을 보면 후에 “API 서버가 명령을 받았으니 컨트롤러 매니저에게 명령어를 보내겠군?” 이라고 생각을 할 수 있지만 그렇지 않다. (API 서버의 쿠버네티스의 핵심적인 서비스다, 즉 중심이 되는 움직이지 않는 굳건한 서비스다)

 

3-1. 쿠버네티스의 API 서버는 명령을 보내지 않고, 컨트롤러 매니저에 Pod가 생성했는지 감시를 수행한다.

3-2. API 서버는 선언값만 가지고 있고 컨트롤러 매니저가 해당 값을 보고 파드의 생성을 진행한다.

 

4-1. 또한 API 서버는 새로운 파드가 워커노드에 들어갔는지 스케줄러를 감시한다.

4-2. 스케쥴러는 새로운 파드를 워커 노드에 넣도록 스케줄링을 수행한다.

4-3. 실제 파드의 생성은 Kubelet이 담당한다.

 

5-1. API서버는 새로운 파드가 노드에 잘 소속되어 있는지 Kubelet을 감시한다.

5-2. 파드 상태 정보 전달

 

6. Kubelet은 동작에 대한 관리만 한다

7. 컨테이너 런타임에 의해 컨테이너를 생성한다.

여기서 중요한 부분은 API 서버는 중앙에서 굳건하게 상태 값을 유지하고 있고 컨트롤러 매니저, 스케줄러, Kubelet이 해당 상태를 맞추기 위해 움직이고 있는 그림을 생각하는게 중요한 부분인 것 같다.

02-3. API 서버와 ETCD

API서버와 etcd의 방식은 조금 다르다. API 서버는 가지고 있는 현재 상태, 추구하는 값을 가지고 있다. 이 값들은 휘발이 될 수 있기 때문에 etcd라는 곳(DB)에 저장을 하게 된다. 즉, API서버가 선언을 하면 etcd가 가져가는 것이 아닌 API가 etcd에 넣는 방식으로 구성이 되어있다. etcd는 매번 API 서버에 업데이트가 되었음을 알려준다.

02-4. 2가지만 기억하자

• 선언적인 구조이며 쿠버네티스의 각 요소들은 자기 할일만 한다
  • API 서버: 상태값만 업데이트 다른 요소에 관여하지 않는다
  • 컨트롤러 매니저: API 서버의 상태값에 맞는 상태를 맞추기 위해 움직인다
  • 스케줄러: 실제 배포한 파드가 노드에 assign되어있는지 상태값을 체크한다
  • 즉, 각 요소들은 하나의 일만 담당해서 역할을 수행한다
• 쿠버네티스는 이렇듯 상태를 맞추기위한 철학에 맞춰 일을 수행한다

03. 실제 쿠버네티스의 파드 배포 흐름

위에서 쿠버네티스의 기본 철학과 구성요소들의 메커니즘에 대해 알아보았다.

이번 시간에는 실제 마스터 노드(Control Plan)에 접속하여 구성요소의 동작을 확인 해보자.

03-1. 현재 쿠버네티스 파드 배포 흐름 확인

1. 관리자 혹은 개발자가 kubectl을 통해 명령을 통해서 API 서버에 명령이 들어간다
   1. pod 생성
   2. pod 조회
   3. pod 삭제
2. API 서버는 가장 먼저 해당 정보를 etcd에 저장을 한다 (1:1 동기화 수행)
3. API 서버는 컨트롤러 매니저와의 통신을 수행한다
   1. 컨트롤러 매니저는 API의 서버의 상태를 보고 동기화를 수행한다
4. API 서버는 스케쥴러와의 통신을 수행한다
   1. 스케줄러는 워커 노드에 Pod를 assign 한다
   2. 실제로 Pod가 각 워커 노드에 밸런싱하게 들어가도록 밸런싱 수행
5. API 서버를 보고 kubelet이 파드 생성을 진행
   1. 컨테이너 런타임에 kubelet이 명령을 요청
   2. 컨테이너 런타임에 의해서 실제 파드가 생성이 된다
6. API 서버는 모든 것의 중심이 된다 (정말 중요한 부분)
   1. 쿠버네티스의 통신의 중심
   2. 모든 것의 Gateway
   3. 모든 것의 집합체
   4. 모든 것의 시작과 - 끝
7. Pod 배포시 IP를 따로 지정할 수 없다

참고 자료

• [[인프런] 3.1 쿠버네티스 구성 요소 확인(+EKS, AKS, GKE 관리형 쿠버네티스)]
• [[인프런] 3.2 쿠버네티스의 기본 철학]
• [[인프런] 3.3 실제 쿠버네티스의 파드 배포 흐름]