Cette page a été traduite par l'API Cloud Translation.

Supprimer les nœuds bloqués par PodDisruptionBudgets

Dans certaines conditions, les règles PodDisruptionBudgets (PDB) peuvent empêcher la suppression des nœuds des pools. Dans ces conditions, l'état du nœud indique Ready,SchedulingDisabled bien qu'il soit supprimé. Ce document explique comment supprimer de vos clusters Google Distributed Cloud qui sont actuellement bloqués par des problèmes PDB.

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

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 stratégies PDB limitent le nombre de pods indisponibles simultanément dans une application répliquée.

Cependant, la règle PDB peut parfois empêcher les suppressions de nœuds si vous ne la respectez pas, en supprimant un nœud.

Par exemple, une stratégie PDB peut définir qu'il doit toujours y avoir deux pods disponibles dans le système (.spec.minAvailable est égal à 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 stratégie PDB définit qu'aucun pod ne doit être indisponible (.spec.maxUnavailable est 0), elle empêche également la suppression des nœuds associés. Même si vous essayez de supprimer un seul pod à la fois, la règle 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 règle PDB. Une fois le PDB supprimé, le nœud se draine et les pods associés sont supprimés. Vous pouvez ensuite apporter les modifications souhaitées et 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 Google Distributed Cloud: 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 kubeconfig (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 d'un 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.

Après avoir retiré 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 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 résultat 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 de pod dans le PDB et les pods correspondants du nœud. Cette correspondance garantit que vous désactivez le bon PDB pour supprimer le nœud:
```
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 la liste des pods correspondant à l'étiquette PDB et vérifie la stratégie PDB à 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 règle 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 est drainé. 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 est terminé.

Si vous souhaitez supprimer définitivement le nœud et également supprimer 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 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 les 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.