Esta página se ha traducido con Cloud Translation API.

Renovar manualmente los certificados de clúster caducados

En este documento se describe cómo renovar manualmente los certificados caducados de Google Distributed Cloud. Los componentes del plano de control de Google Distributed Cloud usan certificados de Seguridad en la capa de transporte (TLS). Cuando estos certificados caduquen, no podrás gestionar las cargas de trabajo ni los ciclos de vida de los clústeres hasta que se renueven. Para obtener más información sobre las consecuencias de que caduquen los certificados, consulta Vencimiento de certificados.

Esta página está dirigida a administradores, arquitectos y operadores que gestionan el ciclo de vida de la infraestructura tecnológica subyacente y responden a alertas y páginas cuando no se cumplen los objetivos de nivel de servicio (SLOs) o las aplicaciones fallan. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas de usuario habituales de GKE. Google Cloud

De forma predeterminada, los certificados TLS, incluidos los certificados etcd, tienen un periodo de validez de un año. Google Distributed Cloud renueva estos certificados durante las actualizaciones del clúster y cuando rota las autoridades de certificación. Estos certificados no se actualizan periódicamente por sí solos. Te recomendamos que actualices tus clústeres con regularidad para que sigan siendo seguros y compatibles, y para evitar que caduquen los certificados TLS.

Errores causados por el vencimiento del certificado

Si los certificados TLS de tu clúster caducan, los controladores principales no podrán establecer conexiones TLS con el servidor de la API de Kubernetes. Esta falta de conectividad provoca 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 han caducado, como en el siguiente ejemplo:
```
Unable to connect to the server: x509: certificate has expired or is not yet valid
```
No se ha podido conectar: x509 o Conexión rechazada

Los certificados caducados bloquean el acceso al clúster de etcd, ya que los peers 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 "")
```

Consultar los tiempos de caducidad de los certificados

Para comprobar las horas de vencimiento de los certificados, sigue estos pasos en cada nodo del plano de control:

Inicia sesión en una de las máquinas de nodos 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 fecha de vencimiento, tal como se muestra en el siguiente 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 comprobar las horas 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 de cada comando es similar a la siguiente:
```
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 han inicializado al mismo tiempo, los tiempos de vencimiento de los certificados serán muy similares. Esta relación de tiempos se aplica a todos los nodos del plano de control. Para verificar las horas de vencimiento, ejecuta los comandos anteriores en cada nodo del plano de control.

Ejecuta el siguiente comando en la estación de trabajo del administrador para comprobar la hora 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 tiene este aspecto:

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 la fecha de vencimiento del certificado del archivo 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
```
Haz los cambios siguientes:
- ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.
- CLUSTER_NAME: el nombre del clúster para el que vas a renovar los certificados.
- CLUSTER_NAMESPACE: el espacio de nombres del clúster para el que vas a renovar los certificados.
La respuesta tiene este aspecto:
```
Validity
    Not Before: Sep 17 22:27:53 2021 GMT
    Not After : Sep 17 22:33:16 2022 GMT
```
El certificado kubeconfig del clúster de administrador y el certificado del archivo kubeconfig de la estación de trabajo de administrador son los mismos. Por lo tanto, la salida de este comando y la del comando del paso anterior deben coincidir.

Renovar certificados manualmente

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

Renovar los certificados en cada nodo del plano de control

Sigue estos 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 de certificación (ACs) que ya hay en el equipo:

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

Verifica que los certificados tengan una nueva fecha de vencimiento ejecutando el siguiente comando:
```
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, siga estos pasos para reiniciar los siguientes contenedores: kube-apiserver, etcd, kube-scheduler y kube-controller-manager.

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

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

Verificar que se ha restaurado la conectividad

Ahora, los certificados de kubeadm deberían renovarse en todos los nodos del plano de control. Si vas a renovar certificados caducados, 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 debe devolver la lista de nodos del clúster. Si tus certificados se renuevan correctamente, no se devolverá ningún error de TLS ni de certificado.

Actualizar el secreto kubeconfig en el clúster

En los pasos siguientes se usan los certificados renovados del archivo admin.conf para actualizar el secreto kubeconfig de tu clúster. Sin embargo, el contenido del archivo admin.conf actualizado no se puede usar tal cual. Primero, debes hacer una copia del archivo admin.conf y hacer algunos cambios.

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

Usa sed para sustituir 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 el archivo kubeconfig_secret.conf se ha actualizado:

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

La respuesta muestra todos los lugares en los que el archivo kubeconfig_secret.conf es diferente del archivo admin.conf actualizado. Por ejemplo, si has realizado el paso anterior en 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 secreto 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 -

Sustituir el archivo kubeconfig del clúster

Para sustituir 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 ha indicado en 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 nuevo archivo kubeconfig, 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
```
Haz los cambios siguientes:
- ADMIN_CONF_PATH: la ruta del archivo admin.conf que se ha copiado en la estación de trabajo del administrador desde un nodo del plano de control.
- CLUSTER_NAME: el nombre del clúster para el que vas a renovar los certificados.
- CLUSTER_NAMESPACE: el espacio de nombres del clúster para el que vas a renovar los certificados.
El archivo new_kubeconfig.conf contiene los datos del certificado actualizado.
Verifica que el nuevo archivo kubeconfig funciona ejecutando cualquier comando kubectl con las nuevas credenciales:
```
kubectl get nodes --kubeconfig new_kubeconfig.conf
```
Sustituye el contenido del archivo kubeconfig antiguo guardado en el directorio del clúster de la estación de trabajo del administrador por el contenido del nuevo archivo kubeconfig 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`

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

Inicia sesión en el nodo del plano de control y verifica la hora de vencimiento del cliente kubelet y del certificado de servicio ejecutando los siguientes comandos:

Los certificados de Kubelet se rotan automáticamente siempre que se pueda acceder al plano de control. El periodo de renovación automática de los certificados de kubelet es inferior al periodo de validez 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
```
La salida de cualquiera de los comandos es similar 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 cliente apiserver-etcd para comunicarse con etcd y debe reiniciarse para 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, comprueba que todos los pods se estén ejecutando correctamente y que no se hayan notificado errores de TLS en los contenedores del plano de control.

Siguientes pasos

Si necesitas más ayuda, ponte en contacto con el servicio de atención al cliente de Cloud. También puedes consultar la sección 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 admitidos.