Kubernetes Design Principle

Kubernetes Design Principle #1

✨ Kubernetes API는 세부적인 명령 대신에 원하는 것을 서술하는 식이다.

 

쿠버네티스 이전에는…?

나(Master) : 원하는 걸 위해서 정확한 명령을 제공했음

System(Worker) : 명령 수행

나(Master): system을 모니터링하고, 필요할 경우 추가 명령 제공

🔽

쿠버네티스는..!

나 : 원하는 걸 정의함

System: 내가 정의한 요구를 수행함

• 그러니까, 특선점심세트라는 메뉴를 개발하라고 하면, 어떤 주방장이 그걸 보고 개발하기 시작해.
• 처음에는 간단한 걸로 시작해도 거기에 계속 추가해서 복잡한 피쳐를 만들어낼 수 있다는 것이 쿠버네티스의 핵심 컨셉이다.

How to deploy a workload?

나 : Kube API 서버에 영구저장되며 삭제될 때까지 관리하는 API object를 생성

System : 모든 컴포넌트가 그 상태를 위해 일함

Automatic Recovery

➡️ 노드1이 죽더라도, 다른 노드에서 자동으로 pod를 옮겨감(그니까 pod가 죽지 않아)

Node는 자기가 뭘해야할지 어떻게 아는걸까?

➡️ Kubelet은 자신이 관리하는 노드에서 어떤 파드가 실행되어야 하는지, 또는 상태를 조정해야 하는지를 결정하고 실행한다. 그리고 스케쥴러가 node의 상태나 자원을 다 알고 있으니까 만약 노드가 죽으면 시간이 지나면 스케쥴러가 이를 눈치채게 되고, 다른 애한테 리스케줄링 한다!

Master가 뭘해야 하냐면…

➡️ 클러스터 내의 모든 컴포넌트(노드, 파드, 서비스 등)의 상태를 모니터링하고 저장해야 해. 모든 워커 노드에서 파드가 정상적으로 실행 중인지, 네트워크 설정이 잘 되어 있는지 등 전체 상태를 실시간으로 체크한다.

➡️ 클러스터 내의 어떤 컴포넌트가 실패하거나 통신에 문제가 생기면, 마스터 노드는 그 상태를 복구해주거나 조정해야 해. 예를 들어, 파드가 죽거나 네트워크에 장애가 발생했을 때, 마스터 노드는 이를 인지하고 그 컴포넌트를 다시 정상 상태로 되돌려야 해. 이 과정에서 마스터 노드는 “일시적으로 실패한 컴포넌트”가 다시 정상화되었을 때, 그 컴포넌트가 놓친 작업들을 복구하도록 처리해야 해. 예를 들어, 어떤 노드가 일시적으로 다운되었다가 다시 온라인이 되었을 때, 마스터 노드는 그 노드가 실행해야 할 작업을 “따라잡도록” 만들어야 해.

그래서 Master가 갖게되는 문제점은…

1. Complex(복잡해짐) : 클러스터 전체 상태를 모니터링하고, 모든 워커 노드와 상호작용해야 하기 때문에 시스템이 복잡해진다.
2. Fragile(취약해짐) : 클러스터의 모든 상태와 자원을 관리하는 중심이기 때문에, 마스터 노드에 장애가 발생하면 클러스터 전체에 문제가 발생할 수 있다.
3. 확장하기 어려워짐 : 다양한 역할을 수행해야 하므로, 새로운 기능이나 리소스를 추가할 때 확장하기 어렵다.

📌

 

1. Container crashes and dies? ➡️ 쿠버네티스가 컨테이너의 상태를 지속적으로 모니터링하고 있으니까, kubelet이 이를 인지하고 재시작시키거나 새 pod를 배포하여 복구시키려고 한다!
2. Node crashes and dies?
3. ➡️ 노드가 죽으면 마스터노드의 컨트롤러 매니저가 해당 노드가 비정상이라는 걸 알게되고, 해당 노드의 역할을 다른 멀쩡한 노드로 스케쥴링 한다.
4. node B is momentary not healthy?
5. ➡️ 쿠버네티스가 그 상태를 인지하고 작업을 보류하거나 재배치하고 회복되면 다시 일시켜.

 

Kubernetes Design Principle #2

 

Kubernetes API SERVER 뒷단에서 다시 Master가 대신 명령하지 않는다.

 

No hidden internal APIs

쿠버네티스 이전에는…?

나(Master) : 원하는 걸 위해서 정확한 명령을 제공했음

System(Worker): 명령 수행

나(Master): system을 모니터링하고, 필요할 경우 추가 명령 제공

🔽

쿠버네티스는..!

