Rinnova manualmente i certificati del cluster scaduti

Il rinnovo manuale dei certificati consente di ripristinare le operazioni del control plane in Google Distributed Cloud alla scadenza dei certificati Transport Layer Security (TLS). Non puoi gestire i workload e i cicli di vita dei cluster finché non rinnovi i certificati TLS scaduti. Per saperne di più sull'impatto dei certificati scaduti, consulta Scadenza del certificato.

I certificati TLS, inclusi i certificati etcd, hanno un periodo di scadenza predefinito di un anno e non vengono aggiornati automaticamente. Per evitare che i certificati scadano e per mantenere i cluster sicuri e supportati, ti consigliamo di eseguire regolarmente l'upgrade dei cluster. Google Distributed Cloud rinnova questi certificati durante gli upgrade dei cluster e quando ruoti le autorità di certificazione. Puoi utilizzare queste indicazioni per recuperare i cluster se i certificati scadono prima di un upgrade. Per informazioni dettagliate, consulta Ruoli e attività comuni degli utenti GKE.

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 connettività causa i seguenti errori:

• Unable to connect to the server: x509

  Quando utilizzi kubectl per ottenere i nodi del cluster, la risposta include un errore che indica che i certificati sono scaduti, simile al seguente output di esempio:

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

Controlla le date/ore di scadenza dei certificati

Per controllare le date di scadenza dei certificati, esegui questi passaggi su ogni nodo del control plane:

1. Accedi a una delle macchine dei nodi del control plane ed esegui il seguente comando:

   sudo kubeadm certs check-expiration
   

   L'output comando elenca i certificati creati da kubeadm per i componenti del control plane 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
   

2. Esegui questo 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 control plane sono stati avviati contemporaneamente, le date di scadenza dei certificati sono distanziate di pochi minuti. Questa relazione temporale si applica a tutti i nodi del control plane. Puoi verificare le date di scadenza eseguendo i comandi precedenti su ciascun nodo del control plane.

3. Esegui questo comando sulla workstation di amministrazione per controllare la data e l'ora 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 a questo output di esempio:

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

4. Esegui questo comando per cercare la scadenza del certificato per il 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 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 file kubeconfig sulla workstation di amministrazione sono gli stessi. Pertanto, l'output di questo comando e quello del comando del passaggio precedente devono corrispondere.

Rinnova i certificati manualmente

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

Punto chiave: le seguenti istruzioni rinnovano i certificati scaduti e non scaduti. In entrambi i casi, il periodo di scadenza dei certificati TLS rinnovati sul cluster viene reimpostato su un anno. Ti consigliamo vivamente di rinnovare i certificati del cluster prima della scadenza per evitare tempi di inattività significativi del cluster. Il metodo consigliato per rinnovare i certificati prima della scadenza è eseguire regolarmente l'upgrade dei cluster.

Rinnova i certificati su ogni nodo del control plane

Esegui i seguenti passaggi su ciascun nodo del control plane del cluster interessato:

Importante: rinnova i certificati su un solo nodo alla volta. Esegui tutti i passaggi prima di iniziare su un nuovo nodo del control plane.

1. Esegui il backup della cartella /etc/kubernetes.

2. Esegui il seguente comando kubeadm 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 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
   

3. Verifica che i certificati abbiano una nuova data di scadenza eseguendo il seguente comando:

   sudo kubeadm certs check-expiration
   

4. Non tutti i componenti del control plane supportano il ricaricamento dinamico dei certificati. Per recuperare i certificati rinnovati, i passaggi seguenti riavviano i seguenti container: kube-apiserver, kube-scheduler e kube-controller-manager.

   Ripeti i passaggi seguenti per ciascuno dei quattro container:

   Nota: Se i certificati sono scaduti, si consiglia di eseguire prima il seguente passaggio per il contenitore kube-apiserver. Poi, arresta i container kube-scheduler e kube-controller-manager.

   1. Trova l'ID contenitore per ogni contenitore:

      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 al seguente output:

      c331ade490cb6       28df10594cd92      26 hours ago       Running          kube-apiserver ...
      

      L'ID contenitore è 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 interrotto esce, kubelet crea un nuovo container al suo posto ed elimina quello interrotto. 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

I certificati kubeadm dovrebbero ora essere rinnovati su tutti i nodi del control plane. Se stai rinnovando i certificati scaduti, segui questo passaggio:

• Per verificare la connessione con il server API Kubernetes, esegui il seguente comando kubectl 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 relativi ai certificati.

Aggiorna il secret kubeconfig nel cluster

I passaggi seguenti utilizzano i certificati rinnovati del file admin.conf per aggiornare il secret kubeconfig del tuo 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 nel secret, segui questi passaggi su un nodo del control plane:

1. Utilizza sed per sostituire kubernetes nel file admin.conf con il nome del tuo 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
   

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

3. Esegui questi comandi per aggiornare il secret kubeconfig nel tuo 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 -
   

Sostituisci il file kubeconfig del cluster

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

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

2. Per creare il nuovo file kubeconfig, esegui questo comando kubectl 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 nella workstation di amministrazione da un nodo del control plane.

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

3. Verifica che il nuovo kubeconfig funzioni eseguendo un comando kubectl utilizzando le nuove credenziali:

   kubectl get nodes --kubeconfig new_kubeconfig.conf
   

4. 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, esegui i seguenti passaggi per ogni nodo del control plane:

1. 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 per il rinnovo automatico dei certificati kubelet è più breve del periodo di scadenza dei certificati dei componenti del control plane. Pertanto, è probabile che i certificati kubelet siano già 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 al seguente esempio:

   Validity
       Not Before: Nov 28 18:04:57 2022 GMT
       Not After : Nov 28 19:04:57 2023 GMT
   

2. Utilizza il seguente comando 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 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 tutti i pod funzionino correttamente e che non vengano segnalati errori TLS per i container del control plane.

Passaggi successivi

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

• Requisiti per l'apertura di una richiesta di assistenza.
• Strumenti per aiutarti a risolvere i problemi, ad esempio la configurazione dell'ambiente, i log e le metriche.
• Componenti supportati.