이제 나도 클라우드 네이티브 전문가: 쿠버네티스 구축부터 운영 완전 정복

파드가 가진 가장 두드러지고 독특한 특징 중 하나는 바로 하나 이상의 컨테이너를 하나의 논리적인 그룹으로 묶어, 마치 한 몸처럼 함께 실행하고 관리할 수 있다는 점입니다. 여기서 “하나 이상”이라는 표현에 주목해주십시오. 이 말은 즉, 파드가 오직 하나의 컨테이너만으로 구성될 수도 있고, 반대로 서로 밀접하게 연관되어 함께 작동해야 하는 여러 개의 컨테이너들로 구성될 수도 있다는 의미를 내포합니다.

가장 흔하고 직관적인 사용 사례는 단일 컨테이너 파드입니다. 이 경우, 파드 하나에 주된 역할을 수행하는 컨테이너 하나만을 배치합니다. 예를 들어, 웹 요청을 받아 정적 페이지를 제공하는 Nginx 웹 서버 컨테이너 하나만을 포함하는 파드를 떠올릴 수 있습니다. 이런 구성에서 파드는 해당 Nginx 컨테이너가 안정적으로 실행될 수 있도록 격리된 환경과 필요한 자원(네트워크, 일부 스토리지 등)을 제공하는 역할을 합니다. 마치 한 명의 배우가 독무대를 펼칠 수 있도록 무대 장치와 조명을 제공하는 것과 비슷하다고 할 수 있겠습니다. 이 방식은 애플리케이션의 책임이 명확하고, 관리가 단순하다는 장점이 있습니다.

파드는 쿠버네티스에서 가장 작은 배포 단위로, 하나 이상의 컨테이너를 포함합니다. 파드의 생명 주기는 다음과 같은 단계로 구성됩니다.

1. Pending: 파드가 생성되었지만, 아직 모든 컨테이너가 시작되지 않은 상태입니다.
2. Running: 모든 컨테이너가 정상적으로 실행 중인 상태입니다.
3. Succeeded: 모든 컨테이너가 정상적으로 종료된 상태입니다.
4. Failed: 하나 이상의 컨테이너가 비정상적으로 종료된 상태입니다.
5. Unknown: 파드의 상태를 알 수 없는 경우입니다.

파드의 상태는 kubectl get pods 명령어를 통해 확인할 수 있으며, 자세한 정보는 kubectl describe pod <파드명> 명령어로 확인할 수 있습니다.

하지만, 때로는 여러 컨테이너가 마치 하나의 팀처럼, 하나의 단위처럼 긴밀하게 협력하며 움직여야 하는 경우가 발생합니다. 바로 이때 다중 컨테이너 파드의 진가가 드러납니다. 예를 들어 다음과 같은 시나리오들을 생각해 볼 수 있습니다:

• 사이드카(Sidecar) 패턴: 주 애플리케이션 컨테이너(메인 컨테이너)가 핵심 비즈니스 로직에만 집중할 수 있도록, 부가적인 기능을 수행하는 헬퍼 컨테이너를 같은 파드 내에 배치하는 방식입니다. 대표적인 예로, 메인 컨테이너가 생성하는 로그를 수집하여 파일로 저장하거나 중앙 로깅 시스템(예: Elasticsearch, Splunk)으로 실시간 전송하는 로깅 에이전트 컨테이너(예: Fluentd, Filebeat)가 있습니다. 또는, 메인 컨테이너의 상태를 주기적으로 점검하여 모니터링 시스템(예: Prometheus)에 메트릭을 노출하는 모니터링 에이전트 컨테이너도 사이드카의 좋은 예입니다. 서비스 메시 환경에서는 Envoy나 Linkerd 같은 프록시 컨테이너가 사이드카로 배포되어 네트워크 트래픽 제어, 보안, 관찰 가능성 등을 담당하기도 합니다. 중요한 점은, 이러한 사이드카 컨테이너들은 메인 컨테이너의 코드를 변경하지 않고도 기능을 확장하거나 개선할 수 있게 해준다는 것입니다.
• 앰배서더(Ambassador) 패턴: 메인 컨테이너가 외부 서비스(예: 데이터베이스, 다른 마이크로서비스, 레거시 시스템)와 통신하는 방식을 단순화하거나 추상화하는 프록시 컨테이너를 같은 파드에 두는 패턴입니다. 메인 컨테이너는 localhost를 통해 앰배서더 컨테이너와 통신하고, 앰배서더 컨테이너가 실제 외부 서비스와의 복잡한 연결 설정, 재시도 로직, 서비스 디스커버리, 샤딩 등을 대신 처리해줍니다. 이를 통해 메인 애플리케이션은 외부 환경의 변화에 덜 민감해지고, 개발자는 핵심 로직에 더 집중할 수 있습니다.
• 어댑터(Adapter) 패턴: 메인 컨테이너가 생성하는 출력(예: 로그, 메트릭)의 형식을 표준화하거나, 외부 시스템이 요구하는 특정 인터페이스에 맞게 변환하는 역할을 하는 컨테이너를 배치하는 패턴입니다. 예를 들어, 특정 형식으로만 로그를 출력하는 레거시 애플리케이션이 있다면, 어댑터 컨테이너가 이 로그를 받아 표준화된 JSON 형식으로 변환하여 로깅 시스템으로 전달할 수 있습니다.
• 초기화 컨테이너(Init Container): 이 컨테이너들은 조금 특별합니다. 파드 내의 주 애플리케이션 컨테이너들이 시작되기 전에 순차적으로 실행되어, 필요한 사전 설정 작업이나 초기화 작업을 수행합니다. 예를 들어, 애플리케이션 실행에 필요한 설정 파일을 다운로드하거나, 데이터베이스 스키마를 마이그레이션하거나, 특정 서비스가 준비될 때까지 대기하는 등의 작업을 처리할 수 있습니다. 초기화 컨테이너들이 모두 성공적으로 완료되어야만 주 애플리케이션 컨테이너들이 시작될 수 있습니다.

이처럼 강하게 결합되어(tightly coupled) 함께 작동해야 하는 컨테이너들은 같은 파드 안에 배치됨으로써 같은 생명 주기를 공유하게 됩니다. 즉, 파드가 시작될 때 함께 시작되고, 파드가 종료될 때 함께 종료됩니다. 이는 마치 하나의 물리적 머신이나 가상 머신 내에서 여러 프로세스들이 서로 긴밀하게 연관되어 동작하는 상황을 컨테이너 환경에서 효과적으로 모델링한 것이라고 볼 수 있습니다.

여기서 반드시 기억해야 할 중요한 점은, 파드 내의 모든 컨테이너는 예외 없이 동일한 노드(클러스터 내의 워커 머신)에 함께 스케줄링된다는 것입니다. 쿠버네티스의 스케줄러는 개별 컨테이너가 아닌 파드 단위로 자원 할당 및 배치 결정을 내립니다. 따라서 한 파드에 속한 컨테이너들이 서로 다른 노드에 흩어져 실행되는 경우는 절대로 없습니다. 이렇게 항상 같은 “집”에 살게 되는 덕분에, 파드 내 컨테이너들은 다음 절에서 자세히 설명할 네트워크 및 스토리지 자원을 매우 효율적으로 공유하고, localhost를 통해 손쉽게 통신하는 등의 이점을 누릴 수 있게 됩니다. 이는 파드가 제공하는 가장 강력한 기능 중 하나이며, 다양한 애플리케이션 아키텍처를 유연하게 구성할 수 있는 기반이 됩니다.

파드 내에 함께 배치된 컨테이너들은 단순히 같은 공간에 모여 있는 것을 넘어, 마치 한 집에 사는 가족 구성원처럼 중요한 자원들을 공유합니다. 가족들이 집 주소와 현관문, 때로는 거실이나 주방 같은 공용 공간을 함께 사용하듯이, 파드 내의 컨테이너들은 네트워크 환경과 스토리지(볼륨)를 공유합니다. 이 공유라는 개념이야말로 파드가 단순한 컨테이너 그룹 이상의 의미를 지니며, 쿠버네티스에서 애플리케이션을 구성하는 방식에 큰 영향을 미치는 핵심적인 이유 중 하나입니다.

