Cette page a été traduite par l'API Cloud Translation.

Renouveler manuellement les certificats de cluster arrivés à expiration

Ce document explique comment renouveler manuellement les certificats expirés pour votre Google Distributed Cloud. Les certificats TLS (Transport Layer Security) sont utilisés par les composants du plan de contrôle de Google Distributed Cloud. Lorsque ces certificats expirent, vous ne pouvez plus gérer les charges de travail ni les cycles de vie des clusters tant qu'ils n'ont pas été renouvelés. Pour en savoir plus sur l'impact des certificats expirés, consultez Expiration des certificats.

Cette page s'adresse aux administrateurs, aux architectes et aux opérateurs qui gèrent le cycle de vie de l'infrastructure technologique sous-jacente, et qui s'occupent des alertes et des pages lorsque les objectifs de niveau de service (SLO) ne sont pas atteints ou que les applications présentent des défaillances. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud, consultez Rôles utilisateur et tâches courantes de GKE.

Par défaut, les certificats TLS, y compris les certificats etcd, ont un délai d'expiration d'un an. Google Distributed Cloud renouvelle ces certificats lors des mises à niveau du cluster et lorsque vous alternez les autorités de certification. Ces certificats ne se mettent pas à jour automatiquement de manière périodique. Nous vous recommandons de mettre à niveau vos clusters régulièrement pour les sécuriser, assurer le maintien de leur compatibilité et éviter l'expiration des certificats TLS.

Erreurs causées par l'expiration des certificats

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 :

Impossible de se connecter au serveur : x509

Lorsque vous utilisez kubectl pour obtenir les nœuds de votre cluster, la réponse inclut une erreur indiquant que vos certificats ont expiré, qui est semblable à l'exemple de résultat suivant :
```
Unable to connect to the server: x509: certificate has expired or is not yet valid
```
Impossible de se connecter : x509 ou Connexion refusée

Les certificats expirés 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 semblables à celles-ci :
```
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 dates d'expiration des certificats

Pour vérifier les dates d'expiration des certificats, procédez comme suit sur chaque nœud du plan de contrôle :

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

sudo kubeadm certs check-expiration

Le résultat de la commande liste les certificats créés par kubeadm pour les composants du plan de contrôle et leur délai d'expiration, comme le montre l'exemple de résultat suivant :

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 dates 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 ressemble à l'exemple de résultat suivant :
```
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 des certificats présentent quelques minutes d'écart. Cette relation temporelle s'applique à tous les nœuds du plan de contrôle. Vous pouvez vérifier les dates 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 la station 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 est semblable à cet exemple de sortie :

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 pour le fichier kubeconfig du cluster dans le cluster d'administrateur :
```
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
```
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.
La réponse est semblable à cet exemple de sortie :
```
Validity
    Not Before: Sep 17 22:27:53 2021 GMT
    Not After : Sep 17 22:33:16 2022 GMT
```
Le certificat kubeconfig du cluster d'administrateur et celui du fichier kubeconfig sur la station de travail administrateur sont identiques. Par conséquent, le résultat de cette commande et celui de la commande de l'étape précédente doivent correspondre.

Renouveler manuellement les certificats

Pour renouveler manuellement les certificats TLS d'un cluster, suivez les instructions des sections suivantes.

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

Effectuez la procédure suivante sur chaque nœud du 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 existant sur la machine :

sudo kubeadm certs renew all

Le résultat de la commande ressemble à celui de l'exemple ci-dessous :

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 une nouvelle date d'expiration en exécutant la commande suivante :
```
sudo kubeadm certs check-expiration
```
Tous les composants du plan de contrôle ne permettent pas le rechargement dynamique des certificats. Pour vous permettre de récupérer les certificats renouvelés, les étapes suivantes redémarrent les conteneurs kube-apiserver, etcd, kube-scheduler et kube-controller-manager.

Répétez les étapes suivantes pour chacun des quatre conteneurs :

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.
1. Recherchez l'ID de chaque conteneur :
```
sudo crictl ps | grep CONTAINER_NAME
```
  Remplacez CONTAINER_NAME par le nom des conteneurs suivants : kube-apiserver, etcd (mais pas etcd-defrag), kube-scheduler ou kube-controller-manager.
  
  La réponse est semblable à ce qui suit :
