Supprimer les nœuds bloqués par PodDisruptionBudgets

Dans certaines conditions, les règles PodDisruptionBudgets (PDB) peuvent empêcher la suppression de nœuds des pools de nœuds. Dans ces conditions, l'état du nœud indique Ready,SchedulingDisabled malgré sa suppression. Ce document explique comment supprimer de vos clusters GKE sur Bare Metal qui sont actuellement bloqués par des problèmes PDB.

Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.

Conflits PDB avec le nombre de pods disponibles

Les règles PDB contribuent à garantir les performances des applications en empêchant l'interruption des pods en même temps lorsque vous apportez des modifications au système. Par conséquent, les règles PDB limitent le nombre de pods indisponibles simultanément dans une application répliquée.

Toutefois, la règle PDB peut parfois empêcher les suppressions de nœuds que vous souhaitez effectuer si vous enfreignez la règle en supprimant un nœud.

Par exemple, une règle PDB peut définir qu'il doit toujours y avoir deux pods disponibles dans le système (.spec.minAvailable correspond à 2). Toutefois, si vous n'avez que deux pods et que vous essayez de supprimer le nœud contenant l'un d'entre eux, la règle PDB prend effet et empêche la suppression du nœud.

De même, lorsque la règle PDB définit qu'aucun pod ne doit être indisponible (.spec.maxUnavailable est défini sur 0), la règle empêche également la suppression des nœuds associés. Même si vous essayez de supprimer un seul pod à la fois, la stratégie PDB vous empêche de supprimer le nœud concerné.

Désactiver et réactiver la règle PDB

Pour résoudre un conflit PDB, sauvegardez puis supprimez la stratégie PDB. Une fois la base de données supprimée, le nœud est drainé et les pods associés sont supprimés. Vous pouvez ensuite apporter les modifications souhaitées, puis réactiver la stratégie PDB.

L'exemple suivant montre comment supprimer un nœud dans cette condition, ce qui peut affecter tous les types de clusters GKE sur Bare Metal: clusters d'administrateur, hybrides, autonomes et d'utilisateur.

La même procédure générale fonctionne pour tous les types de clusters. Toutefois, les commandes spécifiques pour la suppression d'un nœud d'un pool de nœuds d'un cluster d'administrateur (pour les clusters administrateur, hybrides ou autonomes) diffèrent légèrement de celles de la suppression d'un nœud du pool de nœuds d'un cluster utilisateur.

Pour faciliter la lecture, la variable ${KUBECONFIG} est utilisée dans les commandes suivantes.

Selon le type de cluster, exportez le chemin d'accès kubeconfig du cluster d'administrateur (ADMIN_KUBECONFIG) ou du cluster d'utilisateur (USER_CLUSTER_CONFIG) vers $(KUBECONFIG), puis procédez comme suit:
- Pour supprimer un nœud d'un cluster d'utilisateur, définissez export KUBECONFIG=USER_CLUSTER_CONFIG.
- Pour supprimer le nœud d'un cluster d'administrateur, définissez export KUBECONFIG=ADMIN_KUBECONFIG.
Facultatif: Si vous supprimez un nœud d'un pool de nœuds de cluster d'utilisateur, exécutez la commande suivante pour extraire le fichier kubeconfig du cluster d'utilisateur:
```
kubectl --kubeconfig ADMIN_KUBECONFIG -n cluster-USER_CLUSTER_NAME \
  get secret USER_CLUSTER_NAME-kubeconfig  \
  -o 'jsonpath={.data.value}' | base64 -d > USER_CLUSTER_CONFIG
```
Remplacez les entrées suivantes par des informations spécifiques à votre environnement de cluster:
- ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur.
- CLUSTER_NAME : nom du cluster pour lequel vous souhaitez prendre un instantané.
- USER_CLUSTER_CONFIG: chemin d'accès au fichier de configuration du cluster d'utilisateur.

Une fois le nœud supprimé du pool de nœuds, vérifiez son état. Le nœud concerné indique Ready, SchedulingDisabled:

kubectl get nodes --kubeconfig ${KUBECONFIG}

L'état du nœud ressemble à l'exemple de résultat suivant:

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

Vérifiez les PDB dans votre cluster :

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

Le système signale des PDB semblables à ceux présentés dans l'exemple de sortie suivant:

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

Inspectez le PDB. Recherchez une correspondance entre l'étiquette du pod dans le PDB et les pods correspondants dans le nœud. Cette correspondance vous garantit de désactiver le PDB approprié pour supprimer le nœud correctement:
```
kubectl --kubeconfig ${KUBECONFIG} get pdb log-aggregator -n kube-system -o 'jsonpath={.spec}'
```
Le système renvoie les résultats correspondant aux libellés dans la stratégie PDB :
```
{"maxUnavailable":0,"selector":{"matchLabels":{"app":"stackdriver-log-aggregator"}}}
```

Recherchez les pods qui correspondent au libellé de stratégie PDB :

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

La commande renvoie une liste de pods correspondant à l'étiquette PDB et vérifie la règle PDB que vous devez supprimer:

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

Après avoir confirmé le pod concerné, créez une copie de sauvegarde de la stratégie PDB. L'exemple suivant sauvegarde la stratégie log-aggregator:
```
kubectl get pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system  \
  -o yaml >> log-aggregator.yaml
```
Supprimez la stratégie PDB spécifique. Là encore, les exemples suivants suppriment la règle log-aggregator:
```
kubectl delete pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system
```
Une fois la stratégie PDB supprimée, le nœud procède au drainage. Toutefois, la suppression complète du nœud peut prendre jusqu'à 30 minutes. Continuez à vérifier l'état du nœud pour confirmer que le processus s'est terminé correctement.

Si vous souhaitez supprimer le nœud définitivement, ainsi que les ressources de stockage qui lui sont associées, vous pouvez le faire avant de restaurer la stratégie PDB. Pour en savoir plus, consultez la section Supprimer des ressources de stockage.

Restaurez la stratégie PDB à partir de votre copie :

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

Vérifiez que les pods supprimés sont correctement recréés. Dans cet exemple, s'il y avait deux pods stackdriver-log-aggregator-x, ils sont recréés:
```
kubectl get pods -o wide --kubeconfig ${KUBECONFIG} -A
```
Si vous souhaitez restaurer le nœud, modifiez la configuration de pool de nœuds appropriée et restaurez l'adresse IP du nœud.

Supprimer des ressources de stockage des nœuds supprimés définitivement

Si vous supprimez définitivement un nœud et que vous ne souhaitez pas le restaurer sur votre système, vous pouvez également supprimer les ressources de stockage associées à ce nœud.

Vérifiez et obtenez le nom du volume persistant (PV) associé au nœud :

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}'

Supprimez le PV associé au nœud :
```
kubectl delete pv PV_NAME --kubeconfig ${KUBECONFIG}
```
Remplacez PV_NAME par le nom du volume persistant à supprimer.

Étapes suivantes

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.