[k8s] Pod 생성 시 플로우와 쿠버네티스 특성 이해하기

Notice

Tags more

Archives

관리 메뉴

ysuekkom의 IT study note

DevOps/k8s

ysuekkom 2023. 7. 27. 08:00

k8s의 각 구성요소에 대한 설명은 아래 포스팅을 참고하면 된다. 본 포스팅에서는 파드 배포 시, k8s의 각 구성요소들의 동작과 플로우에 대한 내용을 주로 설명한다.

모든 클러스터는 최소 한 개의 워커 노드를 가지며, 워커 노드의 집합을 클러스터라고 한다. 워커 노드는 애플리케이션의 구성 요소 중 하나인 Pod(파드)를 관리하는 역할을 수행한다.

일반적으로 Control Plane(마스터 노드) 여러 개가 실행되고, 여러개의 워커노드 즉 클러스터가 실행하므로, 장애 발생 시 고가용성과 내결함성을 확보할 수 있다.

파드 배포 시 플로우를 확인하기 전에, k8s의 아키텍처에 대한 이해가 먼저 필요하다.

쿠버네티스는 기본적으로 MSA, 즉 마이크로 서비스 아키텍처 모델이다.

MSA와 기존 모놀리딕 아키텍처의 차이는 아래 포스팅 내 클라우드 네이티브 핵심요소 파트를 참고하면 된다.

클라우드, 도커, 컨테이너, 쿠버네티스 ?

이번 포스팅에서는 데브옵스, 클라우드를 검색하면 따라나오는 도커와 컨테이너 그리고 쿠버네티스(k8s)에 대해서 정리해보는 시간을 가지려고 한다. 많이 접하고 들어봤지만, 그래서 그게 뭔데

ysuekkom8915.tistory.com

쉽게 말해 MSA 아키텍처에 의해서,

마스터노드와 워커노드의 구성요소인 api-server, etcd, kube-contrl, scheduler, kubelet, container는 각자 자기 할 일만 한다는 뜻이다.

아래 플로우를 살펴보자.

1. 관리자가 kubectl create pod 명령어를 통해 pod 생성을 요청

2. api-server는 새로운 요청에 따른 클러스터 정보를 etcd(저장소)에 업데이트

3. etcd는 업데이트 결과를 api-server로 전송

4. controller-manager는 api-server의 상태 값을 확인하고, 새로운 pod를 생성

5. 스케줄러는 생성된 pod의 워커노드에 할당 및 상태값 업데이트

6. pod의 상태와 동작을관리하는 워커노드의 kubelet이 pod 생성 관련하여 컨테이너로 전달

7. 컨테이너 런타임에서 컨테이너 생성

>>api-server는 상태값에 맞는 동작을 하는지 항상 감시

>>사용자는 kube-proxy를 통해 워커노드로 접근, kube-proxy가 워커노드 내에서 pods로 접근

다시 정리해보자면,

API server는 차트에 설명되어 있듯, 상태값을 "선언"만 하고, 실제 명령이나 동작을 내리진 않는다.

컨트롤러와 스케줄러, 그리고 워커노드의 kubelet이 지속적으로 api-server의 상태값을 확인, update된 상태가 있으면

자기가 할 일을 수행한다.

즉, api-server가 모든 통신에 개입하며, 통신의 중심이 되는 것이다(api-server의 상태값에 따라 움직이게 되므로)

api-server: 상태값 update 수행, etcd에 기록, 상태값에 따라 각 구성요소들이 움직이는지 '감시'만 할 뿐 명령 등의 동작 수행 없음
controller-manager: 현 상태와 api-server의 차이를 없애고 동기화 수행
scheduler: 실제로 배포한 pod가 노드에 잘 할당되었는지 상태값을 보고 수행

각 구성요소들은 api-server에 선언된 상태값을 "지속적으로 체크"하여, 상태값에 맞출 수 있도록 각자의 역할을 수행할 뿐이다.

>>중요한 개념임으로 반드시 이해하고 넘어가자!