PodDisruptionBudgets에 의해 차단된 노드 삭제

특정 조건에서는 PodDisruptionBudgets(PDB) 정책으로 인해 노드 풀에서 노드가 삭제되지 못할 수 있습니다. 이러한 조건에서 노드는 삭제되더라도 노드 상태는 Ready,SchedulingDisabled를 보고합니다. 이 문서에서는 현재 PDB 문제로 차단된 Google Distributed Cloud 클러스터에서 노드를 삭제하는 방법을 보여줍니다.

추가 지원이 필요하면 Cloud Customer Care에 문의하세요.

PDB가 사용 가능한 포드 수와 충돌함

PDB 정책은 시스템 변경 시 pod가 동시에 다운되지 않도록 하여 앱 성능을 보장합니다. 따라서 PDB 정책은 복제된 애플리케이션에서 동시에 사용할 수 없는 포드 수를 제한합니다.

그러나 노드를 삭제하여 정책을 위반하게 되는 경우 PDB 정책에서 노드 삭제를 차단할 수도 있습니다.

예를 들어 PDB 정책이 항상 시스템에 사용 가능한 포드 두 개가 있어야 한다고 정의할 수 있습니다(.spec.minAvailable은 2). 그러나 포드가 2개만 있고 이들 중 하나가 포함된 노드를 삭제하려고 하면 PDB 정책이 적용되고 노드 삭제가 방지됩니다.

마찬가지로 PDB 정책이 사용할 수 없는 포드(.spec.maxUnavailable이 0)가 없어야 한다고 정의하면 정책에서 모든 관련 노드의 삭제를 차단합니다. 포드를 한 번에 하나씩 삭제하려고 해도 PDB 정책이 영향을 받는 노드를 삭제할 수 없도록 합니다.

PDB 정책 사용 중지 및 다시 사용 설정

PDB 충돌을 해결하려면 PDB 정책을 백업한 다음 삭제하세요. PDB가 성공적으로 삭제되면 노드가 드레이닝되고 연결된 포드가 삭제됩니다. 그런 다음 원하는 대로 변경하고 PDB 정책을 다시 사용 설정하면 됩니다.

다음 예시에서는 이 조건에서 노드를 삭제하는 방법을 보여줍니다. 이렇게 하면 관리자, 하이브리드, 독립형, 사용자 클러스터 등 모든 Google Distributed Cloud 클러스터 유형에 영향을 줄 수 있습니다.

모든 클러스터 유형에 동일한 일반 절차가 적용됩니다. 그러나 관리자, 하이브리드 또는 독립형 클러스터의 관리자 클러스터 노드 풀에서 노드를 삭제하는 특정 명령어는 사용자 클러스터 노드 풀에서 노드를 삭제하는 명령어와 약간 다릅니다.

쉽게 읽을 수 있도록 다음 명령어에 ${KUBECONFIG} 변수가 사용됩니다.

클러스터 유형에 따라 관리자 클러스터 kubeconfig(ADMIN_KUBECONFIG) 또는 사용자 클러스터 kubeconfig(USER_CLUSTER_CONFIG) 경로를 $(KUBECONFIG)로 내보내고 다음 단계를 완료합니다.
- 사용자 클러스터에서 노드를 삭제하려면 export KUBECONFIG=USER_CLUSTER_CONFIG를 설정합니다.
- 관리자 클러스터에서 노드를 삭제하려면 export KUBECONFIG=ADMIN_KUBECONFIG를 설정합니다.
선택사항: 사용자 클러스터 노드 풀에서 노드를 삭제하는 경우 다음 명령어를 실행하여 사용자 클러스터 kubeconfig 파일을 추출합니다.
```
kubectl --kubeconfig ADMIN_KUBECONFIG -n cluster-USER_CLUSTER_NAME \
  get secret USER_CLUSTER_NAME-kubeconfig  \
  -o 'jsonpath={.data.value}' | base64 -d > USER_CLUSTER_CONFIG
```
다음 항목을 클러스터 환경에 해당하는 정보로 바꿉니다.
- ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
- CLUSTER_NAME: 스냅샷을 만들려는 클러스터의 이름입니다.
- USER_CLUSTER_CONFIG: 사용자 클러스터 구성 파일 경로입니다.

노드 풀에서 노드를 삭제한 후 노드 상태를 확인합니다. 영향을 받는 노드는 Ready, SchedulingDisabled를 보고합니다.

kubectl get nodes --kubeconfig ${KUBECONFIG}

