[kubernetes] PDB(pod disruption Budget)에 대해 알아보자!

Pod Disruption Budget(PDB)는 Kubernetes에서 Pod의 최소 가용성을 보장하거나 허용 가능한 비정상 Pod의 최대 수를 제한하기 위해 사용되는 설정입니다.
이 설정은 클러스터에서 Pod의 강제적인 중단(disruption)이 발생할 경우, 애플리케이션이 일정 수준 이상의 서비스를 유지하도록 보장합니다.

---

1. PDB의 필요성

Pod 중단은 다양한 이유로 발생할 수 있습니다:

• 클러스터 관리 작업:
  • 노드 업데이트, 스케일링, 유지보수.
• 자동 스케일링:
  • 클러스터 오토스케일러에 의해 노드가 축소되는 경우.
• Pod 재배치:
  • 새로운 설정 적용을 위해 Pod를 재배치.

이런 경우 PDB는 중단 가능한 Pod의 수를 제한하여 애플리케이션이 과도하게 중단되지 않도록 합니다.

---

2. PDB의 동작 방식

PDB는 **강제 중단(disruption)**이 허용되는 Pod의 수를 정의합니다. Kubernetes는 PDB를 참조하여 아래 작업 시 중단 가능성을 판단합니다:

• kubectl drain 명령어로 노드를 비울 때.
• 클러스터 오토스케일러가 노드를 축소할 때.

PDB는 아래와 같은 두 가지 기준 중 하나를 설정합니다:

1. 최소 가용 Pod 수 (minAvailable):
   • 항상 실행 중이어야 하는 최소 Pod 수를 정의.
2. 최대 비가용 Pod 수 (maxUnavailable):
   • 동시에 중단될 수 있는 최대 Pod 수를 정의.

---

3. PDB의 예제

a. 최소 가용 Pod 수 설정 (minAvailable)

apiVersion: policy/v1

kind: PodDisruptionBudget

metadata:

  name: example-pdb

spec:

  minAvailable: 2

  selector:

    matchLabels:

      app: example

• 의미:
  • app: example 라벨이 있는 Pod 중에서 최소 2개는 항상 실행 중이어야 함.
  • 만약 현재 실행 중인 Pod이 2개뿐이라면, 추가 중단은 허용되지 않음.

---

b. 최대 비가용 Pod 수 설정 (maxUnavailable)

apiVersion: policy/v1

kind: PodDisruptionBudget

metadata:

  name: example-pdb

spec:

  maxUnavailable: 1

  selector:

    matchLabels:

      app: example

• 의미:
  • app: example 라벨이 있는 Pod 중에서 최대 1개만 비가용 상태가 될 수 있음.
  • 만약 Pod이 3개가 실행 중이라면, 동시에 중단될 수 있는 Pod은 최대 1개로 제한.

---

4. PDB와 관련된 개념

a. 자발적 중단 (Voluntary Disruption)

• 예: 관리자가 노드를 kubectl drain 명령어로 비우는 경우.
• Kubernetes는 PDB를 준수하여 중단 가능한 Pod의 수를 제한.

b. 비자발적 중단 (Involuntary Disruption)

• 예: 노드 장애, 네트워크 오류, 하드웨어 문제 등.
• 이러한 경우 PDB는 적용되지 않습니다.
• Kubernetes는 복구 작업을 수행하지만, PDB는 강제 적용되지 않음.

---

5. PDB의 활용 사례

1. 애플리케이션 안정성 보장:
   • 다수의 Replica를 가진 애플리케이션에서 최소 가용성을 유지.
2. 유지보수 작업 중 서비스 지속성:
   • 노드 드레인(drain) 작업 중에도 서비스의 가용성을 보장.
3. 배포 전략 관리:
   • 롤링 업데이트와 같은 배포 작업 시 과도한 중단 방지.

---

6. PDB의 한계

1. 적용 범위:
   • PDB는 강제 중단(disruption)에만 적용되며, 비자발적 중단에는 영향을 미치지 않습니다.
2. 복잡성 증가:
   • 클러스터에서 여러 워크로드가 복잡하게 구성된 경우, PDB 설정이 충돌하거나 관리 부담이 될 수 있음.
3. 스케줄링 지연:
   • PDB 제한이 너무 엄격하면 노드 드레인 또는 Pod 재배치 작업이 지연될 수 있음.

---

7. 결론

Pod Disruption Budget은 Kubernetes 클러스터에서 Pod 가용성을 보장하기 위한 중요한 도구입니다.
적절한 PDB 설정을 통해 유지보수 작업이나 자동 스케일링 중에도 애플리케이션의 안정성을 유지할 수 있으며, 서비스 중단을 최소화할 수 있습니다. 하지만 비자발적 중단에 대한 보호는 제공하지 않으므로, 이와 함께 Pod 재시작 정책 및 복구 전략도 고려해야 합니다.

 

 

 

 

