[kubernetes] Pod

Kubernetes에서 Pod은 애플리케이션의 가장 작은 배포 단위이다. 컨테이너(Container)를 실행하는 기본 단위로, 컨테이너 그룹을 의미한다. Pod은 하나 이상의 컨테이너를 포함할 수 있으며, 이 안에 있는 컨테이너는 네트워크와 스토리지를 공유하고, 같은 Node에서 실행된다. Kubernetes는 컨테이너를 관리하지 않고, Pod로 추상화했다. 

 

Static Pod 

정적 파드(Static Pod)는 Kubernetes에서 일반적인 Pod과는 다르게 Kubelet이 직접 관리하는 특수한 형태의 Pod이다. 이는 주로 클러스터 관리용 시스템 구성 요소를 실행하거나 특정 노드에 고정된 Pod을 생성할 때 사용된다. 예를 들어, etcd, kube-apiserver, kube-controller-manager와 같은 컴포넌트는 클러스터의 안정적인 동작을 보장하기 위해 특정 노드에서 실행된다. 이러한 구성 요소들은 정적 파드로 정의되어 클러스터 외부 장애 상황에서도 지속적으로 작동합니다. 또한 kubelete에서 참조하는 디렉토리에 있는 YAML 파일로 관리되며, 직접 정적 파드를 삭제할때는 (/etc/kubernetes/manifests) 의 파일경로로 가서 YAML 파일을 삭제해주어 한다. 반대로 정적 파드를 만들떄는 경로로가서 YAML 파일을 작성해주면 된다. 
정적 파드가 실행되면 Kubernetes는 이를 클러스터 API에서 볼 수 있도록 Mirror Pod를 생성하는데 이는 주로 Mirror Pod의 상태를 볼때 주로 확인하며, 이는 읽기 전용이다. 

쿠버네티스에서 파드는 보통 직접 생성하는 대신, Deployment, Job, StatefulSet과 같은 워크로드 리소스를 사용하여 생성한다. 이러한 리소스들은 파드를 생성하고 관리하는 역할을 한다. 특히, 상태를 관리해야 하는 경우에는 StatefulSet을 사용하는 것이 적합한 예시이다. 

Pause Container 

쿠버네티스에서 Pause Container는 일반적으로 파드가 실행될 때 초기화 컨테이너나 비어 있는 상태로 존재하는 특수한 역할을 하는 컨테이너이다. 이 컨테이너는 파드의 네트워크 네임스페이스만을 유지하며, 주로 네트워크 환경 설정을 관리하는 역할을 한다. Pause Container는 실제로 애플리케이션을 실행하지 않으며, 주로 컨테이너의 네트워크 환경을 초기화하고 다른 컨테이너들이 해당 네트워크 환경에서 실행될 수 있도록 하는데 사용된다. 즉 파드 내의 애플리케이션 컨테이너가 종료되더라도 Pause Container는 계속 실행되어 파드의 상태를 유지하게 된다. 이를 통해 파드의 네트워크 환경이 끊어지지 않도록 하며, 다른 컨테이너가 정상적으로 통신할 수 있게 도와줍니다.

Kubernetes에서 Pause Container는 파드가 생성될 때 자동으로 생성되며, 주로 docker나 containerd와 같은 컨테이너 런타임에서 사용된다. 예를 들어, 파드 내의 여러 컨테이너가 동일한 네트워크 네임스페이스를 공유해야 하는 경우, Pause Container가 해당 네트워크 네임스페이스를 유지하고 다른 컨테이너들이 이를 사용할 수 있도록 한다. 즉 container를 기술적으로 구현하기 위해서 사용하는 Kernel 기술인 cgroups, namsepace에서의 namespace를 의미한다. 

Initial container

 

Pod에 대한 모든 네트워킹 및 스토리지가 프로비저닝된 후에 실행하는 컨테이너이다. Pod의 initial container가 실패하면 kublet은 성공할 때까지 해당 init 컨테이널를 반복적으로 재시작한다. 단, Pod restartPolicy: Never가 지정되었다면, 해당 Pod를 시작하는 동안 initial container가 실패하면 Kubernetes는 전체 Pod를 실패한 것으로 처리 뒤 종료한다. 
주로 MSA 애플리케이션 원격지의 소스로부터 최신 구성 파일을 가져오는 작업을 구성하면 initial container에 의해 애플리케이션 컨테이너는 항상 최신 구성 파일을 사용할 수 있다. 데이터베이스를 초기화하거나 애플리케이션 컨테이너가 연결되기 전에 초기 데이터를 채우는 작업을 구성하면 initail container 는 스키마 생성이나 데이터 마이그레이션과 같은 데이터베이스 설정 작업을 처리하여 데이터베이스가 애플리케이션 컨테이너와 상호 작용할 준비가 되었는지 확인할 수 있다. 

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  initContainers:
  - name: download-init-data
    image: busybox:1.35
    command: ["sh", "-c", "echo 'Downloading initial data...' && sleep 5"]
    volumeMounts:
    - name: app-data
      mountPath: /data
  containers:
  - name: my-app-container
    image: my-app:latest
    ports:
    - containerPort: 8080
    volumeMounts:
    - name: app-data
      mountPath: /app/data
  volumes:
  - name: app-data
    emptyDir: {}

Singleton Pod 

싱글톤 파드는 단일 컨테이너를 실행하는 파드이다. 쿠버네티스에서 가장 일반적인 방식으로, 하나의 파드에 하나의 컨테이너만 배치된다. 이 모델은 "파드 당 하나의 컨테이너"라는 규칙을 따르며, 주로 단일 애플리케이션을 실행하는 경우에 사용된다. 파드는 컨테이너를 관리하는 최소 단위로, 파드가 관리하는 컨테이너는 항상 하나만 존재한다. 

Multi-Container Pod

멀티 컨테이너 파드는 여러 컨테이너가 하나의 파드에 배치되는 모델이다. 이 모델은 주로 밀접하게 결합된 여러 컨테이너들이 하나의 애플리케이션을 구성하는 경우에 사용된다. 각 컨테이너는 서로 다른 역할을 하며, 동일한 리소스를 공유할 수 있다. 이러한 컨테이너들은 같은 네트워크와 저장소를 사용하고, 서로 통신할 수 있는 환경에서 실행된다. 예를 들어, 하나의 컨테이너는 웹 서버 역할을 하고 다른 컨테이너는 로그를 수집하거나 데이터를 처리하는 역할을 하는 "사이드카 패턴" 을 볼 수 있다. 또한, 같은 파드 내에 있는 컨테이너들은 네트워크와 볼륨 같은 리소스를 공유한다.

 

파드 내에는 하나의 주요 애플리케이션만 있어야 하며, 다른 컨테이너들은 보조적인 역할을 해야 한다. 예를 들어, 웹 서버를 주 애플리케이션으로 두고, 그 웹 서버의 로그를 수집하여 외부 시스템에 보내는 보조 애플리케이션이 있을 수 있다. 

또한, 파드는 항상 하나의 노드에 배치된다. 즉, 파드 안에 여러 컨테이너가 있더라도, 이 컨테이너들은 모두 동일한 노드에서 실행된다는 것이다. 

따라서 파드를 설계할 때에는 하나의 파드가 하나의 주요 서비스만을 담당하도록 구성하는 것이 중요하며, 여러 주요 서비스를 하나의 파드에 배치하는 것을 조심해야한다. 

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: main-app
    image: my-app-image
    ports:
    - containerPort: 8080
  - name: log-collector
    image: fluentd
    volumeMounts:
    - mountPath: /var/log
      name: log-volume
  volumes:
  - name: log-volume
    emptyDir: {}