85. Pod (파드 / 포드)

⚠️ 이 문서는 컨테이너 오케스트레이션 도구인 쿠버네티스(Kubernetes) 환경에서, 도커(Docker) 컨테이너 한 개를 직접 띄우는 대신 **반드시 하나 이상의 컨테이너들을 캡슐처럼 감싸서 배포하고 관리하는 가장 작고 기본적인 컴퓨팅 논리 단위인 '파드(Pod)'**를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 고래 떼(고래=도커 컨테이너, Pod=고래 떼를 뜻하는 영단어)라는 의미처럼, 긴밀하게 협력해야 하는 컨테이너들을 하나의 그룹으로 묶어 동일한 생태계(IP 주소, 디스크 볼륨)를 제공하는 쿠버네티스의 기본 실행 단위다.
  2. 가치: "왜 컨테이너를 그냥 안 띄우고 귀찮게 파드로 감싸는가?" 핵심 비즈니스 로직(웹 서버)을 담당하는 메인 컨테이너 옆에, 로깅이나 보안을 담당하는 보조 컨테이너(사이드카)를 강력하게 묶어 한 몸처럼 통신하고 배포(Scaling)하기 위함이다.
  3. 기술 체계: 하나의 파드 안에 있는 모든 컨테이너들은 동일한 네트워크 네임스페이스(Network Namespace)를 공유하므로 서로를 localhost로 핑(Ping) 때려 통신할 수 있으며, 파드 하나가 죽고 새로 뜰 때마다 내부에 배정된 IP 주소가 매번 바뀌는 임시적(Ephemeral) 특성을 지닌다.

Ⅰ. 컨테이너 랩핑(Wrapping)의 철학: 왜 Pod인가?

쿠버네티스는 왜 '컨테이너 단위' 통제를 포기했을까?

  1. 컨테이너 단일 배포의 한계:
    • 웹 서버(Nginx) 컨테이너 1개와 로그 수집기(Fluentd) 컨테이너 1개를 각각 따로 서버에 띄운다고 가정하자.
    • 쿠버네티스의 스케줄러가 판단을 잘못하여 Nginx는 한국 서버에, Fluentd는 미국 서버에 띄워버리면? 로그를 읽으러 태평양을 건너야 하는 끔찍한 네트워크 오버헤드가 터진다.
  2. Pod의 강력한 접착력 (Co-location):
    • 두 컨테이너를 하나의 파드(Pod)라는 껍데기로 감싸버리면, 쿠버네티스는 반드시 이 파드를 '단 하나의 물리적 서버(Node)' 안에 띄운다.
    • 파드 안의 컨테이너들은 한 몸통에 붙은 기생수처럼 언제나 운명(생사고락)을 함께하며 찰싹 붙어있게 된다.
  3. 1 Pod = 1 Container 원칙 (단일 목적성):
    • 파드 안에 여러 컨테이너를 넣을 수 있다고 해서, 웹서버, DB서버, 레디스를 한 파드에 몽땅 우겨 넣으면 절대 안 된다. (결합도의 저주)
    • 파드는 기본적으로 1개의 메인 컨테이너만 품는 것이 원칙이며, 부득이하게 메인 컨테이너를 도와줄 **보조 컨테이너(사이드카 패턴)**가 필요할 때만 예외적으로 다중 컨테이너를 구성한다.

📢 섹션 요약 비유: 파드(Pod)는 완두콩 껍질이고 컨테이너는 그 안의 콩알입니다. 요리사(쿠버네티스)는 콩알을 한 알씩 젓가락으로 줍지 않고 껍질째 쥐어 올립니다. 보통 껍질 하나에 콩 한 알(1파드 1컨테이너)이 들어있지만, 가끔 콩알 옆에 아주 작은 기생 벌레(사이드카 컨테이너)가 딱 달라붙어 껍질 속에 같이 살기도 하는 완벽한 생태계 포장지입니다.

