[Kubernetes] Pod

워크로드, 워크로드 리소스, 파드의 관계

워크로드는 쿠버네티스 클러스터에서 실행되는 애플리케이션을 의미합니다. 즉, 우리가 배포하고 관리하려는 서비스나 프로그램 자체를 가리킵니다.

워크로드 리소스는 워크로드를 관리하는 객체입니다. 즉, 워크로드를 구성하고 파드를 생성하며 파드의 상태를 유지하는 역할을 합니다. ReplicaSet, Deployment, StatefulSet, DaemonSet, Job 등이 대표적인 워크로드 리소스입니다.

파드는 워크로드를 실행하는 최소 단위입니다. 하나의 파드에는 하나 이상의 컨테이너가 포함될 수 있으며, 이들은 공유 네트워크와 볼륨을 가지고 함께 실행됩니다.

파드란

파드는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위입니다.

파드는 하나 이상의 컨테이너를 포함하는 논리적인 그룹으로 공유된 네임스페이스, IP 주소, 볼륨을 통해 긴밀하게 연결되어 있습니다. 쿠버네티스는 파드를 최소 배포 단위로 정의하며, 이를 통해 컨테이너 오케스트레이션을 수행합니다. 파드는 컨테이너 오류 발생 시 자동 재시작, 스케줄링, 그리고 서비스 발견과 같은 기능을 제공합니다.

즉 파드의 특징은 다음과 같습니다.

• 공유 네트워크: 파드 내의 모든 컨테이너는 동일한 IP 주소와 네트워크 네임스페이스를 공유합니다.
• 공유 볼륨: 파드 내의 컨테이너는 동일한 볼륨을 마운트하여 데이터를 공유할 수 있습니다.
• 단일 호스트: 일반적으로 하나의 노드에 스케줄링됩니다.
• 비가용성: 파드가 실패하면, 파드 전체가 재생성됩니다.

파드의 사용

파드를 사용해야 하는 이유는 다음과 같습니다.

• 컨테이너 격리: 각 파드는 독립적인 네트워크와 볼륨을 가지므로, 다른 파드와의 간섭을 최소화할 수 있습니다.
• 자원 공유: 파드 내의 컨테이너는 자원을 공유하여 효율적으로 리소스를 활용할 수 있습니다.
• 스케줄링 단위: Kubernetes는 파드를 스케줄링의 기본 단위로 사용합니다.

 

쿠버네티스 클러스터의 파드는 두 가지 주요 방식으로 사용됩니다.

• 단일 컨테이너를 실행하는 파드: "파드 당 하나의 컨테이너" 모델은 가장 일반적인 쿠버네티스 유스케이스입니다. 이 경우, 파드를 단일 컨테이너를 둘러싼 래퍼(wrapper)로 생각할 수 있고 쿠버네티스는 컨테이너를 직접 관리하는 대신 파드를 관리하게 됩니다.
• 함께 작동해야 하는 여러 컨테이너를 실행하는 파드: 파드는 밀접하게 결합되어 있고 리소스를 공유해야 하는 함께 배치된 여러 개의 컨테이너로 구성된 애플리케이션을 캡슐화할 수 있습니다. 함께 배치된 컨테이너는 하나의 결합된 서비스 단위를 형성합니다. 예를 들어, 하나의 컨테이너는 공유 볼륨에 저장된 데이터를 퍼블릭에 제공하는 반면, 별도의 사이드카 컨테이너는 해당 파일을 새로 고치거나 업데이트합니다. 파드는 이러한 컨테이너, 스토리지 리소스, 임시 네트워크 ID를 단일 단위로 함께 래핑합니다.

또한 일부 파드는 애플리케이션 컨테이너 외에도 초기화 작업을 수행하는 초기화 컨테이너를 포함할 수 있습니다. 초기화 컨테이너는 애플리케이션 컨테이너가 시작되기 전에 미리 실행되어 필요한 초기 설정 작업을 수행합니다.

파트를 구성하는 yaml은 다음과 같습니다.

apiVersion: v1 # 쿠버네티스 api version
kind: Pod # 
metadata: # 설명하기 위한 정보
  labels:
    run: po-nginx
  name: po-nginx
spec: # pod가 배포됐을 때 원하는 동작을 작성
  containers:
  - image: nginx
    name: nginx
    port:
    - containerPort: 8080

일반적으로 파드를 직접 만들지 않고 디플로이먼트(Deployment) 또는 잡(Job)과 같은 워크로드 리소스를 사용하여 생성합니다. 파드가 상태를 추적해야 한다면 스테이트풀셋(StatefulSet) 리소스를 고려합니다.

파드 서비스 품질(QoS) 구성

쿠버네티스가 파드를 생성할 때, 파드에 다음의 QoS 클래스 중 하나를 할당합니다.

• Guaranteed
• Burstable
• BestEffort

Guaranteed QoS 클래스

Guaranteed QoS 클래스의 할당을 위한 전제 조건은 다음과 같습니다.

