Renouveler manuellement les certificats de cluster arrivés à expiration

Ce document explique comment renouveler manuellement les certificats arrivés à expiration pour vos clusters Anthos sur bare metal. Les certificats TLS (Transport Layer Security) sont utilisés par les composants du plan de contrôle des clusters Anthos sur bare metal. Lorsque ces certificats expirent, votre capacité à gérer les charges de travail et les cycles de vie des clusters est bloquée jusqu'au renouvellement des certificats. Pour en savoir plus sur l'impact des certificats expirés, consultez la section Expiration des certificats.

Par défaut, le délai d'expiration des certificats TLS est d'un an. Les clusters Anthos sur bare metal renouvellent automatiquement ces certificats lors des mises à niveau des clusters et lorsque vous alternerez les autorités de certification. Nous vous recommandons de mettre à niveau vos clusters régulièrement pour garantir leur sécurité, leur compatibilité et l'expiration des certificats TLS.

Erreurs causées par l'expiration du certificat

Si les certificats TLS de votre cluster expirent, les contrôleurs principaux ne peuvent pas établir de connexions TLS avec le serveur d'API Kubernetes. Ce manque de connectivité entraîne les erreurs suivantes:

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

Lorsque vous utilisez kubectl pour obtenir vos nœuds de cluster, la réponse inclut une erreur qui fait référence à l'expiration du certificat:
```
kubectl get nodes --kubeconfig KUBECONFIG_PATH
```
Remplacez KUBECONFIG_PATH par le chemin d'accès au fichier kubeconfig de votre cluster.

Une fois les certificats arrivés à expiration, la réponse se présente comme suit:
```
Unable to connect to the server: x509: certificate has expired or is not yet valid
```

could not connect: x509 ou rejected connection

Les certificats arrivés à expiration bloquent l'accès au cluster etcd, car les pairs ne peuvent pas communiquer entre eux. Les journaux etcd peuvent contenir des entrées d'erreur suivantes:

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

Vérifier les délais d'expiration des certificats

Cette section explique comment vérifier les délais d'expiration des certificats utilisés par votre cluster. Procédez comme suit sur chaque nœud du plan de contrôle :

Pour vérifier les délais d'expiration des certificats:

Connectez-vous à l'une des machines de nœuds du plan de contrôle et exécutez la commande suivante:

sudo kubeadm certs check-expiration

Le résultat de la commande répertorie les certificats créés par kubeadm pour les composants du plan de contrôle et leur date d'expiration:

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

Exécutez la commande suivante pour vérifier les délais d'expiration des certificats 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 réponse pour chaque commande se présente comme suit:
```
Validity
    Not Before: Sep 17 22:27:53 2021 GMT
    Not After : Sep 17 22:33:16 2022 GMT
```
Si tous les nœuds du plan de contrôle ont été amorcés en même temps, les délais d'expiration du certificat se situent à quelques minutes les uns des autres. Cette relation temporelle s'applique à tous les nœuds du plan de contrôle. Vous pouvez vérifier les délais d'expiration en exécutant les commandes précédentes sur chaque nœud du plan de contrôle.

Exécutez la commande suivante sur le poste de travail administrateur pour vérifier le délai d'expiration du certificat client dans le fichier kubeconfig du cluster:

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

La réponse se présente comme suit:

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

Exécutez la commande suivante pour rechercher le délai d'expiration du certificat du cluster kubeconfig dans le cluster d'administrateur:
```
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
```
Le certificat kubeconfig dans le cluster d'administrateur et le certificat dans le fichier kubeconfig sur le poste de travail administrateur sont identiques. Par conséquent, le résultat de cette commande et de la commande de l'étape précédente doivent correspondre.

Renouveler des certificats manuellement

Pour renouveler manuellement les certificats TLS pour un cluster, suivez les instructions décrites dans les sections suivantes.

Renouveler les certificats sur chaque nœud du plan de contrôle

Procédez comme suit sur chaque nœud de plan de contrôle du cluster concerné:

Sauvegardez le dossier /etc/kubernetes.

Exécutez la commande kubeadm suivante pour renouveler tous les certificats:

La commande renouvelle les certificats à l'aide des autorités de certification existantes sur la machine.

sudo kubeadm certs renew all

Le résultat de la commande ressemble à l'exemple suivant:

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

Vérifiez que les certificats ont un nouveau délai d'expiration en exécutant la commande suivante:
```
sudo kubeadm certs check-expiration
```
Redémarrez les conteneurs à l'aide des commandes suivantes:

Tous les composants du plan de contrôle ne sont pas compatibles avec l'actualisation dynamique de certificats. Par conséquent, cette étape redémarre les conteneurs suivants: kube-apiserver, kube-scheduler, kube-controller-manager et etcd pour récupérer les certificats renouvelés.

