파드(Pod): 쿠버네티스에서 살아 숨쉬는 최소 단위

단일 컨테이너 대신 쿠버네티스가 사용하는 가장 작은 배포 단위인 파드(Pod)의 개념과 역할을 익힙니다.

우리가 도커(Docker)를 사용할 때는 항상 '컨테이너(Container)' 단위로 애플리케이션을 실행했습니다. 하지만 쿠버네티스의 세계로 넘어오면 이야기가 조금 달라집니다. 쿠버네티스는 컨테이너를 직접 다루지 않고, 그보다 한 단계 더 큰 개념인 '파드(Pod)'라는 단위를 사용합니다. 왜 쿠버네티스는 굳이 파드라는 새로운 개념을 도입했을까요? 이번 시간엔 쿠버네티스에서 살아 숨쉬는 최소 단위인 파드의 정체와 그 역할을 파헤쳐 봅니다.

컨테이너를 감싸는 포장지, 파드(Pod)

쿠버네티스 환경에서 애플리케이션이 실행되는 가장 작은 배포 단위는 파드(Pod)입니다.

도커에서는 컨테이너 하나가 곧 배포의 기본 단위였지만, 쿠버네티스 클러스터 안에서는 무조건 파드를 생성해야만 애플리케이션을 띄울 수 있습니다. 마치 우리가 물건을 택배로 보낼 때, 내용물(컨테이너)만 덩그러니 보내지 않고 박스(파드)에 포장해서 보내는 것과 같습니다.

왜 컨테이너를 직접 배포하지 않을까?

"그냥 컨테이너를 바로 실행하면 안 되나?"라는 의문이 생길 수 있습니다. 쿠버네티스가 파드라는 개념을 도입한 가장 큰 이유는 밀접하게 연관된 여러 개의 컨테이너를 하나의 단위로 묶어서 관리하기 위해서입니다.

웹 서버 컨테이너와, 그 웹 서버의 로그를 수집하여 외부로 전송하는 로그 수집 컨테이너가 있다고 가정해 봅시다. 이 두 컨테이너는 항상 같은 컴퓨터(노드) 안에서 찰떡처럼 붙어 다녀야 제 역할을 할 수 있습니다. 쿠버네티스는 이렇게 반드시 함께 동작해야 하는 컨테이너들을 하나의 파드 안에 넣음으로써, 생명 주기를 통일하고 네트워크와 스토리지를 공유할 수 있게 만들어 줍니다.

물론 대부분의 실무 환경에서는 '1 파드 = 1 컨테이너' 구조를 가장 많이 사용합니다. 특별히 여러 컨테이너를 묶어야 할 이유가 없다면, 파드 하나에 컨테이너 하나만 넣어서 단일 애플리케이션처럼 운영하는 것이 일반적인 패턴입니다.

정의

파드 (Pod)

고래 떼(Pod of whales)에서 유래한 단어로, 쿠버네티스에서 생성하고 관리할 수 있는 배포의 가장 작은 컴퓨팅 단위입니다. 한 개 이상의 컨테이너 그룹으로 이루어지며, 스토리지와 네트워크 자원을 공유합니다.

파드 안의 자원 공유: 네트워크와 스토리지

파드라는 울타리 안에 들어간 컨테이너들은 매우 특별한 혜택을 누리게 됩니다. 바로 자원의 긴밀한 공유입니다. 이는 도커 환경에서 각각의 컨테이너를 따로 띄웠을 때 겪게 되는 복잡한 설정들을 크게 단순화시켜 줍니다.

로컬호스트(localhost)로 통신하는 컨테이너들

파드 내부에 있는 컨테이너들은 동일한 네트워크 환경(IP 주소와 포트 공간)을 공유합니다.

이게 무슨 뜻이냐 하면, 같은 파드 안에 있는 '컨테이너 A'와 '컨테이너 B'는 서로 통신할 때 복잡한 IP 설정 없이 그냥 `localhost`를 사용해서 데이터를 주고받을 수 있다는 뜻입니다. 마치 하나의 컴퓨터 안에서 실행되는 서로 다른 프로세스들처럼 말이죠. 따라서 포트 충돌만 조심하면 통신이 매우 직관적이고 빠릅니다.

