Kubernetes Pod 이해하기

소개

Pod는 쿠버네티스의 가장 기본적인 구성요소입니다.
컨테이너 환경을 오케스트레이션하는 쿠버네티스 입장에서 Pod는 컨테이너를 관리하는 주체이기 때문입니다.
하나의 Pod는 하나 이상의 컨테이너를 구동시키며,
Pod에 속한 여러 컨테이너들은 Pod의 리소스를 공유하게 됩니다.

 

 

 

<pod yaml>

3개의 컨테이너를 가지는 Pod 의 yaml 입니다.

각각의 컨테이너 이미지는 nginx, mysql, minio 입니다.

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
  namespace: multi-container
  labels:
    app: multi-container
spec:
  containers:
    - name: container1
      image: nginx
      volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/
    - name: container2
      image: mysql
      env:
        - name: MYSQL_ROOT_PASSWORD
          value: root
    - name: container3
      image: minio/minio
      args:
        - server
        - --console-address
        - ":9001"
        - "/storage"
      env:
        - name: MINIO_ACCESS_KEY
          value: "minio"
        - name: MINIO_SECRET_KEY
          value: "minio123"
        - name: TZ
          value: Asia/Seoul
        - name: LANG
          value: ko_KR.utf8
      volumeMounts:
        - name: storage
          mountPath: "/storage"
  volumes:
    - name: html
      emptyDir: {}
    - name: storage
      emptyDir: { }

예를 들어,

Pod는 새롭게 생성될 때마다 하나의 ip 를 부여받게 되는데 컨테이너들은 Pod의 ip 를 공유합니다.

만약 Pod의 IP 주소 가 10.244.4.3 인 경우에 컨테이너들 또한 10.244.4.3 을 사용합니다.

 

NAME                  READY   STATUS    RESTARTS   AGE   IP           NODE           NOMINATED NODE   READINESS GATES
multi-container-pod   3/3     Running   0          53s   10.244.4.3   kind-worker2   <none>           <none>

< multi-container-pod 라는 Pod는 3개의 container들을 가지고, ip 는 10.244.4.3 을 할당받았습니다.>

 

각 container 의 ip 또한 10.244.4.3 으로 설정됩니다.

eth0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65535 qdisc noqueue state UP group default 
    link/ether 16:fd:56:f1:31:64 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.244.4.3/24 brd 10.244.4.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fd00:10:244:4::3/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::14fd:56ff:fef1:3164/64 scope link 
       valid_lft forever preferred_lft forever

 

그리고 파드가 가지는 볼륨을 공유할 수 있습니다.

하나의 파드 내의 여러 컨테이너들이 같은 볼륨을 공유하는 상황은

하나의 컨테이너가 데이터를 생성하고 다른 컨테이너가 데이터를 소비하는 상황이 있습니다.

ex) 1 크롤러와 2 크롤링된 컨텐츠 서버

 

 

컨테이너와 파드의 차이

그런데 컨테이너가 실질적인 작업의 실행을 담당하기 때문에 굳이 파드를 써야하는 의문이 생길 수 있습니다.

파드가 제공하는 ip 와 스토리지 기능이 아니더라도 컨테이너만  있어도 실질적인 기능은 동작할 것 같습니다.

 

파드는 컨테이너를 한번 더 감싸서 쿠버네티스의 구성요소로 만들어줍니다.

쿠버네티스를 선택된 CRI (Container Runtime Interface) 에 의해서 컨테이너를 관리하는데요.

컨테이너는 docker 나 containerd 처럼 컨테이너 런타임에 의해서 관리됩니다.

하지만 컨테이너 오케스트레이션을 담당하는 쿠버네티스의 관점에서 관리에 효율적인 방식으로 컨테이너를 추상화시킨 개념이 파드입니다.

 

파드는 아래와 같은 기능을 제공합니다.

 

1. 프로브 (Probe)

프로브는 kubelet 이 컨테이너의 상태를 체크하는 진단 프로세스입니다.

모든 파드들은 노드라는 서버에 존재하는데요. 노드는 물리적인 서버 또는 가상 서버를 의미합니다.

즉 하나의 인스턴스입니다.

그리고 모든 노드에는 하나의 kubelet 이 존재하는데 kubelet 이 컨테이너의 실행, 삭제, 수정, 진단 등의 작업을 수행합니다.

probe 는 컨테이너의 상태를 체크하여 재시작 정책에 따른 대응을 합니다.

 

2. affinity

파드들은 노드에 위치합니다.

파드가 노드에 할당되는 전반적인 개념을 파드 스케줄링이라고 하는데요.

파드가 필요로하는 리소스에 따라 해당 리소스를 감당할 수 있는 노드에 배치됩니다.

이러한 과정을 스케줄링이라고합니다.

다만, 파드 별로 특정 노드에 배치되거나 특정 노드에 배치되지 않아야하는 제약이 필요할 수 있습니다.

이러한 스케줄링에 대한 제약을 Affinity 라고합니다.

 

파드는 위와 같은 기능들을 내포하며 컨테이너 그 이상의 작업을 수행합니다.

그리고 파드는 쿠버네티스의 최소 구성 단위로써 쿠버네티스 클러스터에 의해서 관리됩니다.