Questo documento descrive come rinnovare manualmente i certificati scaduti per Google Distributed Cloud. I certificati TLS (Transport Layer Security) vengono utilizzati dai componenti del piano di controllo di Google Distributed Cloud. Alla scadenza di questi certificati, la tua capacità di gestire i carichi di lavoro e i cicli di vita dei cluster viene bloccata fino a quando i certificati non possono essere rinnovati. Per ulteriori informazioni sull'impatto dei certificati scaduti, consulta Scadenza dei certificati.
Per impostazione predefinita, i certificati TLS hanno una scadenza di 1 anno. Google Distributed Cloud rinnova questi certificati automaticamente durante gli upgrade dei cluster e quando ruoti le autorità di certificazione. Ti consigliamo di eseguire regolarmente l'upgrade dei cluster per mantenerli sicuri e supportati e per evitare che i certificati TLS scadano.
Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.Errori causati dalla scadenza del certificato
Se i certificati TLS nel cluster scadono, i controller principali non possono stabilire connessioni TLS con il server API Kubernetes. Questa mancanza di connettività causa i seguenti errori:
Impossibile connettersi al server: x509
Quando utilizzi
kubectl
per recuperare i nodi del cluster, la risposta include un errore relativo alla scadenza dei certificati, simile all'output di 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, poiché i peer non possono comunicare tra loro. I log etcd potrebbero contenere voci di errore come 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 verificare i tempi di scadenza dei certificati, esegui questi passaggi su ciascun nodo del piano di controllo:
Accedi a una delle macchine dei nodi 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, come mostrato nell'output di esempio seguente: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 controllare le scadenze 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 output di esempio:
Validity Not Before: Sep 17 22:27:53 2021 GMT Not After : Sep 17 22:33:16 2022 GMT
Se il bootstrap di tutti i nodi del piano di controllo è stato eseguito contemporaneamente, i tempi di scadenza dei certificati sono a pochi minuti l'uno dall'altro. Questa relazione di temporizzazione si applica a tutti i nodi del piano di controllo. Puoi verificare i tempi di scadenza eseguendo i comandi precedenti su ciascun nodo del piano di controllo.
Esegui il comando seguente sulla workstation di amministrazione per controllare la 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 cercare la scadenza del certificato per il cluster 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 al seguente 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 file kubeconfig sulla workstation di amministrazione sono uguali. Di conseguenza, l'output di questo comando e il comando del passaggio precedente devono corrispondere.
Rinnova i certificati manualmente
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
Esegui questi 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 nella 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 data di scadenza eseguendo questo comando:
sudo kubeadm certs check-expiration
Non tutti i componenti del piano di controllo supportano il ricaricamento dinamico dei certificati. Per recuperare i certificati rinnovati, i seguenti passaggi riavviano i seguenti container:
kube-apiserver
,kube-scheduler
,kube-controller-manager
eetcd
.Ripeti questi passaggi per ognuno dei quattro contenitori:
Trova l'ID contenitore per ciascun contenitore:
sudo crictl ps | grep CONTAINER_NAME
Sostituisci
CONTAINER_NAME
con il nome dei seguenti contenitori:kube-apiserver
,kube-scheduler
,kube-controller-manager
oetcd
(nonetcd-defrag
).La risposta è simile al seguente output:
c331ade490cb6 28df10594cd92 26 hours ago Running kube-apiserver ...
L'ID contenitore è il valore nella prima colonna.
Arresta ogni container:
sudo crictl stop CONTAINER_ID
Sostituisci CONTAINER_ID con l'ID contenitore del passaggio precedente.
Quando il container arrestato viene chiuso, kubelet crea un nuovo container al suo posto ed elimina quello arrestato. Se si verifica un errore, ad esempio
context deadline exceeded
(codice di erroreDeadlineExceeded
), esegui nuovamente il comando.
Verifica che la connettività venga ripristinata
I certificati kubeadm ora dovrebbero essere rinnovati su tutti i nodi del piano di controllo. Se stai rinnovando certificati scaduti, segui questi passaggi:
Per verificare la connessione con il server API Kubernetes, esegui questo 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 vengono restituiti errori di TLS o di certificato.
Sostituisci il file kubeconfig del cluster
Per sostituire il file kubeconfig per il tuo cluster con uno che contiene i certificati rinnovati, segui questi passaggi:
Per creare il nuovo file kubeconfig, esegui questo comando
kubectl
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 al 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 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 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 il processo di rinnovo manuale dei certificati del cluster, esegui questi passaggi per ciascun nodo del piano di controllo:
Accedi al nodo del piano di controllo e verifica la scadenza del client kubelet e della data di scadenza del certificato di distribuzione eseguendo questi comandi:
I certificati kubelet vengono ruotati automaticamente finché il piano di controllo è raggiungibile. Il periodo per il rinnovo automatico dei certificati kubelet è più breve di quello per i certificati dei componenti del piano di controllo. Di conseguenza, è probabile che i certificati kubelet siano stati rinnovati prima:
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 container
etcd-defrag
:Il container
etcd-defrag
utilizza il certificato clientapiserver-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
Dopo aver completato questi passaggi manuali per rinnovare i certificati del cluster, verifica che tutti i pod funzionino correttamente e che non vengano segnalati errori TLS per i container del piano di controllo.