• 파드 내 모든 컨테이너는 메모리 상한과 메모리 요청량을 가지고 있어야 함
• 파드 내 모든 컨테이너의 메모리 상한이 메모리 요청량과 일치해야 함
• 파드 내 모든 컨테이너는 CPU 상한과 CPU 요청량을 가지고 있어야 함
• 파드 내 모든 컨테이너의 CPU 상한이 CPU 요청량과 일치해야 함

이러한 제약은 초기화 컨테이너와 앱 컨테이너 모두 동일하게 적용됩니다.

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"

Burstable QoS 클래스

Burstable QoS 클래스의 할당을 위한 전제 조건은 다음과 같습니다.

• 파드가 Guaranteed QoS 클래스 기준을 만족하지 않음
• 파드 내에서 최소한 하나의 컨테이너가 메모리 또는 CPU 요청량/상한을 가짐

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-2
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-2-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

BestEffort QoS 클래스

BestEffort QoS 클래스의 할당을 위한 전제 조건은 다음과 같습니다.

• 파드의 컨테이너에 메모리와 CPU에 대한 상한이나 요청량이 없어야 함

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-3
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-3-ctr
    image: nginx

컨테이너가 두 개 이상인 경우

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-4
  namespace: qos-example
spec:
  containers:

  - name: qos-demo-4-ctr-1
    image: nginx
    resources:
      requests:
        memory: "200Mi"

  - name: qos-demo-4-ctr-2
    image: redis

이 파드는 Burstable QoS 클래스의 기준을 충족합니다. 즉, Guaranteed QoS 클래스에 대한 기준을 충족하지 않으며, 해당 컨테이너 중 하나가 메모리 요청량을 갖기 때문입니다.

OOM 발생 가능성을 낮추는 방법

OOM 발생 가능성을 낮추기 위해선 Guaranteed QoS 클래스로 설정해야 합니다.

resources:
  requests:
    memory: "128Mi"
    cpu: "500m"
  limits:
    memory: "256Mi"
    cpu: 2

resources:
  requests:
    memory: "128Mi"
    cpu: 2
  limits:
    memory: "128Mi"
    cpu: 2

requests와 limits의 역할은 다음과 같습니다.

• requests
  • 파드가 정상적으로 작동하기 위해 필요한 최소 메모리 양을 의미
  • 스케줄러는 파드를 배치할 때 이 값을 기준으로 노드를 선택
• limits
  • 파드가 사용할 수 있는 최대 메모리 양을 의미
  • 파드가 이 값을 초과하여 메모리를 사용하려고 하면 OOM Killer가 작동하여 해당 파드가 강제 종료

그렇다면 왜 requests와 limits를 동일하게 설정해야 할까요?

• 메모리 할당의 정확성
  • requests와 limits를 동일하게 설정하면 파드가 사용할 수 있는 메모리 양이 정확하게 정해지기 때문에 다른 파드와의 메모리 경쟁을 최소화할 수 있음
• OOM Killer 작동 방지
  • limits를 넘어서 메모리를 사용하는 파드는 OOM Killer의 대상이 되어 강제 종료됩니다. requests와 limits를 동일하게 설정하면 파드가 limits를 초과할 일이 없으므로 OOM Killer가 작동할 가능성이 현저히 줄어듦
• 자원 예측의 정확성
  • 각 파드에 할당된 메모리 양을 정확하게 파악할 수 있으므로 클러스터 전체의 자원 사용량을 예측하고 관리하기가 쉬워짐

왜 limits를 더 크게 설정하면 OOM이 발생할 가능성이 더 높을까요?

• 메모리 초과 사용 가능성
  • limits를 requests보다 크게 설정하면 파드가 requests 이상의 메모리를 사용할 수 있게 됨. 만약 모든 파드가 limits까지 메모리를 사용하게 된다면 시스템 전체의 메모리가 부족해져 OOM이 발생할 수 있음
• 예측 불가능한 메모리 사용
  • 파드의 메모리 사용량이 변동될 수 있는데, limits를 크게 설정하면 예상치 못한 메모리 사용량 증가로 인해 OOM이 발생할 가능성이 높아짐

결론적으로, requests와 limits를 동일하게 설정하면 파드가 사용할 수 있는 메모리 양을 정확하게 제한하여 OOM 발생 가능성을 최소화할 수 있습니다. 이는 클러스터의 안정성과 예측 가능성을 높이는 데 기여합니다.

파드 작업

파드 템플릿

파드를 관리하는 워크로드 리소스는 크게 디플로이먼트, 스테이트풀셋, 데몬셋이 있습니다. 이러한 리소스들은 파드템플릿을 사용합니다.

파드 템플릿을 수정하거나 새로운 파드 템플릿으로 바꿔도 이미 존재하는 파드에는 직접적인 영향을 주지 않습니다. 워크로드 리소스의 파드 템플릿을 변경하는 경우, 해당 리소스는 수정된 템플릿을 사용하는 대체 파드를 생성해야 합니다.

레퍼런스

https://kubernetes.io/ko/docs/concepts/workloads/pods/

https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/

https://coffeewhale.com/kubernetes/mistake/2020/11/29/mistake-10/