쿠버네티스는 파드 내의 모든 컨테이너가 동일한 리눅스 네트워크 네임스페이스(Linux Network Namespace)를 공유하도록 설계되어 있습니다. 네트워크 네임스페이스는 리눅스 커널의 기능으로, 각 네임스페이스마다 독립적인 네트워크 스택(네트워크 인터페이스, IP 주소, 라우팅 테이블, 포트 번호 공간 등)을 가질 수 있게 해주는 격리 기술입니다. 파드에서는 이 네임스페이스를 공유함으로써 다음과 같은 중요한 특징들이 나타납니다:

• 단일 IP 주소 및 포트 공간 공유: 각 파드는 클러스터 내에서 고유한 IP 주소를 할당받습니다 (이에 대해서는 다음 절 7.1.1.3에서 더 자세히 다룹니다). 그리고 이 IP 주소는 파드 내의 모든 컨테이너가 공유합니다. 마치 한 집에 하나의 인터넷 회선과 공인 IP가 할당되는 것과 유사합니다. 또한, 이 IP 주소에 할당된 모든 포트 번호 공간(0번부터 65535번까지)도 파드 내 모든 컨테이너가 공유합니다.이것이 의미하는 바는, 파드 내의 한 컨테이너가 특정 포트(예: 8080번)를 사용하고 있다면, 같은 파드 내의 다른 컨테이너는 그 8080번 포트를 사용할 수 없습니다. 마치 한 집에서 한 사람이 특정 방 번호(예: 안방)를 쓰고 있다면, 다른 가족 구성원이 동시에 그 안방을 자기 방으로 쓸 수 없는 것과 같습니다.하지만 이 공유 덕분에, 파드 내 컨테이너들은 localhost (또는 127.0.0.1)를 통해 서로 매우 쉽게 통신할 수 있습니다. 예를 들어, 메인 애플리케이션 컨테이너가 localhost:8080에서 API 서비스를 제공하고 있다면, 같은 파드 내의 사이드카 컨테이너(예: 로그 수집기)는 별도의 IP 주소를 찾을 필요 없이 http://localhost:8080/api 와 같은 주소로 메인 애플리케이션에 접근하여 데이터를 가져오거나 상태를 확인할 수 있습니다. 이는 단일 물리 머신이나 가상 머신 내에서 여러 프로세스가 localhost를 통해 IPC(Inter-Process Communication)를 수행하는 것과 매우 유사한 경험을 제공하며, 컨테이너 간의 긴밀한 협력을 가능하게 합니다.실제로 이 네트워크 네임스페이스를 유지하기 위해 쿠버네티스는 파드마다 보이지 않는 특별한 컨테이너, 흔히 “pause” 컨테이너 (또는 인프라 컨테이너)라고 불리는 것을 먼저 실행합니다. 이 “pause” 컨테이너는 네트워크 네임스페이스를 생성하고 유지하는 역할을 하며, 파드 내의 다른 애플리케이션 컨테이너들은 이 “pause” 컨테이너의 네트워크 네임스페이스에 참여(join)하는 방식으로 네트워크를 공유합니다. 애플리케이션 컨테이너 중 하나가 재시작되더라도 “pause” 컨테이너가 살아있는 한 파드의 IP 주소는 유지됩니다.
• 컨테이너 간 포트 충돌에 대한 주의: 앞서 언급했듯이, 파드 내 컨테이너들이 포트 공간을 공유하기 때문에, 만약 두 개 이상의 컨테이너가 같은 포트 번호를 사용하려고 하면 포트 충돌(Port Collision)이 발생하여 파드가 정상적으로 시작되지 않거나, 둘 중 하나의 컨테이너만 해당 포트를 점유하게 됩니다. 예를 들어, 한 파드 안에 Nginx 웹 서버 컨테이너와 Apache 웹 서버 컨테이너를 동시에 띄우면서 둘 다 기본 HTTP 포트인 80번을 사용하도록 설정하면 문제가 발생합니다. 이 경우, Nginx는 80번 포트를 사용하고 Apache는 8080번 포트를 사용하는 식으로 각 컨테이너가 서로 다른 포트를 사용하도록 명시적으로 설정해야 합니다. 이는 파드를 설계할 때 반드시 고려해야 할 중요한 사항입니다.

