En este documento, se describe cómo renovar de forma manual los certificados vencidos de Google Distributed Cloud. Los componentes del plano de control de Google Distributed Cloud usan certificados de seguridad de la capa de transporte (TLS). Cuando estos certificados vencen, se bloquea tu capacidad para administrar las cargas de trabajo y los ciclos de vida de los clústeres hasta que se puedan renovar los certificados. Para obtener más información sobre el impacto de los certificados vencidos, consulta Vencimiento de certificados.
De forma predeterminada, los certificados TLS tienen un período de vencimiento de 1 año. Google Distributed Cloud renueva estos certificados automáticamente durante las actualizaciones de los clústeres y cuando rotas las autoridades certificadoras. Te recomendamos que actualices los clústeres con regularidad para mantenerlos seguros y compatibles, y para evitar que los certificados TLS venzan.
Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.Errores causados por el vencimiento del certificado
Si los certificados TLS en tu clúster vencen, los controladores principales no podrán establecer conexiones TLS con el servidor de la API de Kubernetes. Esta falta de conectividad causa los siguientes errores:
No se puede conectar al servidor: x509
Cuando usas
kubectl
para obtener los nodos del clúster, la respuesta incluye un error que indica que tus certificados caducaron, similar al siguiente resultado de ejemplo:Unable to connect to the server: x509: certificate has expired or is not yet valid
no se pudo conectar: x509 o conexión rechazada
Los certificados vencidos bloquean el acceso al clúster de etcd, ya que los pares no pueden comunicarse entre sí. Los registros de etcd pueden contener entradas de error como las siguientes:
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 "")
Verifica los plazos de vencimiento de los certificados
Para verificar los plazos de vencimiento de los certificados, realiza los siguientes pasos en cada nodo del plano de control:
Accede a una de las máquinas de nodo del plano de control y ejecuta el siguiente comando:
sudo kubeadm certs check-expiration
El resultado del comando muestra los certificados creados por
kubeadm
para los componentes del plano de control y su vencimiento, como se muestra en el siguiente resultado de ejemplo: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
Ejecuta el siguiente comando para verificar los plazos de vencimiento de los certificados
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 respuesta para cada comando se parece al siguiente resultado de ejemplo:
Validity Not Before: Sep 17 22:27:53 2021 GMT Not After : Sep 17 22:33:16 2022 GMT
Si todos los nodos del plano de control se iniciaron al mismo tiempo, los tiempos de vencimiento de los certificados serán unos pocos minutos entre sí. Esta relación de tiempo se aplica en todos los nodos del plano de control. Puedes verificar las horas de vencimiento ejecutando los comandos anteriores en cada nodo del plano de control.
Ejecuta el siguiente comando en la estación de trabajo de administrador para verificar la fecha de vencimiento del certificado de cliente en el archivo kubeconfig del clúster:
grep 'client-certificate-data' KUBECONFIG_PATH | \ awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2
La respuesta se ve como este resultado de muestra:
Validity Not Before: Sep 17 22:27:53 2021 GMT Not After : Sep 17 22:33:16 2022 GMT
Ejecuta el siguiente comando para buscar el vencimiento del certificado del clúster kubeconfig en el clúster de administrador:
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
La respuesta se ve como este resultado de muestra:
Validity Not Before: Sep 17 22:27:53 2021 GMT Not After : Sep 17 22:33:16 2022 GMT
El certificado kubeconfig en el clúster de administrador y el certificado en el archivo kubeconfig en la estación de trabajo de administrador son los mismos. Por lo tanto, el resultado de este comando y el del paso anterior deben coincidir.
Renovar certificados de forma manual
Si quieres renovar de forma manual los certificados TLS de un clúster, usa las instrucciones de las siguientes secciones.
Renueva los certificados de cada nodo del plano de control
Realiza los siguientes pasos en cada nodo del plano de control del clúster afectado:
Crea una copia de seguridad de la carpeta
/etc/kubernetes
.Ejecuta el siguiente comando de
kubeadm
para renovar todos los certificados. El comando renueva los certificados mediante las autoridades certificadoras (AC) existentes en la máquina:sudo kubeadm certs renew all
El resultado del comando es similar al siguiente ejemplo.
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
Ejecuta el siguiente comando para verificar que los certificados tengan una nueva hora de vencimiento:
sudo kubeadm certs check-expiration
No todos los componentes del plano de control admiten la recarga dinámica de certificados. Para recoger los certificados renovados, sigue estos pasos y reinicia los siguientes contenedores:
kube-apiserver
,kube-scheduler
,kube-controller-manager
yetcd
.Repite los siguientes pasos para cada uno de los cuatro contenedores:
Busca el ID del contenedor de cada contenedor:
sudo crictl ps | grep CONTAINER_NAME
Reemplaza
CONTAINER_NAME
por el nombre de los siguientes contenedores:kube-apiserver
,kube-scheduler
,kube-controller-manager
oetcd
(noetcd-defrag
).La respuesta es similar al siguiente resultado:
c331ade490cb6 28df10594cd92 26 hours ago Running kube-apiserver ...
El ID del contenedor es el valor de la primera columna.
Detén cada contenedor:
sudo crictl stop CONTAINER_ID
Reemplaza CONTAINER_ID por el ID de contenedor del paso anterior.
Cuando se cierra el contenedor detenido, kubelet crea un contenedor nuevo en su lugar y borra el que se detuvo. Si encuentras un error, como
context deadline exceeded
(código de errorDeadlineExceeded
), vuelve a ejecutar el comando.
Verifica que se restablezca la conectividad
Los certificados de kubeadm ahora deberían renovarse en todos los nodos del plano de control. Si renuevas certificados vencidos, sigue estos pasos:
Para verificar la conexión con el servidor de la API de Kubernetes, ejecuta el siguiente comando
kubectl
en cualquier nodo del plano de control:kubectl get nodes --kubeconfig=/etc/kubernetes/admin.conf
La respuesta debería mostrar la lista de nodos del clúster. Si los certificados se renuevan de forma correcta, no se muestran errores de TLS o de certificados.
Reemplaza el archivo kubeconfig del clúster
Para reemplazar el archivo kubeconfig de tu clúster por uno que tenga los certificados renovados, sigue estos pasos:
Para crear el archivo kubeconfig nuevo, ejecuta el siguiente comando
kubectl
en la estación de trabajo de administrador:kubectl --kubeconfig="ADMIN_KUBECONFIG" get secret/CLUSTER_NAME-kubeconfig \ -n "CLUSTER_NAMESPACE" -o jsonpath='{.data.value}' | base64 --decode > new_kubeconfig.conf
Reemplaza lo siguiente:
ADMIN_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del clúster de administrador.
CLUSTER_NAME: Es el nombre del clúster para el que deseas renovar los certificados.
CLUSTER_NAMESPACE: Es el espacio de nombres del clúster para el que estás renovando los certificados.
El archivo
new_kubeconfig.conf
contiene los datos del certificado actualizados.Ejecuta cualquier comando
kubectl
con las credenciales nuevas para verificar que el kubeconfig nuevo funcione:kubectl get nodes --kubeconfig new_kubeconfig.conf
Reemplaza el contenido del archivo kubeconfig anterior guardado en el directorio del clúster en la estación de trabajo de administrador por el contenido del archivo kubeconfig nuevo
new-kubeconfig.conf
.De forma predeterminada, la ruta al archivo de configuración del clúster es
bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig
.
Verifica los certificados de kubelet y reinicia etcd-defrag
A fin de finalizar el proceso de renovación de certificados del clúster de forma manual, realiza los siguientes pasos para cada nodo del plano de control:
Accede al nodo del plano de control y verifica el cliente de kubelet y la hora de vencimiento del certificado de entrega mediante la ejecución de los siguientes comandos:
Los certificados de Kubelet se rotan de forma automática siempre que se pueda acceder al plano de control. El período de renovación automática de los certificados de kubelet es menor que el período de vencimiento de los certificados de componentes del plano de control. Por lo tanto, es probable que los certificados de kubelet se hayan renovado antes:
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
El resultado de cualquiera de los comandos se parece al siguiente ejemplo:
Validity Not Before: Nov 28 18:04:57 2022 GMT Not After : Nov 28 19:04:57 2023 GMT
Usa el siguiente comando para reiniciar el contenedor
etcd-defrag
:El contenedor
etcd-defrag
usa el certificado de clienteapiserver-etcd
para comunicarse con etcd y debe reiniciarse a fin de recoger los certificados actualizados.kubectl rollout restart daemonset etcd-defrag -n kube-system --kubeconfig KUBECONFIG_PATH
Después de completar estos pasos manuales para renovar los certificados del clúster, verifica que todos los Pods se ejecuten de forma correcta y que no se informen errores de TLS para los contenedores del plano de control.