쿠버네티스 파드(Pod)와 노드(Node)의 핵심 차이점 이해하기

쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하는 업계 표준 플랫폼입니다. 모든 쿠버네티스 클러스터 아키텍처의 핵심에는 두 가지 기본적이지만 종종 혼동되는 개념, 즉 파드(Pod)와 노드(Node)가 있습니다. 이러한 구성 요소 간의 차이점을 파악하는 것은 효과적인 클러스터 설계, 문제 해결 및 최적화에 매우 중요합니다.

이 글에서는 파드와 노드의 아키텍처 역할을 명확하게 구분하고, 각 구성 요소가 무엇을 나타내는지, 서로 어떻게 관련되는지, 그리고 클러스터 환경 내에서 애플리케이션이 안정적이고 효율적으로 실행되도록 어떻게 협력하는지 살펴보겠습니다.

쿠버네티스 클러스터 아키텍처 개요

쿠버네티스 클러스터는 함께 작동하는 여러 머신(물리적 또는 가상)으로 구성됩니다. 이러한 머신은 컨트롤 플레인(클러스터 상태를 관리하는 두뇌)과 워커 노드(실제 워크로드를 실행하는 근육)로 크게 분류됩니다. 파드와 노드는 이 구조 내에서 상호 작용합니다.

노드: 컴퓨팅 리소스를 제공하는 물리적 또는 가상 머신입니다.
파드: 하나 이상의 컨테이너를 호스팅하는 가장 작은 배포 가능한 단위입니다.

노드가 파드를 호스팅하고, 파드가 컨테이너를 호스팅한다는 이 계층 구조를 이해하는 것이 쿠버네티스 숙달의 시작점입니다.

쿠버네티스 노드: 컴퓨팅 파워의 기반

쿠버네티스 노드(때로는 워커 머신이라고도 함)는 애플리케이션을 실행하는 데 필요한 컴퓨팅 리소스(CPU, RAM, 네트워크)를 제공하는 머신입니다. 클러스터에는 최소한 하나의 노드가 있어야 하지만, 프로덕션 환경에서는 일반적으로 중복성과 확장성을 위해 여러 노드를 사용합니다.

노드의 주요 책임

각 노드는 컨트롤 플레인과 통신하고 애플리케이션 워크로드를 호스팅할 수 있도록 하는 필수 구성 요소를 실행합니다.

Kubelet: 컨트롤 플레인과 통신하는 모든 노드에서 실행되는 에이전트입니다. PodSpecs에 설명된 컨테이너가 해당 노드에서 실행 중이고 정상 상태인지 확인합니다.
컨테이너 런타임: 이미지를 가져와 컨테이너를 실행하는 소프트웨어입니다(예: Docker, containerd, CRI-O).
Kube-proxy: 노드에서 네트워크 규칙을 유지 관리하여 내부 및 외부에서 파드와의 통신을 가능하게 합니다.

실제 예시: 노드 표현

클러스터에서 노드를 검사할 때 쿠버네티스가 사용하고 있는 기본 인프라를 볼 수 있습니다.

kubectl get nodes

NAME           STATUS   ROLES    AGE     VERSION
worker-node-01 Ready    <none>   2d1h    v1.27.4
worker-node-02 Ready    <none>   2d1h    v1.27.4

핵심 요점: 노드는 실행이 발생하는 하드웨어/VM 계층입니다.

쿠버네티스 파드: 가장 작은 배포 가능한 단위

파드(Pod)는 쿠버네티스에서 원자적인 배포 단위입니다. 자체적으로 컨테이너가 아니라, 동일한 노드에 함께 배치되고 리소스를 공유하도록 보장되는 하나 이상의 컨테이너를 감싸는 래퍼입니다.

직접 컨테이너 대신 파드를 사용하는 이유?

쿠버네티스가 개별 컨테이너가 아닌 파드를 관리하는 데는 몇 가지 중요한 이유가 있습니다.

공유 컨텍스트: 단일 파드 내의 모든 컨테이너는 동일한 네트워크 네임스페이스(IP 주소 및 포트 범위)를 공유하며 localhost를 통해 쉽게 통신할 수 있습니다.
공유 스토리지: 동일한 파드의 컨테이너는 동일한 마운트된 스토리지 볼륨에 액세스할 수 있습니다.
수명 주기 관리: 쿠버네티스는 파드를 단일 엔티티로 취급합니다. 파드 내의 컨테이너가 실패하면 쿠버네티스는 전체 파드 구조의 다시 시작 또는 재생성을 처리합니다.

파드의 구조