Ⅱ. 파드 내부의 생태계: 네트워크와 스토리지 공유

파드 안에 들어간 컨테이너들은 남이 아니라 완벽한 한 가족이 된다.

  1. 네트워크 공유 (Localhost 통신):
    • 파드가 생성될 때, 쿠버네티스는 컨테이너가 아니라 '파드 껍데기'에 딱 1개의 IP 주소(예: 10.1.1.5)를 부여한다.
    • 따라서 파드 안에 있는 Nginx 컨테이너와 Tomcat 컨테이너는 서로 복잡한 IP를 묻지 않고, 내 PC 안에서 통신하듯 그냥 localhost:8080이라고 부르면 즉시 통신이 연결된다. (극강의 통신 속도)
  2. 볼륨(디스크) 공유 (Shared Volume):
    • 파드 안에 10GB짜리 공용 디스크(Volume)를 마운트할 수 있다.
    • Nginx 컨테이너가 이 공용 디스크에 error.log 파일을 쭉쭉 써 내려가면, 옆에 있는 Fluentd 컨테이너가 즉시 그 폴더를 열어 파일을 읽어 들여 바깥 중앙 센터로 쏘아 올린다. (퍼펙트한 로깅 협업)

📢 섹션 요약 비유: 파드는 하나의 아파트 호수(IP 주소)입니다. 방 A에 사는 철수(웹 컨테이너)와 방 B에 사는 영희(로그 컨테이너)는 우편물을 보낼 필요 없이 그냥 거실(Localhost)로 나와서 말하면 들립니다. 그리고 거실에 있는 공용 냉장고(볼륨)에 철수가 먹다 남은 케이크(로그)를 넣어두면 영희가 열어보고 바로 먹을 수 있는 완벽한 공동생활 공간입니다.

Ⅲ. 파드의 일회성(Ephemeral)과 생명주기

파드는 소나 돼지 같은 애완동물이 아니라, 언제든 죽이고 새로 찍어내는 닭 공장의 닭이다.

  1. 영원하지 않은 생명 (Cattle, Not Pets):
    • 파드는 서버 메모리 부족이나 버그가 생기면 언제든지 가차 없이 죽는다(Terminated).
    • 쿠버네티스(ReplicaSet 등)는 파드가 죽은 것을 감지하면, 죽은 파드를 심폐소생술로 살리지 않고 그 파드를 버린 뒤 완전히 똑같이 생긴 '새로운 파드'를 찍어내어 교체해 버린다.
  2. IP 주소의 휘발성 (Dynamic IP):
    • 새로운 파드가 태어나면 IP 주소는 예전과 다르게 완전히 랜덤한 새 번호를 부여받는다.
    • 따라서 파드 A가 파드 B와 통신할 때 B의 IP(예: 10.1.1.5)를 소스코드에 하드코딩해 두면, B가 죽고 새 파드(10.1.1.9)로 교체되는 순간 통신이 100% 단절되는 대형 사고가 터진다.
  3. 서비스(Service) 객체의 필요성:
    • 이 치명적인 파드의 잦은 죽음과 IP 변경을 덮어주기 위해, 쿠버네티스에는 영원히 IP가 변하지 않는 간판(Load Balancer) 역할을 하는 **서비스(Service)**라는 오브젝트가 반드시 파드 앞단에 짝꿍으로 서 있어야만 아키텍처가 굴러간다.

📢 섹션 요약 비유: 파드는 전쟁터의 소모품 병사입니다. 총에 맞아 죽으면 살려내지 않고 바로 똑같은 훈련을 받은 신병(새 파드)을 무한정 찍어내 전선에 투입합니다. 병사들 가슴에 붙은 군번(IP 주소)이 매일 바뀌기 때문에, 외부에서는 특정 병사를 찾지 않고 항상 그 자리에 고정되어 있는 '소대장(Service 객체)'에게 연락해야만 100% 안전하게 부대와 통신할 수 있습니다.