그런데 HPA와 조금 비슷한 기능인것같은데 비교해보자 

 

 

HPA와 PDB의 차이점

기능	HPA	PDB
목적	부하에 따라 Pod의 수를 자동으로 확장/축소	Pod 강제 중단을 제한하여 가용성을 보장
적용 대상	애플리케이션의 성능 최적화	클러스터 유지보수 및 관리 작업 시 안정성 확보
작동 방식	CPU/메모리 사용량 등 메트릭 기반 확장	노드 드레인 등 강제 중단(disruption) 제어
중단(disruption) 관리	중단에 직접 관여하지 않음	강제 Pod 중단을 허용하지 않거나 제한

---

왜 HPA로는 PDB의 역할을 대체할 수 없는가?

1. HPA는 Pod 중단 시 가용성을 보장하지 못함:
   • HPA는 트래픽 증가 또는 리소스 사용량 상승에 따라 Pod의 개수를 확장합니다.
   • 그러나 Pod이 강제로 종료되는 상황(예: 노드 드레인, 클러스터 업그레이드)에서는 HPA가 직접적으로 영향을 미치지 않습니다.
   • 이로 인해 특정 시점에 Pod의 개수가 지나치게 줄어들어 애플리케이션이 불안정해질 수 있습니다.

---

1. HPA는 강제 중단에 대한 방어 기능이 없음:
   • HPA는 CPU, 메모리 등 리소스 사용량을 기준으로 Pod 수를 조정하지만, Pod 강제 중단 상황에서는 동작하지 않습니다.
   • 예를 들어, 클러스터 관리자가 노드를 드레인하거나 클러스터 오토스케일러가 노드를 축소할 때, HPA는 중단된 Pod의 가용성을 보장하지 못합니다.
   • PDB는 이러한 상황에서도 최소 가용 Pod 수를 보장합니다.

---

1. HPA는 관리 작업의 영향을 고려하지 않음:
   • 노드 드레인, 클러스터 업그레이드와 같은 관리 작업 시 Pod이 동시에 종료될 가능성이 있습니다.
   • HPA는 이런 작업을 인식하지 못하며, 관리 작업으로 인해 발생하는 Pod의 중단을 제어할 수 없습니다.
   • PDB는 관리 작업과 Pod 가용성을 조율하여 중단을 최소화합니다.

---

HPA와 PDB의 보완적인 역할

예제: HPA와 PDB 동시 사용

• HPA: 트래픽 증가 시 Pod을 자동으로 확장하여 서비스 성능을 유지.
• PDB: 클러스터 업그레이드, 노드 드레인 등 관리 작업 중 최소 가용성을 보장.

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:

  name: example-hpa

spec:

  scaleTargetRef:

    apiVersion: apps/v1

    kind: Deployment

    name: example

  minReplicas: 2

  maxReplicas: 10

  metrics:

    - type: Resource

      resource:

        name: cpu

        target:

          type: Utilization

          averageUtilization: 50

---

apiVersion: policy/v1

kind: PodDisruptionBudget

metadata:

  name: example-pdb

spec:

  minAvailable: 2

  selector:

    matchLabels:

      app: example

시나리오:

• HPA는 CPU 사용량이 증가하면 Pod을 10개까지 확장합니다.
• 동시에 PDB는 최소 2개의 Pod이 항상 가용하도록 보장하여 관리 작업 중에도 애플리케이션이 중단되지 않도록 합니다.

---

PDB의 필요성이 두드러지는 상황

1. 노드 유지보수:
   • 클러스터 관리자가 특정 노드를 드레인하거나 업그레이드해야 할 때, Pod이 한꺼번에 중단되는 것을 방지.
2. 클러스터 오토스케일링:
   • 클러스터 오토스케일러가 노드를 축소하면서 Pod을 강제로 종료할 수 있는 상황에서 최소 가용성을 보장.
3. 고가용성 서비스:
   • 특정 수의 Pod이 항상 가동 중이어야만 정상 동작하는 애플리케이션(예: 데이터베이스 클러스터, 캐싱 서버).
4. 리소스 부족 시 안정성 확보:
   • HPA가 동작하기 전에 리소스 부족으로 Pod이 종료될 가능성을 PDB로 제한.

---

결론

• HPA는 부하에 따라 확장성과 효율성을 제공하지만, Pod 중단 상황을 직접 제어하지 못합니다.
• PDB는 Pod의 최소 가용성을 보장하여 관리 작업이나 강제 중단 상황에서도 애플리케이션 안정성을 유지합니다.
• 두 기능은 상호 보완적이며, 안정성과 확장성을 동시에 유지하려면 함께 사용하는 것이 가장 효과적입니다.