Ce document explique comment renouveler manuellement les certificats expirés pour votre cloud distribué Google. Les certificats Transport Layer Security (TLS) sont utilisés par les composants du plan de contrôle de Google Distributed Cloud. Lorsque ces certificats expirent, votre capacité à gérer les charges de travail et les cycles de vie des clusters est bloquée jusqu'à ce que les certificats puissent être renouvelés. Pour en savoir plus sur l'impact des certificats expirés, consultez la section 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 technique sous-jacente, et qui répondent aux alertes et aux pages lorsque les objectifs de niveau de service (SLO) ne sont pas atteints ou que les applications échouent. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud, consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.
Par défaut, les certificats TLS ont une période d'expiration d'un an. Google Distributed Cloud renouvelle automatiquement ces certificats lors des mises à niveau du cluster et lorsque vous effectuez une rotation des autorités de certification. Nous vous recommandons de mettre à niveau régulièrement vos clusters afin de garantir leur sécurité et leur compatibilité, et d'éviter l'expiration des certificats TLS.
Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.Erreurs provoqué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:
Impossible de se connecter au serveur : x509
Lorsque vous utilisez
kubectlpour obtenir les nœuds de votre cluster, la réponse inclut une erreur indiquant que vos certificats ont expiré, semblable à l'exemple de sortie suivant :Unable to connect to the server: x509: certificate has expired or is not yet validImpossible 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 telles que les 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
Pour vérifier les délais d'expiration des certificats, procédez comme suit sur chaque nœud du plan de contrôle:
Connectez-vous à l'une des machines du nœud du plan de contrôle et exécutez la commande suivante:
sudo kubeadm certs check-expirationLa sortie de la commande liste les certificats créés par
kubeadmpour les composants du plan de contrôle et leur date d'expiration, comme illustré dans l'exemple de sortie 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 noExé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 -A2La réponse de 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 GMTSi tous les nœuds du plan de contrôle ont été amorcés en même temps, les délais d'expiration du certificat sont compris à quelques minutes l'un de l'autre. Cette relation de planification 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 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 -A2La réponse est semblable à ceci:
Validity Not Before: Sep 17 22:27:53 2021 GMT Not After : Sep 17 22:33:16 2022 GMTExécutez la commande suivante pour rechercher la date d'expiration du certificat pour le fichier kubeconfig du cluster 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 -A2La réponse est semblable à ceci:
Validity Not Before: Sep 17 22:27:53 2021 GMT Not After : Sep 17 22:33:16 2022 GMTLe certificat kubeconfig du cluster d'administrateur et celui du fichier kubeconfig sur la station de travail administrateur sont identiques. Par conséquent, la sortie de cette commande et celle 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
Procédez comme suit sur chaque nœud du plan de contrôle du cluster concerné:
Sauvegardez le dossier
/etc/kubernetes.Exécutez la commande
kubeadmsuivante pour renouveler tous les certificats. La commande renouvelle les certificats en utilisant les autorités de certification existantes sur la machine:sudo kubeadm certs renew allLe 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 renewedVérifiez que les certificats ont un nouveau délai d'expiration en exécutant la commande suivante:
sudo kubeadm certs check-expirationLes composants du plan de contrôle ne sont pas tous compatibles avec l'actualisation dynamique des certificats. Pour récupérer les certificats renouvelés, procédez comme suit pour redémarrer les conteneurs suivants:
kube-apiserver,kube-scheduler,kube-controller-manageretetcd.Répétez les étapes suivantes pour chacun des quatre conteneurs:
Recherchez l'ID de chaque conteneur:
sudo crictl ps | grep CONTAINER_NAMERemplacez
CONTAINER_NAMEpar le nom des conteneurs suivants:kube-apiserver,kube-scheduler,kube-controller-managerouetcd(et nonetcd-defrag).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.
Arrêtez chaque conteneur:
sudo crictl stop CONTAINER_IDRemplacez CONTAINER_ID par l'ID de conteneur de l'étape précédente.
Lorsque le conteneur arrêté se ferme, kubelet crée un nouveau conteneur à la place et supprime celui arrêté. Si vous rencontrez une erreur, telle que
context deadline exceeded(code d'erreurDeadlineExceeded), réexécutez la commande.
Vérifier que la connectivité est restaurée
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 avec le serveur d'API Kubernetes, exécutez la commande
kubectlsuivante 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 ou 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
kubectlsuivante 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.confRemplacez 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.confcontient 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.confRemplacez le contenu de l'ancien fichier kubeconfig enregistré dans le répertoire de cluster du 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 du plan de contrôle :
Connectez-vous au nœud du plan de contrôle et vérifiez le délai d'expiration du client kubelet et du certificat de diffusion en exécutant les commandes suivantes:
Les certificats Kubelet sont automatiquement alternés 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 du 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 -A2Le 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 GMTExécutez la commande suivante pour redémarrer le conteneur
etcd-defrag:Le conteneur
etcd-defragutilise le certificat clientapiserver-etcdpour 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 ces étapes manuelles effectuées pour renouveler les certificats de cluster, vérifiez que tous les pods fonctionnent correctement et qu'aucune erreur TLS n'est signalée pour les conteneurs du plan de contrôle.