[K8S] 쿠버네티스 Core Concept - 아키텍처, Pod

쿠버네티스 공식문서, 유튜브 따배님 강의, Udemy CKA with Practice Tests 강좌 참고

https://kubernetes.io/ko/docs/

 

---

Kubernetes Architecture

쿠버네티스 클러스터 구성

출처 : 쿠버네티스 공식 문서, https://kubernetes.io/ko/docs/concepts/overview/components/

쿠버네티스 클러스터는 컨트롤 플레인 컴포넌트(Master Node), 노드 컴포넌트(Worker Node)로 구성됨.

워커 노드는 애플리케이션의 구성요소인 파드를 호스트, 컨트롤 플레인은 워커 노드와 클러스터 내 파드를 관리한다.

프로덕션 환경에서는 일반적으로 컨트롤 플레인이 여러 컴퓨터에 걸쳐 실행되고, 클러스터는 일반적으로 여러 노드를 실행하므로 내결함성과 고가용성이 제공된다.

 

Control Plane

컨트롤 플레인 컴포넌트는 클러스터에 관한 전반적인 결정(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, deployment의 replicas 필드에 대한 요구 조건이 충족되지 않을 경우 새로운 Pod를 구동시키는 것)를 감지하고 반응

 

kube-apiserver (쿠버네티스 API 서버)

API 서버는 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트

응용 프로그램을 컨테이너 형식으로 호스트. 자동화된 방식

 

**API : 소프트웨어끼리 소통할 수 있는 약속된 인터페이스

(어떻게 요청하면, 어떤 형식으로 응답해줄게라는 형식)

 

쿠버네티스는 다양한 API를 가지고 있다.

Kubernetes API (Control Plane API)	쿠버네티스 리소스를 생성/조회/수정/삭제할 때 사용하는 중앙 제어 인터페이스
API 리소스	Pod, Service, Deployment 등
REST API, 애플리케이션 API	HTTP/REST 기반의 API 제공

 

 

ETCD

모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소

 

쿠버네티스 핵심 구조

사용자(kubectl) ──> [API Server] ──> etcd (데이터 저장)
                              └─> Controller, Scheduler 등으로 명령 전달

 

kube-controller-manager, cloud-controller-manager

kube-controller-manager : 컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트

cloud-controller-manager : 클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트

 

 

 

Node Component

노드 컴포넌트는 동작 중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공하며, 모든 노드 상에서 동작

 

Kubelet

클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리

 

kube-proxy

kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 서비스 개념의 구현부이다.

kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.

 

컨테이너 런타임

컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어

 

 

---

Pod

Pod란?

컨테이너 하나는 애플리케이션 하나라고 생각할 수 있다. 도커에서는 도커 허브에 있는 image를 실행시키는데, 그럼 쿠버네티스에서는 컨테이너가 어떤 식으로 실행될까? => Pod 형태로 컨테이너를 실행

 

Pod = 컨테이너를 표현하는 K8S API의 최소 단위

 

API에서 컨테이너 동작은 불가능하므로 Pod라는 API를 통해 컨테이너를 실행하는 것이다. Pod가 쿠버네티스에서 실행되는 최소 단위로 이해하자.

한개의 Pod 안에는 한개 이상의 컨테이너가 포함될 수 있다. 책임과 관리를 위해 보통 하나의 Pod에 하나의 컨테이너를 배치하는 경우가 많지만 로그수집이나, 외부에서 만들어진 컨테이너 간의 유기적인 관계 유지 등을 이유로 2개 이상의 컨테이너를 배치하기도 한다.

**참고로 ip는 파드 당 하나만 할당됨

 

 

Pod 생성하기

1. CLI

kubectl run webserver --image-nginx

 

2. YAML

yaml 파일 안 kind에 pod를 명시하고 생성하기

** yaml 파일은 들여쓰기를 정확히 맞춰야 함. 여기서 오류가 생기면 생성 불가능하다.

 

 

Pod의 동작 Flow

kubectl

 

 

Pod에 리소스 할당하기

여기서 말하는 리소스란 CPU, 메모리 등을 얘기함.

 

컨트롤 플레인의 컨트롤러가 파드를 워커 노드에 배치할 때 어떻게 해야할까? 무조건 실행중인 파드가 작은 곳에 배치해줘야 할 지, 아니면 전체 리소스가 많이 남은 곳에 배치해야할 지 고민이 있을 것이다.

 

그래서 쿠버네티스에서는 파드를 실행할 때 requests와 limits를 설정하여 컨테이너가 사용할 리소스를 제어할 수 있다.

 

Resource Requests : 파드를 실행하기 위한 최소 리소스 양을 요청

requests는 파드가 스케줄러에게 요청하는 최소한의 리소스를 의미하며, 스케줄러는 이 값을 기준으로 CPU 및 메모리 여유가 있는 노드에 파드를 배치한다. 예를 들어, CPU는 최소 6500m을 요청하고, 메모리는 현재 여유가 있는 만큼만 요청하도록 설정할 수 있다.

(Pod가 요청하는 것. 나 이정도는 보장해줘)

 

Resource Limits : 파드가 사용할 수 있는 최대 리소스 양을 제한, Memory Limit을 초과해서 사용되는 파드는 종료되며 다시 스케줄링 

limits는 해당 컨테이너가 사용할 수 있는 최대 리소스 양을 의미하며, 이를 초과할 경우 리소스 사용이 제한되거나 컨테이너가 종료될 수 있다. 이와 같은 설정을 통해 리소스를 효율적으로 관리하고, 노드 간 부하를 분산시킬 수 있다.

만약에 이 limit을 넘어가면 restart ➡️ 너무 타이트하게 limit을 걸면 안되겠지

 

 

컨테이너 및 Pod에 CPU 리소스 할당 관련 공식 문서 내용

https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/