Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Rinnova manualmente i certificati del cluster scaduti

Questo documento descrive come rinnovare manualmente i certificati scaduti per Google Distributed Cloud. I certificati Transport Layer Security (TLS) vengono utilizzati dai componenti del piano di controllo di Google Distributed Cloud. Quando questi certificati scadono, la tua capacità di gestire i workload e i cicli di vita dei cluster viene bloccata fino a quando i certificati non possono essere rinnovati. Per saperne di più sull'impatto dei certificati scaduti, consulta Scadenza dei certificati.

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

Per impostazione predefinita, i certificati TLS, inclusi i certificati etcd, hanno un periodo di scadenza di 1 anno. Google Distributed Cloud rinnova questi certificati durante gli upgrade dei cluster e quando ruoti le autorità di certificazione. Questi certificati non vengono aggiornati periodicamente da soli. Ti consigliamo di eseguire regolarmente l'upgrade dei cluster per mantenerli sicuri, supportati e per evitare la scadenza dei certificati TLS.

Errori causati dalla scadenza dei certificati

Se i certificati TLS del 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 che indica che i certificati sono scaduti, 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 gli orari di scadenza dei certificati

Per controllare gli orari di scadenza dei certificati, esegui i seguenti passaggi su ogni nodo del piano di controllo:

Accedi a una delle macchine dei nodi del piano di controllo ed esegui il comando seguente:

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 il comando seguente per controllare gli orari 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 a ogni comando è simile all'output di esempio seguente:
```
Validity
    Not Before: Sep 17 22:27:53 2021 GMT
    Not After : Sep 17 22:33:16 2022 GMT
```
Se tutti i nodi del control plane sono stati avviati contemporaneamente, gli orari di scadenza dei certificati sono a pochi minuti di distanza l'uno dall'altro. Questa relazione temporale si applica a tutti i nodi del piano di controllo. Puoi verificare gli orari di scadenza eseguendo i comandi precedenti su ogni nodo del control plane.

Esegui il comando seguente sulla workstation di amministrazione per controllare l'orario 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 all'output di esempio seguente:

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

Esegui il comando seguente per cercare la scadenza del certificato kubeconfig del cluster nel cluster di amministrazione:
```
kubectl get secret/CLUSTER_NAME-kubeconfig \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG \
    -o jsonpath='{.data.value}' | base64 --decode | grep client-certificate-data | \
    awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2
```
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.
La risposta è simile all'output di esempio seguente:
```
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 del comando del passaggio precedente devono corrispondere.

Rinnovare i certificati manualmente

Per rinnovare manualmente i certificati TLS per un cluster, segui le istruzioni nelle 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 il comando kubeadm seguente per rinnovare tutti i certificati. Il comando rinnova i certificati utilizzando le autorità di certificazione (CA) esistenti 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 data di 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 recuperare i certificati rinnovati, i seguenti passaggi riavviano i container kube-apiserver, kube-scheduler e kube-controller-manager.

Ripeti i seguenti passaggi per ognuno dei quattro container:

Nota: se i certificati sono scaduti, ti consigliamo di eseguire prima il seguente passaggio per il container kube-apiserver. Poi, arresta i container kube-scheduler e kube-controller-manager.
1. Trova l'ID container per ogni container:
```
sudo crictl ps | grep CONTAINER_NAME
```
  Sostituisci CONTAINER_NAME con il nome dei seguenti container: kube-apiserver, kube-scheduler o kube-controller-manager.
  
  La risposta è simile all'output seguente:
```
c331ade490cb6       28df10594cd92      26 hours ago       Running          kube-apiserver ...
```
  L'ID container è il valore nella prima colonna.
2. Arresta ogni container:
```
sudo crictl stop CONTAINER_ID
```
  Sostituisci CONTAINER_ID con l'ID container 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 errore DeadlineExceeded), esegui di nuovo il comando.

Verificare che la connettività sia stata ripristinata

I certificati kubeadm dovrebbero essere rinnovati su tutti i nodi del control plane. Se stai rinnovando i certificati scaduti, esegui il seguente passaggio:

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

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

Aggiornare il secret kubeconfig nel cluster

I seguenti passaggi utilizzano i certificati rinnovati dal file admin.conf per aggiornare il secret kubeconfig per il cluster. Tuttavia, i contenuti del file admin.conf aggiornato non possono essere utilizzati così come sono. Devi prima creare una copia del file admin.conf con alcune modifiche necessarie.

Per aggiornare il nuovo kubeconfig al secret, esegui i seguenti passaggi su un nodo del control plane:

Utilizza sed per sostituire kubernetes nel file admin.conf con il nome del cluster e scrivi le modifiche in un nuovo file, kubeconfig_secret.conf:
```
sed "s/kubernetes/CLUSTER_NAME/g" \
    /etc/kubernetes/admin.conf > /etc/kubernetes/kubeconfig_secret.conf