노드 상태는 다음 출력 예시와 유사합니다.

NAME   STATUS                    ROLES      AGE      VERSION
CP2    Ready                     Master     11m      v.1.18.6-gke.6600
CP3    Ready,SchedulingDisabled  <none>     9m22s    v.1.18.6-gke.6600
CP4    Ready                     <none>     9m18s    v.1.18.6-gke.6600

클러스터의 PDB를 확인합니다.

kubectl get pdb --kubeconfig ${KUBECONFIG} -A

시스템은 다음 예시 출력에 표시된 것과 유사한 PDB를 보고합니다.

NAMESPACE     NAME             MIN AVAILABLE    MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
gke-system    istio-ingress    1                N/A               1                     19m
gke-system    istiod           1                N/A               1                     19m
kube-system   coredns          1                N/A               0                     19m
kube-system   log-aggregator   N/A              0                 0                     19m
kube-system   prometheus       N/A              0                 0                     19m

PDB를 검사합니다. PDB 내 포드 라벨과 노드의 일치하는 포드 간의 일치를 찾습니다. 이 일치는 올바른 PDB를 사용 중지하여 노드를 성공적으로 삭제합니다.
```
kubectl --kubeconfig ${KUBECONFIG} get pdb log-aggregator -n kube-system -o 'jsonpath={.spec}'
```
시스템이 PDB 정책에서 일치하는 라벨 결과를 반환합니다.
```
{"maxUnavailable":0,"selector":{"matchLabels":{"app":"stackdriver-log-aggregator"}}}
```

PDB 정책 라벨과 일치하는 Pod를 찾습니다.

kubectl --kubeconfig ${KUBECONFIG} get pods -A --selector=app=stackdriver-log-aggregator  \
  -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.nodeName}{"\n"}{end}'

이 명령어는 PDB 라벨과 일치하는 포드 목록을 반환하고 삭제해야 하는 PDB 정책을 확인합니다.

stackdriver-log-aggregator-0    CP3
stackdriver-log-aggregator-1    CP3

영향을 받은 포드를 확인한 후 PDB 정책의 백업 사본을 만듭니다. 다음 예시에서는 log-aggregator 정책을 백업합니다.
```
kubectl get pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system  \
  -o yaml >> log-aggregator.yaml
```
특정 PDB 정책을 삭제합니다. 다음 예시에서는 또 다시 log-aggregator 정책을 삭제합니다.
```
kubectl delete pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system
```
PDB 정책을 삭제하면 노드가 드레이닝을 진행합니다. 노드가 완전히 삭제되는 데 최대 30분이 소요될 수 있습니다. 노드 상태를 계속 확인하여 프로세스가 성공적으로 완료되었는지 확인합니다.

노드를 영구적으로 삭제하고 노드와 연결된 스토리지 리소스도 삭제하려면 PDB 정책을 복원하기 전에 삭제할 수 있습니다. 자세한 내용은 스토리지 리소스 삭제를 참조하세요.

사본에서 PDB 정책을 복원합니다.

kubectl apply -f log-aggregator.yaml --kubeconfig ${KUBECONFIG}

삭제된 포드가 성공적으로 다시 생성되었는지 확인합니다. 이 예시에서는 2개의 stackdriver-log-aggregator-x 포드가 있는 경우 이러한 포드가 다시 생성됩니다.
```
kubectl get pods -o wide --kubeconfig ${KUBECONFIG} -A
```
노드를 복원하려면 적절한 노드 풀 구성을 수정하고 노드 IP 주소를 복원합니다.

영구 삭제된 노드에서 스토리지 리소스 삭제

노드를 영구적으로 삭제하고 시스템을 복원하지 않으려는 경우 이 노드와 연결된 스토리지 리소스도 삭제할 수 있습니다.

노드와 연결된 영구 볼륨(PV)의 이름을 확인하고 가져옵니다.

kubectl get pv --kubeconfig ${KUBECONFIG}  \
  -A -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{.spec.claimRef.name}{":\t}  \
  {.spec.nodeAffinity.required.nodeSelectorTerms[0].matchExpressions[0].values}{"\n"}{end}'

노드와 연결된 PV를 삭제합니다.
```
kubectl delete pv PV_NAME --kubeconfig ${KUBECONFIG}
```
PV_NAME을 삭제할 영구 볼륨의 이름으로 바꿉니다.

다음 단계

추가 지원이 필요하면 Cloud Customer Care에 문의하세요.