Version 1.6. Cette version n'est plus compatible. Pour plus d'informations, consultez la politique de compatibilité avec les versions. Pour en savoir plus sur la mise à niveau vers la version 1.7, consultez la page Mettre à niveau Anthos sur solution Bare Metal dans la documentation de la version 1.7.

Versions compatibles : 1.14 | 1.13 | 1.12

Forcer la suppression des nœuds endommagés dans les clusters Anthos sur Bare Metal

Lorsqu'un nœud est endommagé et doit être supprimé d'un cluster pour être réparé ou remplacé, vous pouvez forcer sa suppression du cluster.

Forcer la suppression des nœuds dans la version 1.6.0 des clusters Anthos sur Bare Metal

Dans la version 1.6.0 d'Anthos on bare metal, la suppression d'un nœud de son pool de nœuds parent entraîne les actions suivantes :

Drainer le nœud
Supprimer le nœud du cluster Kubernetes
Réinitialiser la machine à l'état antérieur à l'installation d'Anthos on bare metal

Toutefois, si le nœud est inaccessible, le drainage de nœud ne se termine pas. Le contrôleur tente de drainer le nœud à plusieurs reprises, sans jamais progresser.

Afin de résoudre temporairement ce problème, vous pouvez appliquer les modifications suivantes pour contourner les étapes de drainage et de réinitialisation.

ATTENTION : Cette opération nécessite une mise à jour minutieuse des champs de mise en œuvre spécifiques des ressources personnalisées Kubernetes. N'effectuez pas cette opération à moins d'être certain que le nœud est irrécupérable.

Effectuez ces étapes après avoir supprimé physiquement le nœud défectueux du pool de nœuds et appliqué la modification dans le cluster d'administrateur.

Recherchez la ressource personnalisée de la machine API dans le cluster d'administrateur, où ADMIN_KUBECONFIG est le chemin d'accès au fichier kubeconfig et CLUSTER_NAMESPACE est l'espace de noms du cluster affecté :
```
kubectl --kubeconfig ADMIN_KUBECONFIG \
-n CLUSTER_NAMESPACE get ma 10.200.0.8
```
La commande renvoie des résultats semblables à ce qui suit :
```
NAME         PROVIDERID               PHASE
10.200.0.8   baremetal://10.200.0.8   Deleting
```
Dans cet exemple, 10.200.0.8 est l'adresse IP du nœud bloqué pendant la phase de suppression.
Modifiez la ressource personnalisée de la machine et ajoutez l'annotation machine.cluster.x-k8s.io/exclude-node-draining. Notez que la valeur de l'annotation n'a pas d'importance. Tant que la clé est présente, le drainage est ignoré :
```
kubectl --kubeconfig ADMIN_KUBECONFIG -n CLUSTER_NAMESPACE \
annotate ma 10.200.0.8 machine.cluster.x-k8s.io/exclude-node-draining=true
```

Recherchez la ressource personnalisée de la machine Bare Metal dans le cluster d'administrateur :

kubectl --kubeconfig ADMIN_KUBECONFIG -n CLUSTER_NAMESPACE \
get baremetalmachine 10.200.0.8

La commande renvoie des résultats semblables à ce qui suit :

NAME         CLUSTER    READY   INSTANCEID               MACHINE
10.200.0.8   cluster1   true    baremetal://10.200.0.8   10.200.0.8

Supprimez le finaliseur pour ignorer l'étape de réinitialisation et débloquer la suppression du nœud :

kubectl --kubeconfig ADMIN_KUBECONFIG -n CLUSTER_NAMESPACE \
patch baremetalmachine 10.200.0.8 --type json -p='[{"op": "remove", "path": "/metadata/finalizers"}]'

Après quelques secondes, le nœud est supprimé du cluster.

Forcer la suppression des nœuds dans la version 1.6.1 des clusters Anthos sur Bare Metal

Dans la version 1.6.1 des clusters Anthos sur Bare Metal, vous pouvez ajouter une annotation pour marquer un nœud en vue de la suppression forcée.

Après avoir supprimé le nœud du pool de nœuds parent, exécutez la commande suivante pour annoter la machine défaillante correspondante avec l'annotation baremetal.cluster.gke.io/force-remove. La valeur de l'annotation elle-même n'a pas d'importance.

kubectl --kubeconfig ADMIN_KUBECONFIG -n CLUSTER_NAMESPACE \
  annotate machine 10.200.0.8 baremetal.cluster.gke.io/force-remove=true

Les clusters Anthos sur Bare Metal suppriment le nœud avec succès.

Forcer la suppression des nœuds du plan de contrôle

