Rinnova manualmente i certificati dei cluster scaduti

Questo documento descrive come rinnovare manualmente i certificati scaduti per i tuoi cluster Anthos su Bare Metal. I certificati TLS (Transport Layer Security) vengono utilizzati dai componenti del piano di controllo dei cluster Anthos su Bare Metal. Alla scadenza di questi certificati, la possibilità di gestire carichi di lavoro e cicli di vita dei cluster viene bloccata fino al rinnovo dei certificati. Per ulteriori informazioni sull'impatto dei certificati scaduti, consulta Scadenza dei certificati.

Per impostazione predefinita, i certificati TLS hanno un periodo di scadenza di 1 anno. Anthos clusters on bare metal rinnova automaticamente questi certificati durante gli upgrade dei cluster e quando esegui la rotazione delle autorità di certificazione. Ti consigliamo di eseguire regolarmente l'upgrade dei tuoi cluster per mantenerli protetti, supportati e per evitare che i certificati TLS scadano.

Errori causati dalla scadenza del certificato

Se i certificati TLS sul tuo cluster scadono, i controller principali non possono stabilire connessioni TLS con il server API Kubernetes. La mancanza di connettività causa i seguenti errori:

Unable to connect to the server: x509: Unable to connect to the server

Quando utilizzi kubectl per recuperare i nodi del cluster, la risposta include un errore che fa riferimento alla scadenza del certificato:
```
kubectl get nodes --kubeconfig KUBECONFIG_PATH
```
Sostituisci KUBECONFIG_PATH con il percorso del file kubeconfig per il cluster.

Quando i certificati sono scaduti, la risposta è simile alla seguente:
```
Unable to connect to the server: x509: certificate has expired or is not yet valid
```

could not connect: x509 o rejected connection

I certificati scaduti bloccano l'accesso al cluster etcd, in quanto i peer non possono comunicare tra loro. I log etcd potrebbero contenere voci di errore come queste:

W | rafthttp: health check for peer 6221a1d241bb2d0a could not connect: x509: certificate
has expired or is not yet valid
I | embed: rejected connection from "10.200.0.4:46108" (error "remote error: tls: bad
certificate", ServerName "")

Controlla le date di scadenza dei certificati

Questa sezione contiene le istruzioni per controllare la scadenza dei certificati utilizzati dal cluster. Completa i seguenti passaggi su ciascun nodo del piano di controllo.

Per controllare le date di scadenza dei certificati:

Accedi a una delle macchine nodo del piano di controllo ed esegui questo comando:

sudo kubeadm certs check-expiration

L'output comando elenca i certificati creati da kubeadm per i componenti del piano di controllo e la relativa scadenza:

CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 Nov 28, 2021 19:09 UTC   53m                                     no
apiserver                  Nov 28, 2021 19:09 UTC   53m             ca                      no
apiserver-etcd-client      Nov 28, 2021 19:09 UTC   53m             etcd-ca                 no
apiserver-kubelet-client   Nov 28, 2021 19:09 UTC   53m             ca                      no
controller-manager.conf    Nov 28, 2021 19:09 UTC   53m                                     no
etcd-healthcheck-client    Nov 28, 2021 19:09 UTC   53m             etcd-ca                 no
etcd-peer                  Nov 28, 2021 19:09 UTC   53m             etcd-ca                 no
etcd-server                Nov 28, 2021 19:09 UTC   53m             etcd-ca                 no
front-proxy-client         Nov 28, 2021 19:09 UTC   53m             front-proxy-ca          no
scheduler.conf             Nov 28, 2021 19:09 UTC   53m                                     no

CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
ca                      Nov 26, 2031 18:06 UTC   9y              no
etcd-ca                 Nov 26, 2031 18:06 UTC   9y              no
front-proxy-ca          Nov 26, 2031 18:06 UTC   9y              no

Esegui questo comando per verificare la scadenza dei certificati kubelet:
```
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text | grep Validity -A2
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-server-current.pem -text | grep Validity -A2
```
La risposta per ogni comando ha il seguente output:
```
Validity
    Not Before: Sep 17 22:27:53 2021 GMT
    Not After : Sep 17 22:33:16 2022 GMT
```
Se tutti i nodi del piano di controllo sono stati sottoposti a bootstrap contemporaneamente, i tempi di scadenza del certificato sono entro pochi minuti l'uno dall'altro. Questa relazione di temporizzazione si applica a tutti i nodi del piano di controllo. Puoi verificare le date di scadenza eseguendo i comandi precedenti su ciascun nodo del piano di controllo.

Esegui il comando seguente sulla workstation di amministrazione per verificare la data di scadenza del certificato client nel file kubeconfig del cluster:

grep 'client-certificate-data' KUBECONFIG_PATH | \
    awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2

La risposta ha il seguente aspetto:

Validity
    Not Before: Sep 17 22:27:53 2021 GMT
    Not After : Sep 17 22:33:16 2022 GMT

Esegui questo comando per cercare la scadenza del certificato di kubeconfig del cluster nel cluster di amministrazione:

kubectl get secret/CLUSTER_NAME-kubeconfig -n CLUSTER_NAMESPACE -o --kubeconfig=ADMIN_KUBECONFIG jsonpath='{.data.value}' | base64 --decode | grep client-certificate-data | awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2

Validity
    Not Before: Sep 17 22:27:53 2021 GMT
    Not After : Sep 17 22:33:16 2022 GMT

Il certificato kubeconfig nel cluster di amministrazione e il certificato nel file kubeconfig sulla workstation di amministrazione sono gli stessi. Pertanto, l'output di questo comando e quello del passaggio precedente devono corrispondere.

Rinnovare manualmente i certificati

Per rinnovare manualmente i certificati TLS per un cluster, segui le istruzioni riportate nelle sezioni seguenti.

Rinnova i certificati su ciascun nodo del piano di controllo

Completa i seguenti passaggi su ciascun nodo del piano di controllo del cluster interessato:

Esegui il backup della cartella /etc/kubernetes.

Esegui questo comando kubeadm per rinnovare tutti i certificati:

Il comando rinnova i certificati utilizzando le autorità di certificazione (CA) esistenti sul computer.

sudo kubeadm certs renew all

L'output comando è simile al seguente esempio:

certificate embedded in the kubeconfig file for the admin to use and for kubeadm itself renewed
certificate for serving the Kubernetes API renewed
certificate the apiserver uses to access etcd renewed
certificate for the API server to connect to kubelet renewed
certificate embedded in the kubeconfig file for the controller manager to use renewed
certificate for liveness probes to healthcheck etcd renewed
certificate for etcd nodes to communicate with each other renewed
certificate for serving etcd renewed
certificate for the front proxy client renewed
certificate embedded in the kubeconfig file for the scheduler manager to use renewed

Verifica che i certificati abbiano una nuova scadenza eseguendo il comando seguente:
```
sudo kubeadm certs check-expiration
```
Riavvia i container con i seguenti comandi:

Non tutti i componenti del piano di controllo supportano il ricaricamento dinamico dei certificati, pertanto questo passaggio riavvia i seguenti container: kube-apiserver, kube-scheduler, kube-controller-manager e etcd per recuperare i certificati rinnovati.

Ripeti i seguenti passaggi per ciascuno dei quattro contenitori:
1. Trova l'ID di ciascun contenitore:
```
sudo crictl ps | grep CONTAINER_NAME
```
  Sostituisci CONTAINER_NAME con il nome dei seguenti container: kube-apiserver, kube-scheduler, kube-controller-manager o etcd (non etcd-defrag).
  
  La risposta è simile alla seguente:
```
c331ade490cb6       28df10594cd92      26 hours ago       Running          kube-apiserver ...
```
  L'ID contenitore è il valore nella prima colonna.
  
  Nota: se i certificati sono scaduti, ti consigliamo di eseguire prima di tutto il passaggio seguente per i container kube-apiserver e etcd. quindi arresta i container kube-scheduler e kube-controller-manager.
2. Interrompi ogni container:
```
sudo crictl stop CONTAINER_ID
```
  Sostituisci CONTAINER_ID con l'ID container del passaggio precedente.
  
  All'uscita del container interrotto, kubelet crea un nuovo container al suo posto ed elimina quello arrestato. Se si verifica un errore, ad esempio context deadline exceeded (codice di errore DeadlineExceeded), esegui nuovamente il comando.

Verifica che la connettività sia stata ripristinata

A questo punto, i certificati kubeadm dovrebbero essere rinnovati su tutti i nodi del piano di controllo. Se vuoi rinnovare i certificati scaduti, procedi nel seguente modo.

Per verificare la connessione con il server API di Kubernetes, esegui il comando kubectl su qualsiasi nodo del piano di controllo:
```
kubectl get nodes --kubeconfig=/etc/kubernetes/admin.conf
```

La risposta dovrebbe restituire l'elenco di nodi per il cluster. Se i certificati vengono rinnovati correttamente, non verranno restituiti errori relativi a TLS o certificati.

Sostituisci il file kubeconfig del cluster

Per sostituire il file kubeconfig per il tuo cluster con uno con i certificati rinnovati, segui questi passaggi:

Per creare il nuovo file kubeconfig, esegui il comando kubectl seguente sulla workstation di amministrazione:
```
kubectl --kubeconfig="ADMIN_KUBECONFIG" get secret/CLUSTER_NAME-kubeconfig  \
    -n "CLUSTER_NAMESPACE"  -o jsonpath='{.data.value}'  | base64 --decode > new_kubeconfig.conf
```
Sostituisci quanto segue:
- ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
- CLUSTER_NAME: il nome del cluster per cui vuoi rinnovare i certificati.
- CLUSTER_NAMESPACE: lo spazio dei nomi del cluster per cui stai rinnovando i certificati.
Il file new_kubeconfig.conf contiene i dati aggiornati del certificato.
Verifica che la nuova kubeconfig funzioni eseguendo qualsiasi comando kubectl, utilizzando le nuove credenziali:
```
kubectl get nodes --kubeconfig new_kubeconfig.conf
```
Sostituisci i contenuti del vecchio file kubeconfig salvato nella directory del cluster nella workstation di amministrazione con il contenuto del nuovo file kubeconfig new-kubeconfig.conf.

Per impostazione predefinita, il percorso del file di configurazione del cluster è bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.

Verifica i certificati kubelet e riavvia `etcd-defrag`

Per completare il processo di rinnovo manuale dei certificati del cluster, esegui questi passaggi per ogni nodo del piano di controllo:

Accedi al nodo del piano di controllo e verifica il client kubelet e la data di scadenza del certificato di pubblicazione eseguendo i comandi seguenti:

I certificati kubelet vengono ruotati automaticamente se il piano di controllo è raggiungibile. Il periodo per il rinnovo automatico dei certificati kubelet è inferiore al periodo di scadenza per i certificati dei componenti del piano di controllo. È quindi probabile che i certificati kubelet siano stati rinnovati in precedenza
```
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text | grep Validity -A2
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-server-current.pem -text | grep Validity -A2
```
L'output di uno dei due comandi è simile al seguente esempio:
```
Validity
    Not Before: Nov 28 18:04:57 2022 GMT
    Not After : Nov 28 19:04:57 2023 GMT
```
Utilizza il comando seguente per riavviare il container etcd-defrag:

Il container etcd-defrag utilizza il certificato client apiserver-etcd per comunicare con etcd e deve essere riavviato per recuperare i certificati aggiornati.
```
kubectl rollout restart daemonset etcd-defrag -n kube-system --kubeconfig KUBECONFIG_PATH
```

Hai completato i passaggi manuali per rinnovare i certificati dei cluster. Verifica che tutti i pod funzionino correttamente e che non siano segnalati errori TLS per i container del piano di controllo.