일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- Kubernetes
- eBPF
- Kubernetes 인증
- serving
- gitops
- 오퍼레이터
- 카오스 엔지니어링
- Continuous Deployment
- blue/green
- argocd
- kubernetes operator
- operator
- Model Serving
- seldon core
- knative
- Litmus
- xdp
- keda
- opentelemetry
- CANARY
- mlops
- tekton
- Argo
- Kubeflow
- CI/CD
- opensearch
- Pulumi
- MLflow
- Kopf
- nginx ingress
- Today
- Total
Kubernetes 이야기
Pod Disruption Budget 본문
"PodDisruptionBudget" (PDB)은 자발적 중단으로 인해 동시에 다운된 복제된 애플리케이션의 포드 수를 제한하는 Kubernetes 객체이다. PDB는 비자발적으로 중단된 애플리케이션/포드 집합에서 작동하지 않는다. 여기서 자발적 중단이라는 용어가 나온다.
Kubernetes 매뉴얼에는 자발적 중단과 비자발적 중단을 아래와 같이 설명하고 있다.
비자발적 중단
- 노드를 지원하는 물리 머신의 하드웨어 오류
- 클러스터 관리자의 실수로 VM(인스턴스) 삭제
- 클라우드 공급자 또는 하이퍼바이저의 오류로 인한 VM 장애
- 커널 패닉
- 클러스터 네트워크 파티션의 발생으로 클러스터에서 노드가 사라짐
- 노드의 리소스 부족으로 파드가 축출됨
자발적 중단
- 디플로이먼트 제거 또는 다른 파드를 관리하는 컨트롤러의 제거
- 재시작을 유발하는 디플로이먼트의 파드 템플릿 업데이트
- 파드를 직접 삭제
- 복구 또는 업그레이드를 위한 노드 드레이닝.
- 클러스터의 스케일 축소를 위한 노드 드레이닝(클러스터 오토스케일링에 대해 알아보기 ).
- 노드에 다른 무언가를 추가하기 위해 파드를 제거
PDB을 사용하면 Kubernetes 노드에 대한 업그레이드 또는 일상적인 유지 관리 작업과 같은 어떤 이유로 Pod를 다시 예약해야 하는 경우 애플리케이션 중단을 제한할 수 있다.
그럼, PodDisruptionBudget 을 구성해야 하는 이유가 무엇일까? 아래와 같은 Deployment가 Kubernetes Cluster에 배포되었다고 해보자.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
노드가 3대이면 아래와 같이 배포될 수 있다. ( Affinity 설정등에 따라 달라질 수 있다. )
이제, Node1을 drain 해보자. 그러면 아래와 같이 배포될 수 있다.
이 때, 관리자가 상태를 점검하지 않고, Node2 를 Drain할 수 있다. 그럼 Drain 순간 아래와 같은 상태가 될 수 있다.
즉, Running 중인 Application 이 없는 상태가 될 수 있어 장애가 발생할 수 있다.
PDB를 사용하면 아래와 같이 상태체크를 진행하기 때문에 장애를 방지할 수 있게 된다.
꼭 위와 같은 경우가 아니더라도 2개의 Replicas가 하나의 노드에 배포되어 있을 때도 서비스 중단이 발생될 수 있다.
설정
PDB에서는 3개의 필드로 구성된다.
- .spec.selector : 레이블을 기반으로 다른 리소스를 선택한다.
- .spec.minAvailable : 항상 필요한 활성 포드 수를 결정한다.
- .spec.maxAvailable : 허용된 중단된 포드의 최대 수를 나타낸다.
PodDisruptionBudget 예제는 아래와 같다.
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: nginx-pdb
spec:
minAvailable: 3
selector:
matchLabels:
app: nginx
위의 예제는 만약 4개의 Nginx Pod가 있으면 ReplicaSet 컨트롤러는 다른 포드를 제거하기 전에 하나의 포드를 제거하고 새 포드로 교체될 때까지 기다린다.
또는 아래와 같이 CLI로 생성가능하다.
kubectl create poddisruptionbudget nginx-pdb –selector=app=nginx –min-available=80%
위의 예에서 PDB는 nginx 포드의 80%가 항상 정상 상태를 유지해야 한다는 요구 사항을 설정한다. 사용자가 포드 제거를 요청하면 클러스터는 PDB 요구 사항을 충족하는 경우에만 단계적 프로세스를 활성화한다.
PDB는 주로 고가용성이 반드시 담보되어야 하는 애플리케이션에서 많이 사용된다, 주로 Quorum 기능 (정족수 기반의 애플리케이션)이 존재하는 Application, ZooKeeper, ElasticSearch, ETCD 등 상태 저장 애플리케이션들이 PDB로 구성된다. 하지만 일반 애플리케이션도 고가용성을 고려해야 하기 때문에 관리자는 신경써서 설정해 주는 것이 바람직하다.
특히 운영기 환경에서는 적정할 설정이 필요하고, 일부 K8S Manifest 검사 도구들에서는 이를 경고로 표시해 준다.
참고
https://kubernetes.io/ko/docs/concepts/workloads/pods/disruptions/
https://www.logicmonitor.com/blog/what-is-kubernetes-pod-disruption
'Kubernetes > 일반' 카테고리의 다른 글
Nats - 오픈 소스 메시징 시스템 (0) | 2022.07.27 |
---|---|
KubeVirt로 kubernetes에 Windows VM 생성 (3) | 2022.06.10 |
Kubernetes Ephemeral Containers를 사용하여 debug 하기 (0) | 2022.05.11 |
컨테이너 환경에서 JVM Memory 설정 (0) | 2022.05.10 |
nginx ingress controller 를 helm chart로 배포하기 (0) | 2022.05.09 |