MLOps Engineer와 함께 쿠버네티스(Kubernetes) 구조 살펴보기

반응형

Kubernetes 구조를 간단하게 살펴보려고합니다.
제가 아는 선에서 최대한 쉽게 글을 써볼게요~

 

Kubernetes 구조

먼저 Kubernetes 공식 페이지에 소개된 구성도부터 살펴봅시다.
뭐가... 많아보이죠? 그런데 Kubernetes의 목적을 이루기 위한 최소한의 요소들이라고 생각해요.

쿠버네티스 구성도

 

Control Plan

클러스터를 전체적으로 관리하기 위한 요소들이 모여있습니다. 
중앙 관제탑이라고 보시면 됩니다. 여기서는 클러스터 내 노드와 애플리케이션들을 관리하기 위한 컴포넌트들이 유기적으로 동작합니다.

 

API Server

동작을 위해서는 Kubernetes에 호출이 필요하겠죠? 이러한 동작을 관리하는 컴포넌트입니다.
외부 호출 뿐만 아니라, Kubernetes는 모든 호출들은 api로 관리합니다. 

예를 들어 Pod를 생성하라는 외부 호출을 받아서 노드로 전달하고, 생성의 성공 여부를 받는 것 모두가 api로 통신됩니다.

 

ETCD

클러스터의 모든 데이터를 저장하는 Key-Value 스토어 입니다.

위 상황에서 Pod가 어디에 생성되었는지 Pod의 상태가 어떻게 되는지 저장하는 곳이 필요합니다. 
이를 ETCD에서 관리하게 됩니다.

만약 ETCD의 데이터가 사라진다면.. Kubernetes 리소스들이 어디서 어떤 상태인지 알 수가 없게 됩니다. (한 마디로 노답..)
따라서 ETCD 데이터를 주기적으로 백업해주는 것이 Kubernetes에서는 권장됩니다.

 

Scheduler

Kubernetes의 중요한 기능 중 하나는 자원 관리입니다. 
Pod를 적절한 곳에 적절하게 생성하는 것이 중요하기 때문에 Scheduler라는 컴포넌트가 존재합니다.

Kubernetes는 ETCD를 통해서 현황을 파악하고, 적절한 노드에 자원을 생성합니다.

또한 만약에 Pod를 띄울 적절한 노드가 없다면 이를 보관하는 큐(Queue) 역할을 하게 됩니다.
이를 통해서 명령들이 소실되지 않도록 합니다. 

 

Controller manager

이 친구의 역할이 꽤나 많습니다.
Kubernetes의 상태를 정상적으로 하는 데에 역할을 가지고 있는데, 사람이 더우면 땀을 흘리고, 추우면 몸을 떨 듯이 항상성을 유지하도록 돕습니다.

1. 상태 관리 및 자동화된 복구

Controller에서는 ETCD를 지속적으로 모니터링하면서 클러스터의 현재 상태를 확인합니다.
사용자가 원하는 상태가 있다면 이를 유지하도록 조정하고, 이 과정을 Reconciliation이라고 합니다.

ReplicaSet Controller는 지정된 수의 파드가 항상 실행되도록 보장하게 되는데,
Desired Pod 개수가 3인데, 환경적 요인으로 Pod가 몇 개 죽게되더라도 Controller는 이를 감지하고 Pod를 자동으로 생성하게 됩니다.

2. 스케일링

애플리케이션의 부하에 따라서 Pod의 수를 조절할 수 있습니다.
이는 Deployment Controller를 통해서 스케일 업/다운을 수행할 수 있습니다.

3. 롤링 업데이트

Deployment 컨트롤러는 애플리케이션의 새 버전을 무중단으로 배포할 수 있는 롤링 업데이트 기능을 제공합니다
서비스 중인 애플리케이션을 업데이트 시에, 기존 애플리케이션으로 오던 트래픽을 다음 버전의 애플리케이션으로 자연스럽게 흘러보낼 수 있습니다.

 

Worker Node

이름에서 느낄 수 있듯이 성실한 일꾼들입니다.
자신이 가진 자원(CPU,MEM,GPU)을 통해서 Pod를 띄우는 역할을 합니다.

 

Kubelet

클러스터의 모든 노드에서 실행되는 에이전트입니다.
ControlPlane에서 원하는 자원 스펙을 여기로 전달하고, 그에 따라 Pod를 실행합니다.

Kubelet은 Pod 실행 뿐만 아니라, 모니터링도 진행합니다.
노드의 상태 및 리소스 현황을 모니터링하고, 관리하고 이러한 상태를 API 서버에 보고합니다.
그리고 Pod의 상태에 대한 이벤트를 감지하고 그에 따라 필요한 작업들을 수행해줍니다.

또한 볼륨마운트를 진행하는데요.
볼륨은 보통 클러스터 단위로 구성되어 있습니다. Kubelet은 이러한 볼륨이 Pod에 연결될 필요가 있다면 관련된 작업들을 수행합니다.

 

Kube-Proxy

네트워크 프록시로, 쿠버네티스의 네트워크 서비스를 구현합니다.

이게 무슨말이냐면... 원래는 사용자가 애플리케이션에 접근하기 위해서는 실제 애플리케이션이 존재하는 Pod에 접근해야하는데요.
사용자는 실제 Pod IP가 아닌 Kubernetes에 연결된 외부 IP를 통해서 접근하게 됩니다.
Kubernetes에서는 Service 리소스를 통해서 이러한 연결을 관리하게 되고, 이를 통해서 원하는 Pod에 접근할 수 있도록 돕습니다.

서버와 클라이언트 사이의 대리인이라는 말을 쓰기도 하는데, 실제로는 클라이언트가 원하는 서버에 직접 접근을 하지 않아도 대리인의 역할로 원하는 서버에 접근할 수 있도록 해준다는 뜻입니다.

조금 헷갈릴 수도 있는데.. (네트워크가 가장 어려운 거 같아요 ㅠㅠ) 나중에 Service를 다룰 때 다시 정리해보도록 하겠습니다. 

 

 

정리

결국 Kubernetes는 Node를 잘 관리하고 싶고, 그 안에 있는 애플리케이션들을 Reconcile하게 잘 관리하고 싶어서 만들어진 것입니다.
클러스터 내부에 존재하는 노드들이 하나의 시스템처럼 동작하기를 바라는 거죠.

물론 위에 언급한 기능들에 더 해서 Kubernetes는 더 다양한 기능들을 제공합니다.
아직도 발전이 끊이없이 이루어지고 있고요. 

위 글을 읽으시면서 Kubernetes에 대해서 좀 더 이해할 수 있는 계기가 되었으면 좋겠습니다. 🙆‍♂️