대부분의 경우 파드에는 단일 기본 애플리케이션 컨테이너가 포함됩니다. 그러나 보조 컨테이너가 기본 컨테이너를 지원하는 사이드카 패턴(예: 로깅 에이전트, 서비스 메시 프록시)에 자주 사용됩니다.

예시 파드 정의 (간소화된 YAML)

다음 YAML은 단일 Nginx 컨테이너를 감싸는 파드를 정의합니다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80

핵심 요점: 파드는 애플리케이션 컨테이너의 논리적 호스트이며 노드에 스케줄링되는 단위입니다.

핵심 관계: 스케줄링 및 배치

파드와 노드 간의 기본 상호 작용은 컨트롤 플레인에 있는 쿠버네티스 스케줄러에 의해 관리됩니다.

파드가 노드에 배치되는 방법

파드 생성: 사용자가 API 서버에 파드(또는 파드를 생성하는 Deployment와 같은 상위 수준 객체)의 YAML 정의를 제출합니다.
스케줄링 결정: 스케줄러는 리소스 요청, 제약 조건 및 사용 가능한 용량을 기반으로 해당 파드를 실행하기에 가장 적합한 노드를 식별합니다.
바인딩: 노드가 선택되면 파드는 해당 특정 노드에 바인딩됩니다.
실행: 할당된 노드의 Kubelet은 새 파드 할당을 감지하고 필요한 이미지를 가져와 컨테이너를 시작합니다.

중요 사항: 파드가 노드에 스케줄링되면, 종료되거나, 영구적으로 충돌하거나, 노드가 실패할 때까지 해당 노드에 유지됩니다. 쿠버네티스는 일반적으로 실행 중인 파드를 노드 간에 마이그레이션하지 않습니다.

기능	쿠버네티스 노드	쿠버네티스 파드
역할	물리적/가상 컴퓨팅 리소스를 제공합니다.	하나 이상의 애플리케이션 컨테이너를 실행합니다.
범위	클러스터 인프라 수준.	애플리케이션 워크로드 수준.
스케줄링 단위	스케줄러로부터 파드를 받습니다.	노드에 스케줄링되는 단위입니다.
구성 요소	Kubelet, 컨테이너 런타임, Kube-proxy.	애플리케이션 컨테이너, 공유 볼륨, 공유 IP.
수량	일반적으로 클러스터당 몇 개에서 수십 개.	워크로드에 따라 수백 또는 수천 개가 될 수 있습니다.

모범 사례 및 문제 해결 통찰

이 아키텍처를 이해하면 실제 클러스터 관리에 도움이 됩니다.

리소스 관리

리소스 요청/제한: Pod spec에서 항상 리소스 requests 및 limits를 정의하십시오. 이를 통해 스케줄러는 충분한 용량을 가진 노드에 파드를 정확하게 일치시켜 리소스 경합을 방지할 수 있습니다.
노드 압박: 노드에 과부하가 걸리면(디스크 공간 또는 메모리 부족) Kubelet이 이 상태를 보고합니다. 그러면 쿠버네티스는 안정성을 유지하기 위해 해당 노드에서 파드를 이주시킬 수 있습니다.

고가용성(HA)

중복성: HA를 달성하려면 Deployment 또는 StatefulSet에서 관리하는 파드의 여러 복사본(복제본)을 실행해야 합니다. 스케줄러는 이러한 복제본을 다른 노드에 배치하려고 시도하여 단일 노드 실패가 전체 애플리케이션을 중단시키지 않도록 합니다.

문제 해결

애플리케이션이 시작되지 않을 때:

파드 상태 확인: kubectl describe pod <pod-name>을 사용합니다. 'Events' 섹션을 보고 파드가 어떤 노드에 스케줄링되었는지 확인합니다.
노드 상태 확인: 파드가 Pending 상태에 머물러 있다면, 문제는 일반적으로 스케줄링 관련입니다(예: 요구 사항을 충족하는 노드가 없음). 파드가 실행 중이지만 실패하는 경우, 파드가 배치된 특정 노드의 Kubelet 로그를 확인하십시오.

결론

쿠버네티스 노드는 실행 환경과 리소스를 제공하는 물리적 또는 가상 머신이며 Kubelet에 의해 관리됩니다. 파드는 어떤 코드가 실행되는지, 그리고 해당 코드가 실행을 위해 어떻게 패키지되는지(공유 스토리지 및 네트워킹과 함께)를 결정하는 추상적이고 논리적인 래퍼입니다. 파드는 노드에 스케줄링되어 쿠버네티스에서 컨테이너 오케스트레이션을 지원하는 필수 실행 쌍을 형성합니다.