Versione 1.6. Questa versione non è più supportata. Per ulteriori informazioni, consulta le norme relative all'assistenza per le versioni. Per informazioni su come eseguire l'upgrade alla versione 1.7, consulta la pagina relativa all'upgrade di Anthos su Bare Metal nella documentazione della versione 1.7.

Versioni supportate disponibili: 1.14 | 1.13 | 1.12

Forzare la rimozione dei nodi danneggiati nei cluster Anthos su Bare Metal

Quando un nodo si rompe e deve essere rimosso da un cluster per la riparazione o la sostituzione, puoi forzarne la rimozione dal cluster.

Forzare la rimozione dei nodi nei cluster Anthos su Bare Metal 1.6.0

Nella versione 1.6.0 di Anthos su Bare Metal, la rimozione di un nodo dal pool di nodi padre comporta le seguenti azioni:

Svuotamento del nodo in corso...
Rimozione del nodo dal cluster Kubernetes
Reimpostazione dello stato della macchina prima dell'installazione di Anthos su Bare Metal

Tuttavia, se il nodo non è accessibile, lo svuotamento dei nodi non verrà completato. Il controller tenta ripetutamente di svuotare il nodo e non esegue mai l'avanzamento.

Come soluzione temporanea, puoi applicare le seguenti modifiche per ignorare i passaggi di svuotamento e reimpostazione.

ATTENZIONE: questa operazione richiede un aggiornamento accurato dei campi di implementazione specifici nelle risorse personalizzate di Kubernetes. Non continuare finché non hai la certezza che il nodo non sia recuperabile.

Esegui questi passaggi dopo aver rimosso fisicamente il nodo rotto dal pool di nodi e applicato la modifica nel cluster di amministrazione.

Cerca la risorsa personalizzata della macchina API del cluster nel cluster di amministrazione, dove ADMIN_KUBECONFIG è il percorso del file kubeconfig e CLUSTER_NAMESPACE è lo spazio dei nomi del cluster interessato:
```
kubectl --kubeconfig ADMIN_KUBECONFIG \
-n CLUSTER_NAMESPACE get ma 10.200.0.8
```
Il comando restituisce risultati simili ai seguenti:
```
NAME         PROVIDERID               PHASE
10.200.0.8   baremetal://10.200.0.8   Deleting
```
In questo esempio, 10.200.0.8 è l'indirizzo IP del nodo bloccato nella fase di eliminazione.
Modifica la risorsa personalizzata della macchina e aggiungi l'annotazione machine.cluster.x-k8s.io/exclude-node-draining. Tieni presente che il valore dell'annotazione in sé non è importante, in quanto finché la chiave è presente, lo svuotamento verrà ignorato:
```
kubectl --kubeconfig ADMIN_KUBECONFIG -n CLUSTER_NAMESPACE \
annotate ma 10.200.0.8 machine.cluster.x-k8s.io/exclude-node-draining=true
```

Cerca la risorsa personalizzata della macchina Bare Metal nel cluster di amministrazione:

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

Il comando restituisce risultati simili ai seguenti:

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

Rimuovi il finalizzatore per saltare il passaggio di reimpostazione e sblocca la rimozione del nodo:

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

Dopo alcuni secondi, il nodo viene rimosso dal cluster.

Forzare la rimozione dei nodi nei cluster Anthos su Bare Metal 1.6.1

Nei cluster Anthos su Bare Metal 1.6.1, puoi aggiungere un'annotazione per contrassegnare un nodo per la rimozione forzata.

Dopo aver rimosso il nodo dal pool di nodi padre, esegui il comando seguente per annotare la macchina in errore corrispondente con l'annotazione baremetal.cluster.gke.io/force-remove. Il valore dell'annotazione stessa non è importante:

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

I cluster Anthos su Bare Metal rimuovono correttamente il nodo.

Rimozione forzata dei nodi del piano di controllo

La rimozione forzata di un nodo del piano di controllo è simile all'esecuzione di un kubeadm reset sui nodi del piano di controllo e richiede passaggi aggiuntivi.

Per forzare la rimozione di un nodo del piano di controllo dai pool di nodi, devi eseguire le seguenti azioni nei confronti del cluster che contiene il nodo del piano di controllo non riuscito:

rimuovi il membro etcd in errore sul nodo in errore dal cluster etcd
aggiorna il ClusterStatus nel kube per rimuovere il apiEndpoint corrispondente.

Rimozione di un membro con errori `etcd`

Per rimuovere il nodo del piano di controllo in errore, esegui prima l'elemento etcdctl sui pod etcd rimanenti in stato integro. Per informazioni più generali su questa operazione, consulta questa documentazione di Kubernetes.

Nella procedura seguente, CLUSTER_KUBECONFIG è il percorso del file kubeconfig del cluster.

Cerca il pod etcd con il comando seguente:

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

Il comando restituisce il seguente elenco di nodi. Per questo esempio, supponiamo che il nodo 10.200.0.8 sia inaccessibile e non recuperabile:

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

Attiva uno dei pod etcd in stato integro rimanenti:

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

Cerca gli attuali membri per trovare l'ID del membro in errore. Il comando restituisce un elenco:

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

Questo comando restituisce, ad esempio:

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

Rimuovi il membro in errore:

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

Aggiornamento di `ClusterStatus` e rimozione di `apiEndpoint` non riuscito

Nella procedura seguente, CLUSTER_KUBECONFIG è il percorso del file kubeconfig del cluster.

Cerca la sezione ClusterStatus nella mappa di configurazione di kubeadm-config:

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

Il comando restituisce risultati simili a quelli mostrati di seguito:

...
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
...

Modifica la mappa di configurazione per rimuovere la sezione che contiene l'IP in errore (questo esempio mostra i risultati della rimozione di 10.200.0.8 utilizzando il comando kubectl edit):

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

Dopo la modifica, la mappa di configurazione è simile alla seguente:

...
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
...

Quando salvi la mappa di configurazione modificata, il nodo in errore viene rimosso dal cluster.