Répétez les étapes suivantes pour chacun des quatre conteneurs:
1. Recherchez l'ID de chaque conteneur:
```
sudo crictl ps | grep CONTAINER_NAME
```
  Remplacez CONTAINER_NAME par le nom des conteneurs suivants: kube-apiserver, kube-scheduler, kube-controller-manager ou etcd (pas etcd-defrag).
  
  La réponse ressemble à ce qui suit:
```
c331ade490cb6       28df10594cd92      26 hours ago       Running          kube-apiserver ...
```
  L'ID du conteneur correspond à la valeur de la première colonne.
  
  Remarque :Si vos certificats ont expiré, nous vous recommandons d'effectuer d'abord l'étape suivante pour les conteneurs kube-apiserver et etcd. Arrêtez ensuite les conteneurs kube-scheduler et kube-controller-manager.
2. Arrêtez chaque conteneur:
```
sudo crictl stop CONTAINER_ID
```
  Remplacez CONTAINER_ID par l'ID de conteneur de l'étape précédente.
  
  Lorsque le conteneur arrêté s'arrête, kubelet crée un conteneur à la place et supprime le conteneur arrêté. Si vous rencontrez une erreur telle que context deadline exceeded (code d'erreur DeadlineExceeded), réexécutez la commande.

Vérifier que la connectivité est rétablie

À ce stade, les certificats kubeadm doivent être renouvelés sur tous les nœuds du plan de contrôle. Si vous renouvelez des certificats arrivés à expiration, procédez comme suit.

Pour vérifier la connexion au serveur d'API Kubernetes, exécutez la commande kubectl suivante sur n'importe quel nœud de plan de contrôle:
```
kubectl get nodes --kubeconfig=/etc/kubernetes/admin.conf
```

La réponse doit renvoyer la liste des nœuds du cluster. Si vos certificats sont renouvelés correctement, aucune erreur TLS ni aucune erreur de certificat n'est renvoyée.

Remplacer le fichier kubeconfig du cluster

Pour remplacer le fichier kubeconfig de votre cluster par un fichier contenant les certificats renouvelés, procédez comme suit:

Pour créer le fichier kubeconfig, exécutez la commande kubectl suivante sur le poste de travail administrateur:
```
kubectl --kubeconfig="ADMIN_KUBECONFIG" get secret/CLUSTER_NAME-kubeconfig  \
    -n "CLUSTER_NAMESPACE"  -o jsonpath='{.data.value}'  | base64 --decode > new_kubeconfig.conf
```
Remplacez les éléments suivants :
- ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur.
- CLUSTER_NAME : nom du cluster pour lequel vous renouvelez les certificats.
- CLUSTER_NAMESPACE : espace de noms du cluster pour lequel vous renouvelez les certificats.
Le fichier new_kubeconfig.conf contient les données de certificat mises à jour.
Vérifiez que le nouveau fichier kubeconfig fonctionne en exécutant une commande kubectl à l'aide des nouveaux identifiants:
```
kubectl get nodes --kubeconfig new_kubeconfig.conf
```
Remplacez le contenu de l'ancien fichier kubeconfig enregistré dans le répertoire du cluster sur le poste de travail administrateur par le contenu du nouveau fichier kubeconfig new-kubeconfig.conf.

Par défaut, le chemin d'accès au fichier de configuration du cluster est bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.

Vérifier les certificats kubelet et redémarrer `etcd-defrag`

Pour terminer le processus de renouvellement manuel des certificats de cluster, procédez comme suit pour chaque nœud de plan de contrôle:

Connectez-vous au nœud du plan de contrôle et vérifiez le client kubelet et le délai d'expiration du certificat en exécutant les commandes suivantes:

Les certificats Kubelet sont alternés automatiquement tant que le plan de contrôle est accessible. La période de renouvellement automatique des certificats kubelet est plus courte que celle des certificats des composants du plan de contrôle. Par conséquent, il est probable que les certificats kubelet aient été renouvelés avant
```
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
```
Le résultat de l'une ou l'autre des commandes ressemble à ceci:
```
Validity
    Not Before: Nov 28 18:04:57 2022 GMT
    Not After : Nov 28 19:04:57 2023 GMT
```
Utilisez la commande suivante pour redémarrer le conteneur etcd-defrag:

Le conteneur etcd-defrag utilise le certificat client apiserver-etcd pour communiquer avec etcd. Vous devez le redémarrer pour récupérer les certificats mis à jour.
```
kubectl rollout restart daemonset etcd-defrag -n kube-system --kubeconfig KUBECONFIG_PATH
```

Vous avez terminé la procédure manuelle pour renouveler les certificats de cluster. Vérifiez que tous les pods s'exécutent correctement et qu'aucune erreur TLS n'est signalée pour les conteneurs du plan de contrôle.