파드는 컨테이너들이 데이터를 서로 공유하거나, 파드가 재시작되어도 데이터를 유지할 수 있도록 (볼륨의 종류에 따라) 스토리지 볼륨(Volume) 세트를 정의할 수 있습니다. 이 볼륨들은 파드의 명세(PodSpec)에 정의되며, 파드 내의 특정 컨테이너 또는 모든 컨테이너에서 지정된 경로로 마운트(mount)하여 사용할 수 있도록 설정될 수 있습니다. 이를 통해 컨테이너 간에 데이터를 매우 쉽게 공유할 수 있습니다.

• 데이터 공유의 예: 예를 들어, 한 컨테이너(예: 콘텐츠 생성기)가 동적으로 웹 페이지 파일들을 생성하고, 이 파일들을 공유 볼륨의 특정 디렉터리에 저장한다고 가정해 봅시다. 그러면 같은 파드 내의 다른 컨테이너(예: Nginx 웹 서버)는 이 공유 볼륨의 동일한 디렉터리를 자신의 웹 루트 디렉터리로 마운트하여, 콘텐츠 생성기가 만든 파일들을 즉시 웹으로 서비스할 수 있습니다. 또는, 여러 컨테이너가 공통으로 사용하는 설정 파일(예: config.ini)이나 인증서 파일이 있을 경우, 이 파일들을 공유 볼륨에 저장해두고 각 컨테이너가 필요에 따라 읽어 사용하도록 구성할 수 있습니다.
• 볼륨의 생명 주기: 파드에서 사용되는 볼륨의 종류는 다양하며 (예: emptyDir, hostPath, configMap, secret, persistentVolumeClaim 등), 각 볼륨 유형마다 특징과 생명 주기가 다릅니다. 가장 기본적인 emptyDir 볼륨의 경우, 파드가 노드에 할당될 때 생성되며 파드가 존재하는 동안 유지됩니다. 파드 내의 모든 컨테이너는 이 emptyDir 볼륨에 데이터를 읽고 쓸 수 있습니다. 하지만 emptyDir 볼륨의 생명 주기는 파드의 생명 주기에 직접적으로 연결되기 때문에, 파드가 어떤 이유로든 노드에서 삭제되면 emptyDir 볼륨에 저장된 데이터도 함께 영구적으로 사라집니다. 이는 임시적인 데이터 공유나 스크래치 공간으로 활용하기에는 적합하지만, 영구적인 데이터 보존에는 적합하지 않습니다.
• 영구 데이터 저장: 데이터베이스나 중요한 애플리케이션 상태처럼 영구적인 데이터 저장이 필요한 경우에는, 파드의 생명 주기와 독립적으로 데이터를 보존할 수 있는 퍼시스턴트 볼륨(PersistentVolume, PV)과 퍼시스턴트 볼륨 클레임(PersistentVolumeClaim, PVC) 같은 다른 메커니즘을 사용해야 합니다. 이러한 영구 스토리지 옵션에 대해서는 책의 뒷부분에서 더 자세히 다룰 예정입니다.

이처럼 파드 내 컨테이너들이 네트워크와 스토리지를 공유하는 강력한 특징 덕분에, 개발자들은 마치 단일 머신에서 여러 협력적인 프로세스를 운영하는 것처럼 컨테이너들을 구성하고 관리할 수 있습니다. 서로를 쉽게 발견하고(localhost 통신), 데이터를 효율적으로 주고받으며(공유 볼륨), 하나의 논리적인 애플리케이션 단위로 함께 작동할 수 있는 환경이 마련되는 것입니다. 이는 특히 마이크로서비스 아키텍처에서 주 애플리케이션 컨테이너를 보조하는 작은 헬퍼 컨테이너들(예: 로그 수집기, 모니터링 에이전트, 보안 프록시, 데이터 동기화 유틸리티 등)을 주 애플리케이션 컨테이너와 함께 같은 파드 내에 묶어 배포하고 운영하는 데 매우 효과적이며, 쿠버네티스가 제공하는 유연성과 강력함의 핵심적인 기반이 됩니다.