나 : 원하는 걸 정의함

System: 내가 정의한 요구를 수행하기 위해 독립적으로 일함

Declarative API의 장점

• 더 단순하고 견고한 시스템:Master 구성요소가 간단하므로 관리가 쉽고, 클러스터 상태가 자동으로 조정된다.
• 일부 컴포넌트가 실패하더라도 전체 시스템이 쉽게 복구 될 수 있다.(쿠버네티스의 여러 컴포넌트는 서로 독립적이고 병렬적으로 작동하니까!)
• 쿠버네티스의 유연성과 확장성:Extensible : 기본 제공되는 Kubernetes 컴포넌트가 충분하지 않다면, 사용자는 커스텀 컨트롤러나 오퍼레이터 같은 기능을 추가할 수 있어. 예를 들어, 특정 네트워크 플러그인이나 스토리지 솔루션을 사용할 수 있고, 기본 스케줄러가 아닌 사용자 정의 스케줄러를 만들어 사용할 수도 있어.
• Composable : 다양한 구성 요소들이 독립적으로 작동하며, 사용자에 따라 필요한 기능을 추가하거나 제거할 수 있어. 사용자는 필요한 컴포넌트만 사용하고, 추가 기능을 쉽게 붙일 수 있어.

Kube API DATA

kubernetes API는 다양한 데이터를 제공한다. 그중 몇가지 데이터 유형인 Secrets, ConfigMap, DownwardAPI를 살펴보자.

1. Secrets

• 민감한 정보를 저장하는 데 사용된다. 비밀번호, 인증서 API key 같은 데이터를 저장한다.
• Kubernetes API에서 관리하며, pod가 실행될 때 이 데이터를 안정하게 사용할 수 있도록 제공한다.

1. ConfigMap

• 애플리케이션 설정 정보를 저장하는데 사용된다. 애플리케이션이 시작할때 필요한 구성 파일이나 파라미터를 Kubernetes API에 저장해둔다.

1. DownwardAPI

• Pod의 메타데이터나 상태 정보를 애플리케이션 내부에서 사용할 수 있도록 제공한다.
• 현재 pod 이름, 네임스페이스 등이 해당한다.

근데 그렇다면, Kubernetes에서 API 데이터는 어떻게 가져오는 걸까??

이러한 위의 데이터들은 어플리케이션이 실행되는 동안 필요하고, Kubernetes API를 통해 제공된다. 그 방법은 바로 쿠버네티스는 숨겨진 내부 API가 없다는 특징을 이용하면 된다.

즉, 애플리케이션이 Kubernetes API를 통해 필요한 정보를 가져올 수 있도록 설계되어 있다. 애플리케이션을 수정해서 직접 Kubernetes API 서버에서 데이터를 가져오도록 만들면 된다.

하지만, 이 방법은 Legacy application에는 적합하지 않다. 레거시 애플리케이션은 구조적으로 kubernetes API에 접근하도록 설계되지 않았거나, 이를 수정하는 데 많은 비용이 들기 떄문이다.

➡️ Principle#3을 통해 해결

Kubernetes Design Principle #3

 ✨

기존 응용들을 수정없이 돌릴 수 있게 하자.

 

그니까 대충 설명을 해보자면, 기존 응용프로그램을 수정하지 않고도 kubernetes 에서 실행 가능하게 하자는 거다. 이렇게 해야 kubernetes를 도입하려는 회사나 개발자가 기존 시스템을 그대로 사용할 수 있잖아.

사용자가 있는 곳에서 시작하자

사용자가 이미 사용하는 환경이나 설정을 최대한 건드리지 않고도 kubernetes 환경으로 마이그레이션하거나 애플리케이션을 배포할 수 있게하자. 라는 뜻이다.

쿠버네티스 이전에는…?

애플리케이션이 kubernetes 환경에서 동작할 수 있도록 수정해야 한다. (개발자 눈물 닦는 소리 들린다..)

🔽

쿠버네티스는..!

애플리케이션이 Kubernetes API를 직접 알지 못하더라도 파일 시스템이나 환경 변수를 통해 설정 정보나 비밀 정보를 읽어올 수 있다면, 애플리케이션을 수정할 필요가 없다!!

(근데 그렇게 좋은 솔루션은 아닌게 만약 pod가 삭제되거나 종료되면 데이터가 날라가는 거다..)

Remote Storage

그래서 또 이에 대한 해결책이 바로 Remote Storage 되시겠다.

GCE PD, AWS EBS, NFS 등과 같은 다양한 원격 스토리지 솔루션을 지원하고, 이러한 스토리지를 pod에 직접 연결해서 사용한다.

