Supprimer des nœuds bloqués par le budget d'interruption de pod

Dans certaines conditions, les règles de Budget d'interruption de pod (PDB) peuvent empêcher la suppression définitive des nœuds des pools de nœuds. Dans ces conditions, l'état du nœud indique Ready,SchedulingDisabled malgré sa suppression.

Le budget d'interruption de pod est en conflit 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 celles-ci entraînent une violation de la règle.

Par exemple, une règle PDB peut définir qu'il y a toujours deux pods disponibles dans le système (.spec.minAvailable correspond à 2). Toutefois, si vous ne disposez que de 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 indique qu'aucun pod ne doit être indisponible (.spec.maxUnavailable est 0), elle empêche également la suppression de tous les nœuds associés. Même si vous essayez de supprimer un pod unique à la fois, la règle PDB vous empêche de supprimer le nœud concerné.

Solution : désactiver et réactiver la règle PDB

Pour résoudre ce conflit, vous devez sauvegarder la règle PDB, puis la supprimer. Une fois le PDB supprimé, le nœud est drainé et les pods associés sont supprimés. Après avoir effectué les modifications souhaitées, vous pouvez réactiver la règle PDB.

L'exemple suivant montre comment supprimer un nœud de cette condition, qui peut affecter tous les types de clusters Anthos sur Bare Metal : clusters d'administrateurs, hybrides, autonomes et clusters d'utilisateurs.

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.

Variantes de commandes pour différents types de clusters

Pour faciliter la lecture, notez l'espace réservé ${KUBECONFIG} dans les commandes suivantes. Selon le type de cluster, exportez kubeconfig du cluster administrateur (ADMIN_KUBECONFIG) ou le kubeconfig du cluster utilisateur (USER_CLUSTER_CONFIG) vers $(KUBECONFIG), puis procédez comme suit.

Pour supprimer un nœud d'un cluster d'utilisateur, exécutez la commande export KUBECONFIG=USER_CLUSTER_CONFIG.
Pour supprimer le nœud d'un cluster d'administrateur, exécutez la commande export KUBECONFIG=ADMIN_KUBECONFIG.

Facultatif : Si vous supprimez un nœud d'un pool de nœuds d'un cluster utilisateur, exécutez la commande suivante pour extraire le fichier kubeconfig du cluster d'utilisateur. Notez que la variable ADMIN_KUBECONFIG spécifie le chemin d'accès au fichier kubeconfig du cluster d'administrateur, et que la variable USER_CLUSTER_NAME spécifie le nom du cluster :
```
kubectl --kubeconfig ADMIN_KUBECONFIG -n cluster-USER_CLUSTER_NAME  \
get secret USER_CLUSTER_NAME-kubeconfig  \
-o 'jsonpath={.data.value}' | base64 -d > USER_CLUSTER_CONFIG
```

Après avoir supprimé le nœud 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 est semblable à ce qui suit :

NAME        STATUS                    ROLES      AGE      VERSION
abmnewCP2   Ready                     Master     11m      v.1.18.6-gke.6600
abmnewCP3   Ready,SchedulingDisabled  <none>     9m22s    v.1.18.6-gke.6600
abmnewCP4   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 indique des PDB similaires à ceux indiqués ci-dessous :

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. Vous devez rechercher une correspondance entre l'étiquette du pod dans le PDB et les pods correspondants dans le nœud. Cette correspondance garantit que vous désactivez 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 au libellé PDB et vérifie la règle PDB que vous devez supprimer :

stackdriver-log-aggregator-0    abmnewCP3
stackdriver-log-aggregator-1    abmnewCP3

Après avoir confirmé le pod concerné, créez une copie de sauvegarde de la stratégie PDB, dans cet exemple, la règle log-aggregator :
```
kubectl get pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system  \
-o yaml >> log-aggregator.yaml
```
Supprimez la règle PDB spécifique, dans ce cas, la règle log-aggregator :
```
kubectl delete pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system
```
Une fois que vous avez supprimé la règle PDB, le nœud commence à se drainer. Toutefois, la suppression complète du nœud peut prendre un certain temps (jusqu'à 30 minutes). Ainsi, vous devez continuer à vérifier l'état du nœud.

Notez que si vous souhaitez supprimer le nœud de manière permanente, ainsi que les ressources de stockage associées au nœud, vous pouvez le faire avant de restaurer la règle PDB. 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 ont bien été recréés. Dans cet exemple, s'il existe 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 de nœuds supprimés définitivement

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

Dans les commandes suivantes, notez les variables :

ADMIN-KUBECONFIG spécifie le chemin d'accès au cluster d'administrateur.
USER_CLUSTER_CONFIG spécifie le chemin d'accès au fichier YAML de configuration du cluster.

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}