이전 절에서 파드 내 컨테이너들이 네트워크 네임스페이스를 공유한다고 말씀드렸죠? 그 결과로 나타나는 가장 중요하고 직접적인 특징 중 하나가 바로, 쿠버네티스 클러스터 내에서 각 파드는 고유한 IP 주소를 할당받는다는 사실입니다. 이는 쿠버네티스 네트워킹 모델의 근간을 이루는 매우 중요한 개념으로, 클러스터 내의 모든 파드가 마치 독립된 호스트처럼 서로 직접 통신할 수 있는 기반을 마련해 줍니다. 우리가 현실 세계에서 각자의 집 주소를 가지고 있어 우편물을 주고받거나 서로 방문할 수 있는 것처럼, 쿠버네티스 세상의 모든 파드는 자신만의 고유한 네트워크 주소를 갖게 되는 것입니다.

이 그림에서 볼 수 있듯이, 각 노드(물리적 또는 가상 머신) 위에는 여러 개의 파드가 실행될 수 있으며, 각 파드는 자신만의 IP 주소(예: 10.1.1.2, 10.1.2.2 등)를 가집니다. 쿠버네티스는 CNI(Container Network Interface) 플러그인 아키텍처를 통해 다양한 네트워크 솔루션(예: Calico, Flannel, Weave Net 등)을 지원하며, 이 CNI 플러그인이 실제로 파드에 IP 주소를 할당하고 파드 간 통신이 가능하도록 네트워크를 구성하는 역할을 담당합니다. 중요한 점은 이 IP 주소가 클러스터 내부에서 라우팅 가능한 고유한 IP 주소라는 것입니다.

이 IP 주소는 7.1.1.2절에서 설명드린 바와 같이, 파드 내에 포함된 모든 컨테이너가 공유합니다. 즉, 파드라는 ‘집’의 유일한 외부 주소이며, 그 집 안에 사는 여러 ‘가족 구성원'(컨테이너)들이 함께 사용하는 것입니다. 따라서 파드 외부의 다른 파드나 시스템에서 특정 파드 내부의 특정 컨테이너와 통신하고자 할 때는, 해당 파드의 IP 주소와 그 컨테이너가 파드 내부에서 리스닝하고 있는 포트 번호를 알면 됩니다. 예를 들어, 파드 A의 IP 주소가 10.244.1.5이고, 그 안에 실행 중인 웹 서버 컨테이너가 80번 포트를 사용하고 있다면, 클러스터 내의 다른 파드 B는 특별한 설정 없이 10.244.1.5:80 주소로 파드 A의 웹 서버에 직접 HTTP 요청을 보낼 수 있습니다 (물론, 쿠버네티스 네트워크 정책(NetworkPolicy) 등에 의해 명시적으로 접근이 제한되지 않았다는 가정 하에).

이러한 “IP-per-Pod” (파드당 IP 할당) 모델은 쿠버네티스가 제공하는 여러 가지 중요한 이점의 기반이 됩니다:

• 네트워킹 단순화: 애플리케이션 개발자나 운영자는 더 이상 호스트 머신의 포트를 컨테이너 포트에 일일이 매핑하는 복잡한 과정(예: 컨테이너 런타임에서 docker run -p <host_port>:<container_port> 옵션을 사용하는 것)에 대해 크게 신경 쓸 필요가 없습니다. 각 파드가 고유한 IP를 가지므로, 파드 내의 컨테이너는 자신이 원하는 포트를 (같은 파드 내 다른 컨테이너와 충돌하지 않는 선에서) 자유롭게 사용할 수 있습니다. 다른 파드와 통신할 때도 중간에 복잡한 포트 매핑이나 NAT(Network Address Translation) 계층 없이 대상 파드의 IP 주소와 포트 번호로 직접 통신하면 됩니다. 이는 쿠버네티스가 지향하는 ‘플랫 네트워크(flat network)’ 모델의 핵심입니다. 즉, 원칙적으로 클러스터 내의 어떤 파드라도 다른 파드의 IP 주소를 사용하여 직접 통신할 수 있으며, 중간에 복잡한 네트워크 주소 변환을 거치지 않습니다.
• 기존 애플리케이션과의 높은 호환성: 많은 전통적인 애플리케이션들은 특정 포트(예: 웹 서버는 80 또는 443, 데이터베이스는 3306 또는 5432)에서 실행되도록 하드코딩되어 있는 경우가 많습니다. 만약 여러 애플리케이션 인스턴스가 같은 호스트에서 실행되면서 모두 같은 포트를 사용하려고 하면 포트 충돌이 발생합니다. 하지만 쿠버네티스에서는 각 파드가 자신만의 독립적인 IP 주소를 가지므로, 서로 다른 파드에 배포된 애플리케이션들은 설령 동일한 포트 번호를 사용하더라도 전혀 문제가 되지 않습니다. 예를 들어, 파드 A의 웹 서버가 80번 포트를 사용하고, 파드 B의 또 다른 웹 서버도 80번 포트를 사용할 수 있는 것입니다. 이는 기존 애플리케이션들을 컨테이너화하여 쿠버네티스로 이전(마이그레이션)하는 작업을 매우 용이하게 만들어 줍니다.

