NKS로 쿠버네티스 이해하기 - 2

앞서 쿠버네티스의 전반적인 구조—클러스터, 노드, Pod—를 통해 전체 흐름을 이해해봤다. 이제는 그 구조 안에서 실제로 누가 어떤 역할을 담당하는가?, 즉 이 구성 요소들을 어떻게 다루는가?에 대해 정리해보자.

1. 쿠버네티스 클러스터

Pod는 누가 배치하는가?

쿠버네티스에서는 클러스터 환경 안에서 Pod가 노드에 배치된다고 했다. 그렇다면 이 배치 작업은 누가 담당하는가? 에 대한 질문이 생긴다. 이 역할을 담당하는 주체가 바로 컨트롤 플레인(Control Plane)이다.

 

컨트롤 플레인 vs 워커 노드

쿠버네티스 클러스터는 크게 두 가지 종류의 노드로 구성된다.

 

구성 요소	역할
컨트롤 플레인 노드	클러스터 전체를 관리하고 제어함. Pod 배치, 상태 확인, 스케줄링 등 수행
워커 노드	실제 Pod가 배치되어 실행되는 공간, 컨테이너가 돌아가는 물리/가상 서버

 

Pod를 생성하라고 지시하는 건 컨트롤 플레인, 그리고 그 지시를 받아 실제 실행하는 건 워커 노드다.

 

컨트롤 플레인은 어떤 구성 요소로 동작할까?

컨트롤 플레인은 단일한 프로그램이 아니라, 다음과 같은 핵심 구성 요소들이 협력하여 동작한다.

 

kube-apiserver	쿠버네티스의 입구, 모든 요청은 여기로 옴
kube-scheduler	어떤 노드에 Pod를 배치할지 결정
kube-controller-manager	클러스터 상태 유지, 복제/복구 관리
etcd	클러스터 상태를 저장하는 키-값 저장소 (쿠버네티스의 DB 역할)

 

 

이러한 구성 요소들이 함께 동작하며, 클러스터의 전체 상태를 파악하고, 어떤 Pod를 어디에 배치할지를 결정하는 것이 컨트롤 플레인의 핵심 역할이다. 여기서 중요한 점은, 컨트롤 플레인은 하나의 노드 위에서 동작하는 구조라는 것이다. 위의 각 컴포넌트들은 모두 하나의 노드(컨트롤 플레인 노드) 안에서 Pod 형태로 실행되며, 이들이 함께 클러스터 전체를 제어한다.

결국 이처럼 여러 관리용 Pod들이 모여 클러스터를 제어하는 노드를 '컨트롤 플레인'이라고 부르는 것이며, 쿠버네티스의 관리 구조조차도 Pod와 Node라는 동일한 구조 안에서 운영된다는 점이 흥미롭다.

---

2. 쿠버네티스 객체

파드(Pod)

앞에서 쿠버네티스 전체 흐름을 파악하면서 자주 나온 단어인 Pod(파드)에 대해 알아보자!기존에 알고 있던 것처럼, Pod는 단순히 하나 이상의 컨테이너를 감싸는 단위라고 이해하면 된다.

 

실제로는 대부분의 경우 하나의 컨테이너만 포함된 Pod를 사용하지만, 간혹 서로 밀접하게 연관된 기능을 수행하는 컨테이너들을 함께 묶어 하나의 Pod로 구성하는 경우도 있다. 예를 들어, 주 애플리케이션 컨테이너와 로그 수집 사이드카 컨테이너가 같은 Pod 안에 존재할 수 있다.

 

Pod는 쿠버네티스에서 '스케줄링 단위'

Pod를 하나의 악보, 즉 “어떻게 일할지에 대한 계획서”라고 본다면, 컨트롤 플레인(지휘자)는 이 악보(Pod)를 어느 연주자(노드)에 맡길지 결정한다.

즉, Pod 단위로 어떤 노드에 배치할지(Kubernetes가 결정) 한다는 것이다.

결과적으로 쿠버네티스는 개별 컨테이너가 아니라, Pod라는 단위 전체를 기준으로 작업을 스케줄링하고 실행 환경에 배치한다. 이 점이 쿠버네티스 아키텍처에서 중요한 개념이다.

 

Pod는 그냥 그룹화!

Pod는 사실 어떤 특별한 기술이 들어간 복잡한 구조라기보다는, 그저 컨테이너들을 묶어놓은 논리적인 그룹이라고 이해하면 된다. 쉽게 말해, "그룹화"의 개념에 가깝다.

Pod 안에 있는 컨테이너들은 항상 함께 생성되고, 함께 종료된다. 또한 네트워크, 저장소 등 대부분의 리소스를 공유한다. 예를 들어, 같은 Pod에 있는 컨테이너들은 같은 localhost(127.0.0.1) 환경을 공유하고, 공통된 볼륨에 접근할 수도 있다.

즉, Pod는 여러 컨테이너를 하나의 실행 단위로 묶는 껍데기 역할일 뿐이며, 그 자체가 무슨 고급 기술이라기보다는, 컨테이너들을 효율적으로 관리하기 위한 논리적 단위로 보면 된다.

---

디플로이먼트(Deployment)

파드를 묶음으로 쉽게 관리할 수 있는 기술이 있다.

예를 들어, 서버에 요청이 많아져서 서버를 확장해야 하는 상황이 생겼다고 해보자. 이럴 때마다 파드를 하나하나 복사해서 붙여넣는 방식으로 늘리는 건 비효율적이다. 한두 개는 그렇다 쳐도, 실제 대규모 서비스에서는 수백 개의 파드를 운영하는 경우도 있기 때문에 매번 복사해서 배포하는 건 사실상 불가능하다.

그래서 여러 개의 파드를 효율적으로 관리할 수 있는 장치가 바로 디플로이먼트(Deployment)다.

실제 현업에서는 서버를 작동시킬 때 파드를 수동으로 배포하지 않고, 대부분 디플로이먼트를 통해 자동으로 관리한다.

---

서비스(Service)

디플로이먼트를 사용하면 서버를 수평적으로 확장할 수 있다. 하지만 단순히 서버(파드)를 늘리기만 해서는 소용이 없다. 외부에서 들어오는 트래픽을 적절히 분배해줘야 수평 확장의 효과를 제대로 볼 수 있기 때문이다.

이때 트래픽을 받아서 여러 파드로 분산시켜주는 역할을 하는 것이 바로 서비스(Service)다.

서비스는 사용자의 요청도 받고, 일종의 로드밸런서 역할을 한다.

실제 서비스 환경에서는 파드에 직접 포트 포워딩을 하거나 파드 내부로 접근해서 요청을 보내지 않는다.

보통은 서비스를 통해 파드에 요청을 전달한다.