```

Utilizza diff per verificare che il file kubeconfig_secret.conf sia stato aggiornato:

diff /etc/kubernetes/admin.conf /etc/kubernetes/kubeconfig_secret.conf

La risposta mostra tutti i punti in cui il file kubeconfig_secret.conf è diverso dal file admin.conf aggiornato. Ad esempio, se hai eseguito il passaggio precedente per un cluster denominato demo-cluster, l'output sarà simile al seguente:

6c6
<   name: kubernetes
---
>   name: demo-cluster
9,12c9,12
<     cluster: kubernetes
<     user: kubernetes-admin
<   name: kubernetes-admin@kubernetes
< current-context: kubernetes-admin@kubernetes
---
>     cluster: demo-cluster
>     user: demo-cluster-admin
>   name: demo-cluster-admin@demo-cluster
> current-context: demo-cluster-admin@demo-cluster
16c16
< - name: kubernetes-admin
---
> - name: demo-cluster-admin

Esegui i seguenti comandi per aggiornare il secret kubeconfig nel cluster:

CLUSTER_KUBECONFIG_BASE64=$(base64 /etc/kubernetes/kubeconfig_secret.conf -w 0)

kubectl get secret/CLUSTER_NAME-kubeconfig \
    -n CLUSTER_NAMESPACE \
    --kubeconfig /etc/kubernetes/admin.conf -o json | jq \
    --arg conf "${CLUSTER_KUBECONFIG_BASE64}" '.data."value" |= $conf' | kubectl apply \
    --kubeconfig /etc/kubernetes/admin.conf -f -

Sostituire il file kubeconfig del cluster

Per sostituire il file kubeconfig del cluster con uno che contiene i certificati rinnovati, segui questi passaggi:

Copia il file admin.conf da uno dei nodi del control plane del cluster alla workstation di amministrazione.

Come indicato nelle sezioni precedenti, il file admin.conf si trova nella directory etc/kubernetes sui nodi del control plane del cluster.
Per creare il nuovo file kubeconfig, esegui il comando kubectl seguente sulla workstation di amministrazione:
```
kubectl --kubeconfig ADMIN_CONF_PATH get secret/CLUSTER_NAME-kubeconfig  \
    -n "CLUSTER_NAMESPACE" -o jsonpath='{.data.value}'  | \
    base64 --decode > new_kubeconfig.conf
```
Sostituisci quanto segue:
- ADMIN_CONF_PATH: il percorso del file admin.conf che è stato copiato da un nodo del piano di controllo alla workstation 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 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.

Verificare i certificati kubelet e riavviare `etcd-defrag`

Per completare la procedura di rinnovo manuale dei certificati del cluster, esegui i seguenti passaggi per ogni nodo del piano di controllo:

Accedi al nodo del control plane e verifica la data di scadenza del certificato client e di pubblicazione di kubelet eseguendo i seguenti comandi:

I certificati kubelet vengono ruotati automaticamente purché il control plane sia raggiungibile. Il periodo di rinnovo automatico dei certificati kubelet è più breve del periodo di scadenza dei 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 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
```

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

Passaggi successivi

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud. Puoi anche consultare Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui:

Requisiti per l'apertura di una richiesta di assistenza.
Strumenti per la risoluzione dei problemi, come la configurazione dell'ambiente, i log e le metriche.
Componenti supportati.