Anthos clusters on bare metal è ora Google Distributed Cloud (solo software) per bare metal. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

Rinnova manualmente i certificati cluster scaduti

Questo documento descrive come rinnovare manualmente i certificati scaduti per Google Distributed Cloud. I certificati TLS (Transport Layer Security) sono utilizzati da i componenti del piano di controllo di Google Distributed Cloud. Quando questi certificati scadono, la possibilità di gestire i carichi di lavoro e i cicli di vita dei cluster viene bloccata finché non è possibile rinnovarli. Per ulteriori informazioni sull'impatto certificati scaduti, consulta Scadenza del certificato:

Questa pagina è rivolta agli amministratori, agli architetti e agli operatori che gestiscono ciclo di vita dell'infrastruttura tecnica sottostante e rispondere ad avvisi e pagine quando gli obiettivi del livello di servizio (SLO) non vengono soddisfatti o le applicazioni non vanno a buon fine. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Per impostazione predefinita, i certificati TLS hanno un periodo di scadenza di 1 anno. Google Distributed Cloud rinnova questi certificati automaticamente durante il cluster upgrade e quando Ruota le autorità di certificazione. I nostri suggerimenti eseguire regolarmente l'upgrade dei cluster per mantenerli sicuri, supportati impediscono la scadenza dei certificati TLS.

Se hai bisogno di ulteriore assistenza, contatta Assistenza clienti Google Cloud.

Errori causati dalla scadenza del certificato

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

Impossibile connettersi al server: x509

Quando utilizzi kubectl per recuperare i nodi del cluster, la risposta include un messaggio di errore che indica che i certificati sono scaduti, simile all'output dell'esempio seguente:
```
Unable to connect to the server: x509: certificate has expired or is not yet valid
```

Impossibile connettersi: x509 o Connessione rifiutata

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 quali le seguenti:

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 "")

Controllare le date di scadenza dei certificati

Per controllare le date di scadenza dei certificati, segui questi passaggi su ogni nodo del piano di controllo:

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

sudo kubeadm certs check-expiration

L'output del comando elenca i certificati creati da kubeadm per i componenti del piano di controllo e la relativa scadenza, come mostrato nell'esempio di output riportato di seguito:

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 il seguente comando per controllare le date di 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 è simile al seguente esempio di 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 avviati contemporaneamente, le scadenze dei certificati sono a distanza di pochi minuti l'una dall'altra. Questo tempo si applica a tutti i nodi del piano di controllo. Puoi verificare i tempi di scadenza eseguendo i comandi precedenti su ogni nodo del control plane.

Esegui il comando seguente sulla workstation di amministrazione per controllare 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 è simile al seguente output di esempio:

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

Esegui questo comando per controllare la scadenza del certificato kubeconfig 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
```
La risposta è simile a questo output di esempio:
```
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 il file kubeconfig sulla workstation di amministrazione è lo stesso. Pertanto, per questo comando e il comando del passaggio precedente deve corrispondere.

Rinnovare i certificati manualmente

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

Rinnovare i certificati su ogni nodo del piano di controllo

Esegui i seguenti passaggi su ogni nodo del piano di controllo del cluster interessato:

Esegui il backup della cartella /etc/kubernetes.

Esegui questo comando kubeadm per rinnovare tutti i certificati. La rinnova i certificati utilizzando le autorità di certificazione esistenti (CA) sulla macchina:

sudo kubeadm certs renew all

L'output comando è simile all'esempio seguente:

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
```
Non tutti i componenti del piano di controllo supportano il ricaricamento dinamico dei certificati. Per scegliere i certificati rinnovati, i passaggi seguenti riavviano container: kube-apiserver, kube-scheduler, kube-controller-manager, e etcd.

Ripeti i seguenti passaggi per ciascuno dei quattro contenitori:
1. Trova l'ID contenitore per 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 al seguente output:
```
c331ade490cb6       28df10594cd92      26 hours ago       Running          kube-apiserver ...
```
  L'ID contenitore è il valore nella prima colonna.
  
  Nota: se i tuoi certificati sono scaduti, ti consigliamo di eseguire prima il passaggio seguente per i contenitori kube-apiserver e etcd. Poi interrompi kube-scheduler e kube-controller-manager e container.
2. Interrompi ogni container:
```
sudo crictl stop CONTAINER_ID
```
  Sostituisci CONTAINER_ID con l'ID container del passaggio precedente.
  
  Quando il contenitore fermato esce, kubelet ne crea uno nuovo al suo posto ed elimina quello fermato. Se riscontri un errore, ad esempio context deadline exceeded (codice di errore DeadlineExceeded), esegui nuovamente il comando.

Verifica che la connettività sia stata ripristinata

I certificati kubeadm ora dovrebbero essere rinnovati su tutti i nodi del piano di controllo. Se rinnovate i certificati scaduti, seguite questo passaggio:

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

La risposta dovrebbe restituire l'elenco dei nodi del cluster. Se i certificati sono stati rinnovati correttamente, non vengono restituiti errori TLS o dei certificati.

Sostituisci il file kubeconfig del cluster

Per sostituire il file kubeconfig del cluster con uno con i certificati rinnovati:

Per creare il nuovo file kubeconfig, esegui questo comando kubectl la 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 stai rinnovando i certificati.
- CLUSTER_NAMESPACE: lo spazio dei nomi del cluster per cui stai rinnovando i certificati.
Il file new_kubeconfig.conf contiene i dati del certificato aggiornati.
Verifica che il nuovo kubeconfig funzioni eseguendo un 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 sulla workstation di amministrazione con i contenuti 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 la procedura di rinnovo manuale dei certificati del cluster, svolgi i seguenti passaggi per ogni nodo del control plane:

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

I certificati Kubelet vengono ruotati automaticamente purché il control plane sia raggiungibile. Il periodo per il rinnovo automatico dei certificati kubelet è più breve del periodo di scadenza per i certificati dei componenti del piano di controllo. Pertanto, è 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 entrambi i comandi è simile all'esempio seguente:
```
Validity
    Not Before: Nov 28 18:04:57 2022 GMT
    Not After : Nov 28 19:04:57 2023 GMT
```
Utilizza il seguente comando per riavviare il contenitore etcd-defrag:

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

Dopo aver completato questi passaggi manuali per rinnovare i certificati del cluster, verifica che che tutti i pod siano in esecuzione correttamente e che non vengano segnalati errori TLS per il controllo del piano di controllo.

Passaggi successivi