Forcer la suppression d'un nœud du plan de contrôle est semblable à une opération kubeadm reset sur les nœuds du plan de contrôle et nécessite des étapes supplémentaires.

Pour forcer la suppression d'un nœud du plan de contrôle des pools de nœuds, vous devez effectuer les actions suivantes sur le cluster contenant le nœud du plan de contrôle défaillant :

Supprimer le membre etcd défaillant s'exécutant sur le nœud défaillant du cluster etcd
Mettre à jour ClusterStatus dans le kube pour supprimer l'objet apiEndpoint correspondant.

Supprimer un membre `etcd` défaillant

Pour supprimer le nœud du plan de contrôle défaillant, exécutez d'abord etcdctl sur les pods etcd opérationnels restants. Pour en savoir plus sur cette opération, consultez la documentation Kubernetes.

Dans la procédure suivante, CLUSTER_KUBECONFIG est le chemin d'accès au fichier kubeconfig du cluster.

Recherchez le pod etcd à l'aide de la commande suivante :

kubectl --kubeconfig CLUSTER_KUBECONFIG get \
 pod -n kube-system -l component=etcd -o wide

La commande renvoie la liste de nœuds suivante. Pour cet exemple, supposons que le nœud 10.200.0.8 soit inaccessible et irrécupérable :

NAME                READY   STATUS    RESTARTS   AGE     IP           NODE
etcd-357b68f4ecf0   1/1     Running   0          9m2s    10.200.0.6   357b68f4ecf0
etcd-7d7c21db88b3   1/1     Running   0          33m     10.200.0.7   7d7c21db88b3
etcd-b049141e0802   1/1     Running   0          8m22s   10.200.0.8   b049141e0802

Exec sur l'un des pods etcd opérationnels restants :

kubectl --kubeconfig CLUSTER_KUBECONFIG exec -it -n \
kube-system etcd-357b68f4ecf0 -- /bin/sh

Recherchez les membres actuels pour trouver l'ID du membre défaillant. La commande renvoie une liste :

etcdctl --endpoints=https://10.200.0.6:2379,https://10.200.0.7:2379 --key=/etc/kubernetes/pki/etcd/peer.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt  member list

Cette commande renvoie, par exemple, les données suivantes :

23da9c3f2594532a, started, 7d7c21db88b3, https://10.200.0.6:2380, https://10.200.0.6:2379, false
772c1a54956b7f51, started, 357b68f4ecf0, https://10.200.0.7:2380, https://10.200.0.7:2379, false
f64f66ad8d3e7960, started, b049141e0802, https://10.200.0.8:2380, https://10.200.0.8:2379, false

Supprimez le membre défaillant :

etcdctl --endpoints=https://10.200.0.6:2379,https://10.200.0.7:2379 --key=/etc/kubernetes/pki/etcd/peer.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt \
 member remove f64f66ad8d3e7960

Mettre à jour `ClusterStatus` et supprimer l'`apiEndpoint` défaillant

Dans la procédure suivante, CLUSTER_KUBECONFIG est le chemin d'accès au fichier kubeconfig du cluster.

Recherchez la section ClusterStatus dans le ConfigMap kubeadm-config :

kubectl --kubeconfig CLUSTER_KUBECONFIG describe configmap -n \
kube-system kubeadm-config

La commande renvoie des résultats semblables à ceux ci-dessous :

...
ClusterStatus:
----
apiEndpoints:
7d7c21db88b3:
  advertiseAddress: 10.200.0.6
  bindPort: 6444
357b68f4ecf0:
  advertiseAddress: 10.200.0.7
  bindPort: 6444
b049141e0802:
  advertiseAddress: 10.200.0.8
  bindPort: 6444
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterStatus
...

Modifiez le ConfigMap pour supprimer la section contenant l'adresse IP défaillante (cet exemple montre les résultats de la suppression de 10.200.0.8 à l'aide de la commande kubectl edit) :

kubectl --kubeconfig CLUSTER_KUBECONFIG edit configmap \
-n kube-system kubeadm-config

Une fois la modification effectuée, le ConfigMap ressemble à ceci :

...
ClusterStatus: |
  apiEndpoints:
    7d7c21db88b3:
      advertiseAddress: 10.200.0.6
      bindPort: 6444
    357b68f4ecf0:
      advertiseAddress: 10.200.0.7
      bindPort: 6444
  apiVersion: kubeadm.k8s.io/v1beta2
  kind: ClusterStatus
...

Lorsque vous enregistrez le ConfigMap modifié, le nœud défaillant est supprimé du cluster.