쿠버네티스 핵심 구성 요소 한 번에 정리하기 (Pod, Node, Cluster)

지난 글에서는 쿠버네티스가 왜 등장했고 어떤 문제를 해결하려는지를 중심으로 살펴봤다.
이번 글에서는 쿠버네티스를 이해하기 위해 반드시 넘어야 하는 핵심 구성 요소들을 정리한다.

처음 쿠버네티스를 접하면 용어가 많아서 막막해지기 쉽다.
하지만 구조를 단순하게 보면, 생각보다 복잡하지는 않다.
이 글은 개념을 한 번에 정리하고 싶은 사람에게 도움이 되도록 구성했다.

쿠버네티스 구성 요소를 바라보는 관점

쿠버네티스를 이해할 때 가장 좋은 방법은 다음 질문에서 출발하는 것이다.

이 질문에 답하다 보면 자연스럽게 주요 구성 요소가 정리된다.

쿠버네티스에서 컨테이너를 직접 다루지는 않는다.
대신 Pod라는 단위를 사용한다.

Pod는 하나 이상의 컨테이너를 감싸는 최소 실행 단위다.

[이미지: Pod와 컨테이너 관계 구조 설명]

실제로 사용해보면 Pod를 “서버처럼 오래 유지되는 객체”로 생각하면 곤란하다.
장애가 나거나 재배포가 발생하면 Pod는 쉽게 교체된다.

그래서 쿠버네티스에서는
“이 Pod를 계속 살려라”가 아니라
“이 상태를 유지하라”는 식으로 접근한다.

Pod는 혼자 떠 있는 것이 아니다.
반드시 Node 위에서 실행된다.

Node는 보통 다음 중 하나다.

[이미지: Node 위에서 여러 Pod가 실행되는 구조]

개발자가 Node를 직접 만질 일은 많지 않다.
하지만 리소스 부족, 장애 상황에서는
“이 문제가 Pod 문제인지, Node 문제인지”를 구분하는 것이 중요해진다.

Cluster는 여러 Node를 하나로 묶은 논리적인 단위다.

[이미지: Cluster → Node → Pod 계층 구조]

실제로 쿠버네티스를 쓸 때는
“이 서버에 배포한다”기보다는
“이 Cluster에 배포한다”는 표현이 더 자연스럽다.

지금까지 설명한 Pod와 Node는
“실제로 컨테이너가 실행되는 영역”이다.

반면, Control Plane은 전체를 관리하는 쪽이다.

[이미지: Control Plane과 Worker Node 역할 분리 구조]

중요한 점은,
개발자가 kubectl 같은 도구로 명령을 내리면
항상 Control Plane을 통해서 전달된다는 것이다.

이 구조를 이해하면, 이후에 나오는 개념들이 훨씬 수월해진다.

예를 들어,

이 모든 것이
Pod / Node / Cluster / Control Plane 역할 분리에서 나온다.

실제로 써보면,
처음에는 추상적으로 느껴지던 구조가
장애 상황이나 배포 시점에서 의미를 갖기 시작한다.

이번 글에서는 쿠버네티스의 핵심 구성 요소를
최소한의 단위부터 큰 구조까지 순서대로 정리했다.

다음 글에서는
이 구성 요소 위에서 실제로 가장 많이 쓰이는 개념인
Deployment와 ReplicaSet을 중심으로
“쿠버네티스에서 배포는 어떻게 이루어지는지”를 살펴볼 예정이다.