볼륨(Volume)을 통한 파일 공유

네트워크뿐만 아니라 저장 공간(스토리지)도 쉽게 공유할 수 있습니다. 쿠버네티스는 파드 레벨에서 볼륨(Volume)을 정의할 수 있게 해줍니다.

파드에 볼륨을 하나 만들어 두고, 그 안에 있는 여러 컨테이너들이 모두 동일한 볼륨을 마운트(연결)하도록 설정할 수 있습니다. 예를 들어 한 컨테이너가 특정 디렉토리에 파일을 쓰면, 다른 컨테이너가 그 디렉토리에 접근해서 파일을 즉시 읽어 들일 수 있게 되는 것이죠. 이는 데이터 동기화나 로그 수집 같은 작업을 구성할 때 매우 강력 무기가 됩니다.

파드 정의 매니페스트 (YAML)

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

이 YAML 파일은 쿠버네티스에게 "nginx 이미지를 사용하는 컨테이너 하나가 들어있는 파드를 만들어줘"라고 요청하는 명세서입니다.

파드의 생로병사: 파드는 언제 죽고 어떻게 살아나는가?

파드의 가장 중요한 특징 중 하나는 일시적이고 언제든 사라질 수 있는(Ephemeral) 존재라는 것입니다. 이것은 쿠버네티스 철학의 핵심이기도 합니다.

파드는 반려동물이 아니라 가축(Cattle)이다

전통적인 서버 관리에서는 서버 한 대 한 대에 이름을 붙이고 애지중지 관리했습니다(Pet). 서버가 아프면 고쳐 썼죠. 하지만 쿠버네티스 세계에서 파드는 언제든 교체 가능한 가축(Cattle) 취급을 받습니다.

파드가 실행 중인 서버(노드)가 고장 나거나 메모리 부족 등으로 파드가 죽게 되면, 쿠버네티스는 그 파드를 '수리'하려 들지 않습니다. 대신 미련 없이 파드를 버리고 새로운 파드를 만들어서 다른 건강한 노드에 띄웁니다. 파드가 재생성될 때는 IP 주소도 완전히 새롭게 바뀝니다.

상태(State)를 저장하면 안 되는 이유

이처럼 파드는 언제든 죽고 새로 태어날 수 있기 때문에, 파드 내부의 임시 디스크에 중요한 사용자 데이터를 저장해서는 안 됩니다. 파드가 삭제되는 순간 그 안에 있던 데이터도 연기처럼 사라지기 때문입니다.

중요한 데이터는 반드시 파드 외부의 데이터베이스나 별도의 영구 스토리지(Persistent Volume)에 안전하게 저장해야 합니다. 이것이 바로 컨테이너 기반 애플리케이션이 반드시 지켜야 할 상태가 없는(Stateless) 구조의 핵심입니다.

파드를 다룰 때의 핵심 수칙

파드는 언제든 죽을 수 있다는 가정 하에 설계할 것
중요한 데이터는 파드 내부가 아닌 외부 스토리지에 저장할 것
밀접하게 결합된 컨테이너들만 같은 파드에 묶고, 독립적인 서비스는 별도 파드로 분리할 것

개념 퀴즈

퀴즈 답을 맞춰야 학습 완료가 됩니다.

다음 중 파드(Pod)에 대한 설명으로 가장 적절하지 않은 것은 무엇인가요?

3줄 요약

1파드(Pod)는 쿠버네티스 클러스터에서 애플리케이션을 실행하고 관리하는 가장 작은 배포 단위입니다.
2같은 파드 내의 컨테이너들은 IP 주소(localhost)와 저장 공간(Volume)을 공유하여 긴밀하게 협력할 수 있습니다.
3파드는 일시적인 자원이므로 언제든 소멸할 수 있으며, 중요한 데이터는 파드 외부에 저장(Stateless)해야 합니다.