[CKA] 쿠버네티스 클러스터 개념

게시 2025/02/25

9 분읽는 시간

[CKA] 쿠버네티스 클러스터 개념

Kubernetes 클러스터 핵심 개념

Master와 Worker Node

쿠버네티스 아키텍쳐

Master Node

Master는 kube-api, kube-scheduler(pod를 관찰하며 pod가 할당되기 좋은 노드를 결정), ETCD 클러스터와 컨트롤러로 이루어진다.

Worker Node

Docker로 만들어지며 이를 관리하는 kubelet 이는 kebe-api와 지속적으로 통신한다.

실질적으로 Node를 관리하며 pod의 생성과 모니터링을 담당

ETCD

분산되고 신용될 수 있는 클러스터를 위한 Key-Value 저장소

etcd의 위치

쿠버네티스 클러스터에는 노드의 상태, pod의 정보가 영속적으로 관리 되어질 필요가 있다.

이를 위해 ETCD는 쿠버네티스의 모든 운영 정보가 들어가 있으며, master-node에 etcd pod 이라는 static형태로 존재한다.

주로 kube-api Server와 상호작용하며 요청이 들어올 경우 변경사항을 검증하고 ETCD에 저장한다.

또한 kube-controller-manager와 kube-scheduler 같은 서비스도 ETCD의 데이터를 기반으로 동작한다.

고가용성(HA)의 환경에서 여러개의 Master Node가 구성되어 있을 경우 ETCD도 다중 노드로 구성되어진다.

단, 별도의 ETCD 전용 노드를 사용해 독립적인 운영도 가능하다. 결과적으로 ETCD의 목적을 위한 데이터 정합성 유지가 핵심

ETCD가 저장하고 있는 데이터는 Node, Pod, Configs, Secrets, Roles 등이 있다.

kube-api

클러스터의 모든 오브젝트와 통신하며 Master Node ↔ 사용자를 소통하는 REST API

kube-api는 클러스터의 중앙 제어 역할을 하는 컴포넌트로 인증, API Layer, 요청 검증등을 담당한다.

또한 ETCD 클러스터와 직접 통신하는 오브젝트

Master Node에서 동작하는 주요 관리 컴포턴트로 우리가 일반적으로 사용하는 kubectl 명령을 담당한다. input 하여 검증한 뒤 ETCD 클러스터로부터 데이터를 받아 POST 해준다.

kubectl get nodes의 처리 방식

만약 사용자가 pod를 생성 요청한다면 아래와 같은 순서를 거친다.

요청을 한 유저를 인증
요청 검증
pod 생성 과정에 필요한 데이터를 조회 (Namespace나 RBAC)
ETCD에 pod 생성한 사용자 기록
Sceduler에게 node가 할당되지 않은 pod이 있다는 것을 알려 적절한 node를 고르게 함
kubelet을 통해 pod를 생성, 그리고 kube-api에게 정보를 업데이트

pod를 생성하는 처리 방식

kube controller manager

k8s에서 여러 컨트롤러 프로세스를 관리하는 컴포넌트

k8s는 여러 컨트롤러를 통해서 ETCD를 비롯한 k8s 리소스들의 상태를 확인 리소스 관리를 통해 원하는 상태(desired state)를 유지한다.

Node Controller

AP가 정상적으로 수행될 수 있도록 Node 상태를 모니터링 하고 조치가 필요하다면 kube-api를 통해 수행 할 수 있도록 한다.

5초마다 Node의 상태를 테스트한다.
Node가 접근 할 수 없으면 40초간 기다린다.
접근 할 수 없음을 표시하고 5분간의 회복을 기다린다.

Replication Controller

Replica Set의 상태를 모니터링하고 정해진 pod의 개수를 보장한다.

more controller…

이외에도 K8s에는 다양한 컨트롤러가 존재한다. 특정 시간 간격마다 반복 실행되는 job(배치)을 관리하는 CronJob 같은…

그렇기에 Controller는 쿠버네티스의 두뇌 역할을 한다고 알려져있다.

kube-scheduler

어떤 pod이 어떤 Node로 가야하는가

Node가 할당되지 않은 pod이 존재할 때, 해당 pod이 어떤 Node로 가야하는지에 대해 결정만 한다.

실제 작업은 kubelet이 수행한다.

예를 들어 Cpu:10이라는 요구사항에 있어 맞지 않은 노드를 필터링 하고 가능한 노드 가운데 우선순위를 결정한다. 이때 사용되는 우선 순위는 커스텀이 가능하다.

kubelet

각 Node의 핵심 컴포넌트로 kube-api와 통신하며 pod을 관리

kubelet은 pod을 관리하며 kube-api에 Node와 pod의 상태를 보고한다. 또한 Volume과 Network를 설정하고 관리한다.

이런 좋은 kubelet은 자동으로 Node에 배포되지 않으며, 반드시 수동으로 kubelet을 설치해줘야한다!

Kube Proxy

Node에서 실행하는 Service와 Pod의 네트워크를 관리하는 Proxy*

주로 iptables 를 사용해 트래픽을 관리하며 Service 기반 네트워크 규칙으로 올바르게 트래픽을 pod에게 전달한다.

이는 마치 Interface의 역할과도 같아 Node나 다른 Pod으로 교체되어져도 같은 방식으로 통신을 가능하게 한다.

Pod란?

pod의 일반적인 구성

하나의 Node에는 n개 이상의 pod이 존재한다. 이러한 pod안에는 사용자가 만든 AP Container와 Helper Conatiner라고 불린 두개의 Container가 존재한다. (AP Container가 죽으면 같이 죽는다.)

이러한 pod라는 개념을 통해 Node안에 여러 개의 AP Container를 운용할 때, 큰 도움을 주는데…

만약 Pod라는 개념이 없다면? pod라는 개념이 없는 세계

사용자는 컨테이너에 n개의 AP Container를 가진다면 n개의 helper container를 가져야한다. 여기에 만약 volume을 사용한다면 n개의 volume까지… 운영자 입장에서는 이를 관리하기 위해 별도의 테이블을 만들어 AP Container가 죽는다면 그에 종속된 모든 리소스들을 관리해줘야한다. -> 피로도 증가.

이를 pod라는 하나의 단위로 묶음으로써 관리를 용이하게 한다. (Pod의 출현 배경)

pod를 생성하는법

yaml 을 통해 k8s를 배포하는데 있어 root 레벨 속성들은 apiVersion , kind, metadata , spec 으로 이루어진다.

pod-definition.yml 을 사용해 pod를 배포하기

  
apiVersion: v1 # version
kind: Pod # 어떤 형태를 배포할건지..?
metadata: # 이 pod의 데이터는?
	name : myapp-pod
	labels: # dic 형태
		app: myapp
		type: front-end

spec:
	containers: #List 형태
		- name: nginx-container
			image: nginx

그리고 kubectl creage -f pod-definition.yml를 실행한다.

k8s, CKA