Pod 개요
Pod는 Kubernetes에서 가장 작은 API 단위입니다. 더 기술적으로 말하면, Pod는 Kubernetes의 원자적 스케줄링 단위입니다. 그런데 왜 Pod가 필요할까요? 이 질문에 답하기 위해 먼저 컨테이너의 본질을 이해해야 합니다. 컨테이너는 본질적으로 프로세스입니다. 맞습니다. 컨테이너는 클라우드 컴퓨팅 시스템의 프로세스이며, 컨테이너 이미지는 본질적으로 이 시스템의 ‘.exe’ 설치 패키지입니다. 이 비유에서 Kubernetes는 운영 체제 역할을 합니다.
프로세스와 프로세스 그룹
Linux 머신에 로그인하여 다음 명령을 실행해 보겠습니다:
$ pstree -g
이 명령은 시스템에서 현재 실행 중인 프로세스의 트리 구조를 표시합니다. 출력은 다음과 같을 수 있습니다:
systemd(1)-+-accounts-daemon(1984)-+-{gdbus}(1984)
| `-{gmain}(1984)
|-acpid(2044)
...
|-lxcfs(1936)-+-{lxcfs}(1936)
| `-{lxcfs}(1936)
|-mdadm(2135)
|-ntpd(2358)
|-polkitd(2128)-+-{gdbus}(2128)
| `-{gmain}(2128)
|-rsyslogd(1632)-+-{in:imklog}(1632)
| |-{in:imuxsock) S 1(1632)
| `-{rs:main Q:Reg}(1632)
|-snapd(1942)-+-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
보시다시피 실제 운영 체제에서 프로세스는 격리되어 실행되지 않습니다. 대신 프로세스 그룹으로 구성됩니다. 예를 들어, “rsyslogd” 프로그램은 Linux에서 로그 처리를 담당합니다. rsyslogd의 메인 프로그램인 "main"과 그것이 사용하는 커널 로그 모듈 "imklog"는 프로세스 그룹 1632에 속합니다. 이 프로세스들은 협력하여 rsyslogd 프로그램의 책임을 수행합니다. Kubernetes는 본질적으로 이 “프로세스 그룹” 개념을 컨테이너 기술에 매핑하고 이를 이 클라우드 컴퓨팅 "운영 체제"의 "일등 시민"으로 만듭니다. Kubernetes가 이 접근 방식을 채택한 이유는 Google 엔지니어들이 그들이 배포한 애플리케이션들이 종종 "프로세스와 프로세스 그룹"과 유사한 관계를 보인다는 것을 깨달았기 때문입니다. 구체적으로, 이러한 애플리케이션들은 긴밀한 협업이 필요하여 동일한 머신에 배포해야 했습니다. “그룹” 개념 없이 이러한 운영 관계를 관리하는 것은 매우 어려울 것입니다. rsyslogd를 예로 들어 보겠습니다. 이는 세 개의 프로세스로 구성됩니다: imklog 모듈, imuxsock 모듈, 그리고 rsyslogd 자체의 메인 함수 프로세스입니다. 이 세 프로세스는 동일한 머신에서 실행되어야 합니다. 그렇지 않으면 소켓 기반 통신과 파일 교환에 문제가 발생합니다.
컨테이너 간 통신
위 다이어그램에서 볼 수 있듯이, 이 Pod는 두 개의 사용자 컨테이너 A, B와 Infra 컨테이너를 포함합니다. Kubernetes에서 Infra 컨테이너는 최소한의 리소스를 소비하도록 설계되었으며 "k8s.gcr.io/pause"라는 특별한 이미지를 사용합니다. 이 이미지는 어셈블리 언어로 작성된 컨테이너로, 영구적으로 “일시 정지” 상태를 유지하며 압축되지 않은 크기는 100–200KB에 불과합니다. Infra 컨테이너가 Network Namespace를 "보유"하면 사용자 컨테이너가 이 네임스페이스에 참여할 수 있습니다. 따라서 호스트 머신에서 이 컨테이너들의 Namespace 파일(이 파일의 경로는 앞서 언급했습니다)을 검사하면 동일한 값을 가리키게 됩니다. 즉, Pod 내의 컨테이너 A와 B는 "localhost"를 사용하여 직접 통신할 수 있습니다. 그들은 Infra 컨테이너와 동일한 네트워크 장치를 인식합니다. Pod는 하나의 IP 주소만 가지며, 이는 Pod의 Network Namespace와 연결된 IP 주소입니다. 당연히 다른 모든 네트워크 리소스는 Pod별로 할당되며 해당 Pod 내 모든 컨테이너가 공유합니다. Pod의 수명 주기는 오직 Infra 컨테이너에 연결되어 있으며 컨테이너 A와 B와는 독립적입니다. 또한 같은 Pod 내의 모든 사용자 컨테이너에 대해 들어오고 나가는 트래픽은 Infra 컨테이너를 통과하는 것으로 간주할 수 있습니다. 이 측면은 중요합니다. 왜냐하면 향후 Kubernetes용 네트워크 플러그인을 개발한다면, 주요 초점은 각 사용자 컨테이너가 네트워크 구성을 어떻게 사용하는지가 아니라 Pod의 Network Namespace를 구성하는 데 있어야 하기 때문입니다. 후자는 중요하지 않습니다. 이는 네트워크 플러그인이 컨테이너 내에 패키지나 구성을 설치하는 데 의존한다면 실행 가능한 솔루션이 아님을 의미합니다. Infra 컨테이너 이미지의 루트 파일 시스템은 거의 비어 있어 사용자 정의할 여지가 없습니다. 반대로, 이는 네트워크 플러그인이 사용자 컨테이너의 시작 상태에 신경 쓸 필요 없이 오직 Pod, 즉 Infra 컨테이너의 Network Namespace를 구성하는 데만 집중하면 된다는 것을 의미합니다. 이 설계로 인해 볼륨 공유가 훨씬 간단해집니다. Kubernetes는 모든 볼륨 구성을 Pod 수준에서 정의할 수 있습니다. 결과적으로 볼륨에 해당하는 호스트 디렉터리는 Pod에 고유하며, Pod 내의 모든 컨테이너는 이 디렉터리를 마운트한다고 선언하기만 하면 됩니다. Pod 뒤에 있는 이 설계 철학은 컨테이너 간 "초긴밀 관계"를 조성하여 사용자가 단일 컨테이너에서 실행되는 여러 기능적으로 관련 없는 구성 요소가 있는 애플리케이션이 Pod 내의 여러 컨테이너로 더 잘 표현될 수 있는지 고려하도록 장려하는 것을 목표로 합니다. 이 사고 방식을 이해하려면 단일 컨테이너로 해결하기 어려운 시나리오에 적용해 보십시오. 예를 들어, 컨테이너 내의 “/var/log” 디렉터리에 지속적으로 로그 파일을 출력하는 애플리케이션이 있다고 가정해 보겠습니다. 이 경우 Pod 내에 볼륨을 애플리케이션 컨테이너의 “/var/log” 디렉터리에 마운트할 수 있습니다. 그런 다음 동일한 Pod 안에서 동일한 볼륨을 자체 “/var/log” 디렉터리에 마운트한다고 선언하는 사이드카 컨테이너를 실행합니다. 거기서 사이드카 컨테이너의 유일한 작업은 자체 “/var/log” 디렉터리에서 로그 파일을 지속적으로 읽고 MongoDB 또는 Elasticsearch와 같은 스토리지 솔루션으로 전달하는 것입니다. 이 설정은 기본적인 로그 수집 메커니즘을 구축합니다. 첫 번째 예와 유사하게, 이 시나리오에서 사이드카의 주요 기능도 공유 볼륨을 사용한 파일 작업에 중점을 둡니다. 그러나 Pod의 또 다른 중요한 특성을 간과하지 마십시오. Pod 내의 모든 컨테이너는 동일한 Network Namespace를 공유합니다. 이를 통해 Pod 네트워크와 관련된 많은 구성 및 관리 작업을 사이드카에 위임할 수 있으며, 사용자 컨테이너를 간섭할 필요가 완전히 없어집니다. 이에 대한 대표적인 예가 Istio 서비스 메시 프로젝트입니다.
요약
이 논의에서 우리는 Pod가 필요한 이유를 깊이 살펴보았습니다. 본질적으로 Pod는 Kubernetes 클러스터 내의 기본 단위로, 하나 이상의 컨테이너(일반적으로 Docker 컨테이너)를 캡슐화합니다. 이 컨테이너들은 네트워크 및 스토리지 리소스를 공유합니다. 프로세스 및 프로세스 그룹의 관점에서 Pod는 경량 프로세스 그룹으로 볼 수 있습니다. 이를 통해 긴밀하게 협력하는 여러 프로세스(컨테이너)를 하나의 단위로 배포, 확장 및 관리할 수 있어 복잡한 애플리케이션의 배포 및 운영이 간소화됩니다. 다음 글에서는 Pod에 대해 더 자세히 설명하겠습니다.
Novita AI 는 AI 야망을 실현하는 올인원 클라우드 플랫폼입니다. 원활하게 통합된 API, 서버리스 컴퓨팅, GPU 가속을 통해 AI 기반 비즈니스를 빠르게 구축하고 확장하는 데 필요한 비용 효율적인 도구를 제공합니다. 인프라 관련 문제를 없애고 무료로 시작하세요 - Novita AI가 여러분의 AI 꿈을 현실로 만듭니다.
추천 자료:
