Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Renueva los certificados del clúster vencidos de forma manual

La renovación manual de certificados te permite restablecer las operaciones del plano de control en Google Distributed Cloud cuando vencen los certificados de seguridad de la capa de transporte (TLS). No puedes administrar las cargas de trabajo ni los ciclos de vida de los clústeres hasta que renueves los certificados TLS vencidos. Para obtener más información sobre el impacto de los certificados vencidos, consulta Vencimiento del certificado.

Los certificados TLS, incluidos los certificados etcd, tienen un período de vencimiento predeterminado de 1 año y no se actualizan automáticamente. Para evitar que los certificados venzan y mantener tus clústeres seguros y compatibles, te recomendamos que actualices tus clústeres con regularidad. Google Distributed Cloud renueva estos certificados durante las actualizaciones del clúster y cuando rotas las autoridades certificadoras. Puedes usar esta guía para recuperar clústeres si los certificados vencen antes de una actualización. Para obtener detalles relacionados, consulta Roles y tareas comunes del usuario de GKE.

Errores causados por el vencimiento del certificado

Si los certificados TLS de 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 establecer una conexión con el servidor: x509

Cuando usas kubectl para obtener los nodos del clúster, la respuesta incluye un error que indica que tus certificados vencieron, similar al siguiente resultado de ejemplo:
```
Unable to connect to the server: x509: certificate has expired or is not yet valid
```
No se pudo establecer una conexión: 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 tiempos de vencimiento de los certificados

Para verificar los tiempos 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

En el resultado del comando, se enumeran los certificados que creó 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 tiempos de vencimiento de los certificados de 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 ve como el 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 inicializaron al mismo tiempo, los tiempos de vencimiento de los certificados se encuentran dentro de minutos entre sí. Esta relación de tiempo se aplica a todos los nodos del plano de control. Para verificar los tiempos de vencimiento, ejecuta los comandos anteriores en cada nodo del plano de control.

Ejecuta el siguiente comando en la estación de trabajo de administrador para verificar el tiempo 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 el siguiente resultado de ejemplo:

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 kubeconfig del clúster en el clúster de administrador:
```
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
```
Reemplaza lo siguiente:
- ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
- CLUSTER_NAME: es el nombre del clúster para el que renuevas los certificados.
- CLUSTER_NAMESPACE: Es el espacio de nombres del clúster para el que renuevas los certificados.
La respuesta se ve como el siguiente resultado de ejemplo:
```
Validity
    Not Before: Sep 17 22:27:53 2021 GMT
    Not After : Sep 17 22:33:16 2022 GMT
```
El certificado de 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.

Cómo renovar certificados de forma manual

Para renovar de forma manual los certificados TLS de un clúster, sigue las instrucciones de las siguientes secciones.