다만, 여기서 아주 중요한 주의사항이 있습니다. 바로 파드에 할당되는 IP 주소는 일반적으로 영구적이지 않다는(non-persistent, ephemeral) 사실입니다. 파드는 그 특성상 언제든지 사라지거나 새로 생성될 수 있습니다. 예를 들어, 파드가 실행 중이던 노드에 장애가 발생하여 다른 노드로 파드가 옮겨가거나, 디플로이먼트(Deployment)와 같은 상위 컨트롤러에 의해 애플리케이션 업데이트가 진행되어 기존 파드가 삭제되고 새 파드가 생성되거나, 혹은 오토스케일링에 의해 파드의 개수가 변동되는 경우, 파드는 새로운 IP 주소를 할당받을 가능성이 매우 높습니다. 마치 이사를 가면 집 주소가 바뀌는 것처럼요.

이러한 파드 IP의 비영구적인 특성 때문에, 애플리케이션 간의 안정적이고 지속적인 통신을 위해서는 파드의 IP 주소를 직접 코드에 하드코딩하거나 설정 파일에 고정 값으로 사용하는 것을 피해야 합니다. 만약 그렇게 한다면, 대상 파드가 재시작될 때마다 통신이 끊어지고 수동으로 IP 주소를 갱신해야 하는 끔찍한 상황이 발생할 것입니다. 대신 쿠버네티스는 이러한 문제를 해결하기 위해 ‘서비스(Service)’라는 강력한 추상화 계층을 제공합니다. 서비스는 여러 파드 그룹에 대한 안정적인 단일 접근점(고정된 IP 주소와 DNS 이름)을 제공하여, 내부 파드들의 IP 주소가 변경되더라도 클라이언트가 항상 동일한 주소로 서비스에 접근할 수 있도록 해줍니다. 서비스에 대해서는 이 책의 다음 장에서 아주 자세하게 다루게 될 것이니 기대하셔도 좋습니다.

지금까지 우리는 파드의 기본적인 개념과 그 핵심 특징인 ‘하나 이상의 컨테이너 그룹’, ‘네트워크 및 스토리지 공유’, 그리고 ‘고유한 IP 주소 할당’에 대해 자세히 알아보았습니다. 특히 파드마다 고유한 IP가 할당된다는 점은 쿠버네티스 네트워킹의 기본 원리이며, 이를 통해 애플리케이션 배포와 통신이 간결해진다는 장점이 있지만, 동시에 IP 주소의 비영구성이라는 특성도 함께 이해하는 것이 중요합니다. 이 세 가지 특징은 파드가 왜 쿠버네티스의 가장 기본적인 배포 단위인지, 그리고 어떻게 컨테이너화된 애플리케이션을 효과적이고 유연하게 실행하고 관리할 수 있게 하는지를 이해하는 데 매우 중요한 열쇠가 됩니다. 이러한 탄탄한 개념들을 바탕으로, 다음 절에서는 파드가 생성되고 소멸하기까지의 여정인 ‘파드 생명 주기’와, 파드를 더욱 효과적으로 활용하기 위한 ‘파드 설계 패턴’에 대해 더 깊이 탐구해 보도록 하겠습니다.