Remote Storage는 물리적으로는 클러스터 외부에 있지만, 쿠버네티스를 통해 연결하여 데이터를 영구적으로 저장할 수 있다. 그래서 쿠버네티스는 pod가 remote storage를 사용할 수 있게 Mount 한다!

1. Storage Backend: 예시 그림에서 GCE PD를 사용하고 있다. 클러스터 외부에 있는 Remote Storage이다.
2. Master Node: API sever와 Scheduler가 있다.
3. Pod A: Node1에 배포된 파드이고, Storage: gcePD1에 따라 gcePD1이라는 Remote Storage를 사용하도록 설정되어 있다. 이건 YAML 파일에 명시되어 있다.
4. Kubelet: 각 노드에서 실행되며, 파드를 관리하고 API server와 상호작용한다. API sever로부터 새로운 pod를 실행하라는 명령을 받고, 해당 pod에 gcePD1 볼륨을 마운트해서 사용할 수 있게 처리한다.
5. Volume Mounting: kubelet은 gcePD1이라는 원격 스토리지를 pod에 마운트하는 작업을 담당한다.

• Storage Backend랑 gcePD1이랑 정확하게 무슨 차이?• Storage Backend는 클라우드 서비스 제공자가 제공하는 실제 물리적 스토리지 시스템을 의미해.• 이 스토리지 백엔드는 실제 스토리지 인프라로, 데이터가 물리적으로 저장되는 공간이야.2. gcePD1 (Pod에서 사용되는 볼륨, 왼쪽 텍스트에서 설명된 GCE PD):• 이 볼륨은 Storage Backend의 실제 스토리지 자원을 Kubernetes에서 사용할 수 있게 만든 추상화된 개념이야.• 예를 들어, 특정 Pod가 데이터베이스 애플리케이션을 구동할 때, 이 gcePD1이라는 볼륨을 통해 데이터베이스 파일을 저장하게 되는 거야.
• • Kubernetes는 이런 식으로 Storage Backend에서 물리적인 스토리지를 가져와서 **Pod에서 직접 사용할 수 있는 논리적인 볼륨(gcePD1)**을 생성해.
• • gcePD1은 Pod에 연결된 특정 볼륨이야. 이 볼륨은 Kubernetes에서 사용하기 위해 Storage Backend(GCE PD)에서 할당된 블록 스토리지를 가리켜.
• • 클라우드 서비스 제공자는 이 물리적 스토리지를 관리하고, 사용자는 이를 추상화된 형태로 접근해 데이터를 저장할 수 있어.
• • 예를 들어, Google Cloud Platform(GCP)의 **Google Cloud Persistent Disk (GCE PD)**나 Amazon Web Services(AWS)의 **Elastic Block Store (EBS)**와 같은 클라우드 스토리지 서비스가 여기에 해당해.
• 1. Storage Backend (왼쪽 상단의 Storage Backend 구름 아이콘):

Kubernetes Design Principle #4

 ✨

PoD의 이식성을 강화한다.(스토리지 측면에서도)

 

이건 애플리케이션이 어디서든 동일하게 동작할 수 있는 능력을 의미한다.

PVC/PV

• PV는 쿠버네티스에서 제공하는 영구 스토리지 리소스이다. 클러스터의 관리자에 의해 설정되며 노드와 독립적으로 존재한다.
• PVC는 pod가 스토리지 리소스를 요청하는 방식이다. pod가 직접 스토리지의 세부 사항을 알 필요 없이 pvc를 통해 필요한 스토리지 요구사항을 선언하면 된다

➡️ PVC와 PV는 추상화 계층을 제공하여, 스토리지의 세부 사항을 pod와 분리함으로써 pod의 이식성을 강화한다.

Kubernetes Principles Summary

그래서 Kubernetes Principle을 다시 정리해보자!

1. Kubernetes API는 명령형 방식보다 선언형 방식
   • 자동으로 시스템을 관리하며, 더 높은 자동화와 일관성 제공
2. 내부 API가 숨겨져 있지 않음
   • 투명한 API 접근을 통해 클러스터 상태와 자원 관리가 용이해짐
3. 사용자가 기존에 사용하던 방식을 최대한 변경하지 않고 Kubernetes를 사용할 수 있다.(Remote Storage를 통해)
   • 사용자가 있는 곳에서 만나자.
4. Workload 이식성을 높임
   • PV와 PVC를 통해 스토리지와 애플리케이션을 분리하여 다양한 환경에서 애플리케이션이 유연하게 배포되는 것을 보장 Kubernetes API는 세부적인 명령 대신에 원하는 것을 서술하는 식이다.