Renueva los certificados en 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 kubeadm para renovar todos los certificados. El comando renueva los certificados con 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 un hora de vencimiento nuevo:
```
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, en los siguientes pasos se reinician los siguientes contenedores: kube-apiserver, kube-scheduler y kube-controller-manager.

Repite los siguientes pasos para cada uno de los cuatro contenedores:

Nota: Si tus certificados vencieron, te recomendamos que primero realices el siguiente paso para el contenedor kube-apiserver. Luego, detén los contenedores kube-scheduler y kube-controller-manager.
1. Busca el ID de cada contenedor:
```
sudo crictl ps | grep CONTAINER_NAME
```
  Reemplaza CONTAINER_NAME por el nombre de los siguientes contenedores: kube-apiserver, kube-scheduler o kube-controller-manager.
  
  La respuesta es similar al resultado a continuación:
```
c331ade490cb6       28df10594cd92      26 hours ago       Running          kube-apiserver ...
```
  El ID del contenedor es el valor de la primera columna.
2. Detén cada contenedor:
```
sudo crictl stop CONTAINER_ID
```
  Reemplaza CONTAINER_ID por el ID del contenedor del paso anterior.
  
  Cuando el contenedor detenido se cierra, kubelet crea un contenedor nuevo en su lugar y borra el detenido. Si encuentras un error, como context deadline exceeded (código de error DeadlineExceeded), vuelve a ejecutar el comando.

Verifica que se restablezca la conectividad

Los certificados de kubeadm ahora deberían estar renovados en todos los nodos del plano de control. Si renuevas certificados vencidos, sigue este paso:

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 tus certificados se renuevan de forma correcta, no se devuelven errores de TLS ni de certificados.

Actualiza el secreto de kubeconfig en el clúster

En los siguientes pasos, se usan los certificados renovados del archivo admin.conf para actualizar el secreto de kubeconfig de tu clúster. Sin embargo, el contenido del archivo admin.conf actualizado no se puede usar tal como está. Primero, debes hacer una copia del archivo admin.conf con algunas modificaciones necesarias.

Para actualizar el kubeconfig nuevo en el Secret, sigue estos pasos en un nodo del plano de control:

Usa sed para reemplazar kubernetes en el archivo admin.conf por el nombre de tu clúster y escribe los cambios en un archivo nuevo, kubeconfig_secret.conf:
```
sed "s/kubernetes/CLUSTER_NAME/g" \
    /etc/kubernetes/admin.conf > /etc/kubernetes/kubeconfig_secret.conf
```

Usa diff para confirmar que se actualizó el archivo kubeconfig_secret.conf:

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

En la respuesta, se muestran todos los lugares en los que el archivo kubeconfig_secret.conf es diferente del archivo admin.conf actualizado. Por ejemplo, si realizaste el paso anterior para un clúster llamado demo-cluster, el resultado sería similar al siguiente:

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

Ejecuta los siguientes comandos para actualizar el Secret de kubeconfig en tu clúster:

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 -

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:

Copia el archivo admin.conf de uno de los nodos del plano de control del clúster en la estación de trabajo de administrador.

Como se indicó en las secciones anteriores, el archivo admin.conf se encuentra en el directorio etc/kubernetes de los nodos del plano de control del clúster.
Para crear el archivo kubeconfig nuevo, ejecuta el siguiente comando kubectl en la estación de trabajo de administrador:
```
kubectl --kubeconfig ADMIN_CONF_PATH get secret/CLUSTER_NAME-kubeconfig  \
    -n "CLUSTER_NAMESPACE" -o jsonpath='{.data.value}'  | \
    base64 --decode > new_kubeconfig.conf
```
Reemplaza lo siguiente:
- ADMIN_CONF_PATH: Es la ruta de acceso del archivo admin.conf que se copió en la estación de trabajo de administrador desde un nodo del plano de control.
- CLUSTER_NAME: es el nombre del clúster para el que renuevas los certificados.
- CLUSTER_NAMESPACE: Es el espacio de nombres del clúster para el que renuevas 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 nuevo archivo kubeconfig new-kubeconfig.conf.

De forma predeterminada, la ruta de acceso 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`

Para finalizar el proceso de renovación manual de los certificados del clúster, sigue estos pasos para cada nodo del plano de control:

Accede al nodo del plano de control y verifica el cliente de kubelet y hora de vencimiento del certificado de entrega ejecutando los siguientes comandos:

Los certificados de Kubelet se rotan automáticamente siempre que se pueda acceder al plano de control. El período de renovación automática de los certificados de kubelet es más corto que el período de vencimiento de los certificados de los 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 ve como en el 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 de etcd-defrag:

El contenedor etcd-defrag usa el certificado de cliente apiserver-etcd para comunicarse con etcd y se debe reiniciar para que se apliquen 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 correctamente y que no se informen errores de TLS para los contenedores del plano de control.

¿Qué sigue?

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud. También puedes consultar Cómo obtener asistencia para obtener más información sobre los recursos de asistencia, incluidos los siguientes:

Requisitos para abrir un caso de asistencia.
Herramientas para ayudarte a solucionar problemas, como la configuración de tu entorno, los registros y las métricas.
Componentes compatibles.