| 개인적으로 공부하는 관점에서 작성한 내용이라, 잘못된 부분이 있을 수 있습니다. 발견 시 말씀주시면 감사하겠습니다. |

kubernetes에서 v1.21 이후부터 제공되는 PodDisruptionBudget(이하 PDB) 에 대해 알아보도록 하자.
사실 kubernetes 내에 제공하는 "PDB" 라는 '기능'에 대해 단순히 알아보려다가, 이게 "왜 필요한지?"부터 쫓아가다보니 깊게 생각해야 하는 요소들이 많아서 아래와 학습한 내용 등을 정리한다.
Disruption (중단)과 대응 그리고 PDB
우선 쉽게 말하면 PDB는, kuberntes 위에서 동작되는 워크로드들에 대해 가용성(HA) 을 보장하기 위해 제공하는 기능이라고 이해하면 된다. (물론 이 한줄로만은 이해가 쉽지 않다.)
그리고 PDB를 이해하려면, 결국 kubernetes에서 Disruption(중단) 에 대해 먼저 알고 있어야 한다. 따라서 먼저 kubernetes 상에서 "Disruption"에 대한 의미를 먼저 알아보자.
자발적인 중단, 비자발적인 중단
Disruption을 한국어로 번역하면 말 그대로 '중단'이다. 그리고 이 '중단'은 다시 자발적인 중단(voluntary disruptions) 과 비자발적인 중단(involuntary disruptions) 으로 나눠서 구분할 수 있다.
먼저 '비자발적인 중단'의 경우 관리자 등에 의해 의도적이 아닌, 쉽게 말해 '장애' 상태로 예를 들어보면 Node 역할을 하는 Hardware의 물리적인 Failure, 커널 패닉, 네트워크 단절 등이 예가 될 수 있을 것 같다.
반면 '자발적인 중단'의 경우 애플리케이션 소유자 or 클러스터 관리자 등에 의해 의도적으로 수행하는 작업 등으로 인해 발생하는 중단이다. 만약 '애플리케이션 소유자'에 의해 발생하는 '중단'의 예시로는 당연하게도 Pod Restart, Update, Delete 등이 있을 수 있다. '클러스터 관리자'에 의해 발생하는 '중단'의 경우에는 클러스터 및 노드 레벨로서, 예를 들어보면 OS 패키지 업그레이드, 네트워크 작업 등을 꼽을 수 있다. 다만 이경우에는 대부분 필연적으로 "작업 대상 Node 의 Drain" 을 선행하게 된다. (그리고 이게 PDB와 관련이 있다!)
중단에 '대응'하기 (with PDB)
그리고 이제 이러한 자발적 혹은 비자발적 '중단'에 '잘' 대응하는 워크로드를 구성하기 위해서 알아보자.
먼저, 사실 '비자발적 중단'의 경우 의도적이지 않은 사실상 "예측할 수 없는 장애의 상황"으로서 완전히 막을 수는 없다. 다만 이러한 상황 등을 '완화'하기 위해서는 Pod 레벨에서 동작이 필요한 리소스를 보장하고, 워크로드를 HA 구조로 배포하기, Anti Affinity 와 AZ와 같은 스케줄링 전략을 가지고 워크로드를 잘 구성하는 등의 전략과 실행이 필요한 영역이다.
반면 '자발적인 중단'의 경우에는, 이 글의 주제인 'PDB'와 관련이 있다. 하지만 그 전에, 일단 워크로드가 실행되는 Kubernetes Cluster가 "어떤 기반의 Cluster 인가?"에 따라 PDB의 필요성 자체가 없을 수도 있다.
예를 들어, On-Premise 환경(혹은 순수한 kubernetes)에서는 별도로 클러스터 관리자가 구성하지 않았다는 가정하에 "자동화 된 자발적인 중단"이 딱히 없다. 다르게 말하면 자동으로 Node가 Drain 될 일이 없다. (장애와 같은 '비자발적인 중단' 제외) 그렇기 때문에 별도로 자발적 중단에 대해 계획하기 전까지, PDB 구성이 딱히 필요하지 않을 수도 있다.
다만, '자발적인 중단'이 꼭 클러스터 관리자에 의한 수동으로 Node drain 만 의미하는 것이 아니며, 각각의 클러스터의 운영 정책과 이에 따른 자동화 작업과 같이 "언제든지 발생할 수 있는 이벤트"이다. 따라서 비록 On-Premise 환경의 kubernetes 라 하더라도 중요한 운영 환경인 경우 등에 PDB의 구성이 필요할 수 있다.
반면에 kubernetes Cluster가 EKS와 같은 "Managed 클러스터"에 실행된다면, Cloud 공급자(ex. AWS, GCP)에 의해 자동적으로 자발적 중단이 발생할 수 있다. (ex. Node의 OS 업데이트, kubelet 업데이트)
물론 이러한 경우 Cloud 공급자들은 언제 이러한 중단이 발생하는지에 대해 문서화를 잘 해서, 해당 클러스터 관리지와 워크로드 담당자들이 이를 잘 대비할 수 있게 해야 한다. 그리고 바로 이때 워크로드의 가용성 등을 대비하기 위해서 본 글의 주요 목적인 "PDB" 구성이 필요한 것이다.
다음편 :: https://aoc55.tistory.com/78
'Cloud > kubernetes (k8s)' 카테고리의 다른 글
| k8s :: PodDisruptionBudget (PDB)과 Disruption (#2) (0) | 2025.10.18 |
|---|---|
| k8s :: k8s Security - 10 Best Practices (0) | 2025.10.02 |
| k8s :: kata container (v3) 설치 해보기 with k8s - #2 (0) | 2025.08.20 |
| k8s :: kata container (v3) 설치 해보기 with k8s - #1 (0) | 2025.08.19 |
| IT서적후기 :: 쿠버네티스 오퍼레이터 (8) | 2024.09.04 |