Renueva los certificados de clúster vencidos de forma manual

En este documento, se describe cómo renovar de forma manual los certificados vencidos para tus clústeres de Anthos alojados en Bare Metal. Los componentes del plano de control de los clústeres de Anthos alojados en Bare Metal usan los certificados de seguridad de la capa de transporte (TLS). Cuando estos certificados vencen, la capacidad de administrar cargas de trabajo y ciclos de vida de clústeres se bloquea 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. Los clústeres de Anthos alojados en Bare Metal renuevan estos certificados de forma automática durante las actualizaciones del clúster y cuando rotas las autoridades certificadoras. Te recomendamos que actualices los clústeres con regularidad para mantenerlos seguros y admitidos, y para evitar que caduquen los certificados TLS.

Errores provocados por el vencimiento del certificado

Si los certificados TLS del clúster vencen, los controladores principales no pueden establecer conexiones TLS con el servidor de la API de Kubernetes. Esta falta de conectividad causa los siguientes errores:

  • Unable to connect to the server: x509: Unable to connect to the server

    Cuando usas kubectl para obtener los nodos del clúster, la respuesta incluye un error que hace referencia al vencimiento del certificado:

    kubectl get nodes --kubeconfig KUBECONFIG_PATH
    

    Reemplaza KUBECONFIG_PATH por la ruta de acceso al archivo kubeconfig del clúster.

    Cuando los certificados vencen, la respuesta es similar a la siguiente:

    Unable to connect to the server: x509: certificate has expired or is not yet valid
    
  • could not connect: x509 o rejected connection

    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 las fechas de vencimiento de los certificados

En esta sección, se incluyen instrucciones para verificar los plazos de vencimiento de los certificados que usa tu clúster. Realiza los siguientes pasos en cada nodo del plano de control.

Sigue estos pasos para verificar los plazos de vencimiento del certificado:

  1. 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 una lista de los certificados que creó kubeadm para los componentes del plano de control y su vencimiento:

    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
    
  2. 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 ve como el siguiente resultado:

    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 del certificado serán unos minutos entre sí. Esta relación de tiempo se aplica a todos los nodos del plano de control. Puedes verificar los tiempos de vencimiento si ejecutas los comandos anteriores en cada nodo del plano de control.

  3. Ejecuta el siguiente comando en la estación de trabajo de administrador para verificar 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 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
    
  4. 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 -o --kubeconfig=ADMIN_KUBECONFIG jsonpath='{.data.value}' | base64 --decode | grep client-certificate-data | awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2
    
    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 del archivo kubeconfig de la estación de trabajo de administrador son los mismos. Por lo tanto, el resultado de este comando y el comando del paso anterior deben coincidir.

Renovar certificados manualmente

A fin de renovar de forma manual los certificados TLS para 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:

  1. Crea una copia de seguridad de la carpeta /etc/kubernetes.

  2. Ejecuta el siguiente comando de kubeadm para renovar todos los certificados:

    El comando renueva los certificados con las autoridades certificadoras (CA) existentes de 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
    
  3. Ejecuta el siguiente comando para verificar que los certificados tengan una hora de vencimiento nueva:

    sudo kubeadm certs check-expiration
    
  4. Reinicia los contenedores con los siguientes comandos:

    No todos los componentes del plano de control admiten la recarga dinámica de certificados, por lo que este paso reinicia los siguientes contenedores: kube-apiserver, kube-scheduler, kube-controller-manager y etcd para recoger los certificados renovados.

    Repite los siguientes pasos para cada contenedor de cuatro:

    1. Busque el ID de contenedor para 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 o etcd (no etcd-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.

    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

En este punto, los certificados de kubeadm deben renovarse en todos los nodos del plano de control. Si vas a renovar certificados vencidos, realiza el siguiente paso.

  • Para verificar la conexión con el servidor de la API de Kubernetes, ejecuta el siguiente comando de kubectl en cualquier nodo del plano de control:

    kubectl get nodes --kubeconfig=/etc/kubernetes/admin.conf
    

La respuesta debe mostrar la lista de nodos del clúster. Si los certificados se renuevan de forma correcta, no se muestran TLS ni errores de certificado.

Reemplace el archivo kubeconfig del clúster

Para reemplazar el archivo kubeconfig por el clúster con uno que tenga los certificados renovados, sigue estos pasos:

  1. Para crear el archivo kubeconfig nuevo, ejecuta el siguiente comando de 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 renuevas los certificados.

    • CLUSTER_NAMESPACE: El espacio de nombres del clúster para el que renuevas los certificados.

    El archivo new_kubeconfig.conf contiene los datos del certificado actualizados.

  2. Ejecuta el comando kubectl con las credenciales nuevas para verificar que el kubeconfig nuevo funcione:

    kubectl get nodes --kubeconfig new_kubeconfig.conf
    
  3. 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 manual de los certificados de clúster, sigue estos pasos para cada nodo del plano de control:

  1. Accede al nodo del plano de control y ejecuta el siguiente comando para verificar el cliente de kubelet y la hora de vencimiento del certificado de entrega:

    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 certificados de kubelet es inferior al 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 verá como el siguiente ejemplo:

    Validity
        Not Before: Nov 28 18:04:57 2022 GMT
        Not After : Nov 28 19:04:57 2023 GMT
    
  2. 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 a fin de recoger los certificados actualizados.

    kubectl rollout restart daemonset etcd-defrag -n kube-system --kubeconfig KUBECONFIG_PATH
    

Completaste los pasos manuales para renovar certificados de 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.