```
c331ade490cb6       28df10594cd92      26 hours ago       Running          kube-apiserver ...
```
  L'ID du conteneur correspond à la valeur de la première colonne.
2. Arrêtez chaque conteneur :
```
sudo crictl stop CONTAINER_ID
```
  Remplacez CONTAINER_ID par l'ID du conteneur de l'étape précédente.
  
  Lorsque le conteneur arrêté se ferme, kubelet en crée un nouveau à sa place et supprime celui qui est 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

Les certificats kubeadm doivent maintenant être renouvelés sur tous les nœuds du plan de contrôle. Si vous renouvelez des certificats expirés, 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 du 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 correctement renouvelés, aucune erreur TLS ni de certificat n'est renvoyée.

Mettre à jour le secret kubeconfig dans le cluster

Les étapes suivantes utilisent les certificats renouvelés du fichier admin.conf pour mettre à jour le secret kubeconfig de votre cluster. Toutefois, le contenu du fichier admin.conf mis à jour ne peut pas être utilisé tel quel. Vous devez d'abord créer une copie du fichier admin.conf et y apporter les modifications nécessaires.

Pour mettre à jour le nouveau fichier kubeconfig afin d'intégrer le secret, procédez comme suit sur un nœud du plan de contrôle :

Utilisez sed pour remplacer kubernetes dans le fichier admin.conf par le nom de votre cluster et écrivez les modifications dans un nouveau fichier, kubeconfig_secret.conf :
```
sed "s/kubernetes/CLUSTER_NAME/g" \
    /etc/kubernetes/admin.conf > /etc/kubernetes/kubeconfig_secret.conf
```

Utilisez diff pour vérifier que le fichier kubeconfig_secret.conf a été mis à jour :

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

La réponse indique tous les endroits où le fichier kubeconfig_secret.conf est différent du fichier admin.conf mis à jour. Par exemple, si vous avez effectué l'étape précédente pour un cluster nommé demo-cluster, le résultat ressemblerait à ce qui suit :

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

Exécutez les commandes suivantes pour mettre à jour le secret kubeconfig dans votre 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 -

Remplacer le fichier kubeconfig du cluster

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

Copiez le fichier admin.conf depuis l'un des nœuds du plan de contrôle du cluster vers le poste de travail administrateur.

Comme indiqué dans les sections précédentes, le fichier admin.conf se trouve dans le répertoire etc/kubernetes sur les nœuds du plan de contrôle du cluster.
Pour créer le fichier kubeconfig, exécutez la commande kubectl suivante sur le poste de travail administrateur :
```
kubectl --kubeconfig ADMIN_CONF_PATH get secret/CLUSTER_NAME-kubeconfig  \
    -n "CLUSTER_NAMESPACE" -o jsonpath='{.data.value}'  | \
    base64 --decode > new_kubeconfig.conf
```
Remplacez les éléments suivants :
- ADMIN_CONF_PATH : chemin d'accès au fichier admin.conf qui a été copié sur le poste de travail administrateur à partir d'un nœud de plan de contrôle.
- 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 n'importe quelle 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 la station 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 du plan de contrôle :

Connectez-vous au nœud de plan de contrôle et vérifiez le délai d'expiration du client kubelet et du certificat de service 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 la période d'expiration des certificats des composants de plan de contrôle. Par conséquent, il est probable que les certificats kubelet aient déjà été renouvelés :
```
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 de ces commandes ressemble à l'exemple suivant :
```
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 et doit être redémarré pour récupérer les certificats mis à jour.
```
kubectl rollout restart daemonset etcd-defrag -n kube-system --kubeconfig KUBECONFIG_PATH
```

Une fois que vous avez effectué ces étapes manuelles 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.

Étapes suivantes

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care. Vous pouvez également consulter Obtenir de l'aide pour en savoir plus sur les ressources d'assistance, y compris en ce qui concerne les thématiques suivantes :

Conditions requises pour ouvrir une demande d'assistance
Outils pour vous aider à résoudre les problèmes liés à la configuration de votre environnement, les journaux et les métriques
Composants acceptés