Los clústeres de Anthos en VMware ahora son Google Distributed Cloud (solo software) para VMware. Para obtener más información, consulta la descripción general del producto.
Rota los certificados de CA del clúster de administrador
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Google Distributed Cloud usa certificados y claves privadas para autenticar la comunicación entre los componentes del sistema de Kubernetes en un clúster de administrador. Cuando creas un clúster de administrador, se crean nuevos certificados de autoridad certificadora (CA) y estos certificados raíz se usan a fin de emitir certificados de hoja adicionales para componentes del sistema de Kubernetes.
El sistema de Kubernetes usa tres certificados de CA en un clúster de administrador:
El certificado de CA de etcd protege la comunicación del servidor de la API de Kubernetes a las réplicas de etcd y también la comunicación entre réplicas de etcd. Este certificado está autofirmado.
El certificado de CA del clúster protege la comunicación entre el servidor de la API de Kubernetes y todos los clientes internos de la API de Kubernetes, por ejemplo, kubelet, el administrador del controlador y el programador. Este certificado está autofirmado.
El Certificado de CA de proxy principal protege la comunicación con las APIs agregadas.
Este certificado está autofirmado.
Puedes usar gkectl para activar una rotación de certificado. Durante una rotación, gkectl reemplaza los certificados de CA del sistema principal del clúster de administrador por los certificados recién generados. Luego, distribuye los nuevos certificados de CA, certificados de hoja y claves privadas a los componentes del sistema del clúster de administrador. La rotación ocurre de manera incremental, de modo que los componentes del sistema puedan seguir comunicándose durante la rotación. Sin embargo, ten en cuenta que las cargas de trabajo y los nodos se reinician durante la rotación.
Sin rotación, los certificados de la AC y del plano de control vencerán cinco años a partir de la fecha en que se creó el clúster. Los certificados del plano de control se rotan automáticamente durante una actualización de clúster, pero las AC no se rotan automáticamente. Esto significa que la rotación de una AC debe realizarse al menos una vez cada cinco años, además de las actualizaciones regulares de las versiones.
Limitaciones
Ten en cuenta la siguiente limitación con los clústeres avanzados:
Versión 1.31: La rotación de AC no es compatible con los clústeres avanzados.
Versión 1.32 y versiones posteriores: La rotación de AC es compatible con los clústeres avanzados, pero existen algunas diferencias menores que se indican en este documento cuando corresponda.
La rotación de certificados de CA está limitada a los certificados de etcd, clúster y proxy principal mencionados antes.
La rotación de certificados de AC se limita a los certificados emitidos automáticamente por Google Distributed Cloud. No actualiza los certificados que emite un administrador de forma manual, incluso si las CA del sistema firman esos certificados.
La rotación de certificados de CA reinicia varias veces el servidor de la API de Kubernetes, otros procesos del plano de control y cada nodo en el clúster de administrador.
Cada etapa de una rotación avanza de manera similar a una actualización de clúster. Si bien el clúster de administrador y los clústeres de usuario administrados por el clúster de administrador permanecen operativos durante una rotación de certificados, debes esperar que las cargas de trabajo en el clúster de administrador se reinicien y se reprogramen. También debes esperar períodos de inactividad breves para el plano de control del clúster de administrador y el plano de control del clúster de usuario.
Debes actualizar el archivo kubeconfig del clúster de administrador durante una rotación de certificados y, una vez más, después de que se complete la rotación. Esto se debe a que se revoca el certificado de clúster anterior y las credenciales en el archivo kubeconfig ya no funcionarán.
Una vez iniciada, no se puede revertir una rotación de certificados de CA.
Una rotación de certificados de CA puede tardar un tiempo considerable en completarse, según el tamaño del clúster.
Si se interrumpe, el proceso de rotación de certificados se puede reanudar volviendo a ejecutar el mismo comando. Sin embargo, debes asegurarte de que solo haya un comando de rotación en ejecución a la vez.
Inicia la rotación
Para iniciar la rotación de certificados, ejecuta el siguiente comando:
ADMIN_CLUSTER_CONFIG: la ruta de acceso del archivo de configuración de tu clúster de administrador
ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
El comportamiento del comando difiere según si el clúster avanzado está habilitado:
No habilitada
El comando gkectl update credentials certificate-authorities rotate inicia y realiza la primera mitad de la rotación. Luego, el comando se pausa para permitir que ejecutes el siguiente comando y actualices el archivo kubeconfig.
Actualiza el archivo kubeconfig
Cuando se pause el comando gkectl update credentials certificate-authorities rotate, actualiza el archivo kubeconfig del clúster de administrador. Esto coloca un nuevo certificado de cliente y un nuevo certificado de AC en el archivo kubeconfig. El certificado de cliente anterior se quita del archivo kubeconfig y el certificado de AC anterior permanece en el archivo kubeconfig.
Ejecuta el siguiente comando para realizar la segunda mitad del procedimiento. El comando no continuará hasta que gkectl verifique que el archivo kubeconfig actualizado está en el directorio actual.
Cuando se completa la rotación, se informa la versión actual de CA.
Vuelve a actualizar el archivo kubeconfig
Una vez que se complete la segunda mitad de la rotación, vuelve a actualizar el archivo kubeconfig. Esto quita el certificado de CA anterior del archivo kubeconfig.
Si el clúster avanzado está habilitado, el comando gkectl update credentials
certificate-authorities rotate es síncrono. El comando muestra mensajes de estado en la estación de trabajo del administrador a medida que avanza la rotación de la AC.
Después de que la AC se rota correctamente, el comando se cierra y se genera automáticamente un archivo kubeconfig nuevo. El archivo kubeconfig que especificaste en el comando se reemplaza por uno nuevo. El resultado del comando es similar al siguiente:
Beginning CA rotation with generated CA
...
Successfully rotated CA for admin cluster. The kubeconfig file
"/home/ubuntu/kubeconfig" has been updated.
Done rotating certificate-authorities
Distribuye el archivo kubeconfig nuevo
Distribuye el nuevo archivo kubeconfig del clúster de administrador a todos los usuarios del clúster.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[],[],null,["Google Distributed Cloud use certificates and private keys to authenticate\ncommunication between Kubernetes system components in an admin cluster. When you\ncreate an admin cluster, new certificate authority (CA) certificates are created,\nand these root certificates are used to issue additional leaf certificates for\nKubernetes system components.\n\nThis guide applies only to rotation of admin cluster CA certificates. For\nuser clusters, see\n[Rotating user cluster CA certificates](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/ca-rotation).\n\nThere are three CA certificates used by the Kubernetes system in an admin\ncluster:\n\n- The etcd CA certificate secures communication from the Kubernetes API server\n to the etcd replicas and also communication between etcd replicas. This\n certificate is self-signed.\n\n- The cluster CA certificate secures communication between the Kubernetes API\n server and all internal Kubernetes API clients, for example, the kubelet, the\n controller manager, and the scheduler. This certificate is self-signed.\n\n- The front-proxy CA certificate secures communication with\n [aggregated APIs](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).\n This certificate is self-signed.\n\nYou can use `gkectl` to trigger a certificate rotation. During a rotation,\n`gkectl` replaces the core system CA certificates for the\nadmin cluster with newly generated certificates. Then it distributes the new\nCA certificates, leaf certificates, and private keys to admin cluster system\ncomponents. The rotation happens incrementally, so that system components can\ncontinue to communicate during the rotation. Note, however, that workloads and\nnodes are restarted during the rotation.\n\nWithout rotation, CA certificates and control-plane certificates will expire\nfive years from the date the cluster was created. The control plane certificates\nare automatically rotated during a cluster upgrade, but the CAs are\nnot automatically rotated. This means a CA rotation must be performed at least\nonce every five years, in addition to regular version upgrades.\n| **Warning:** A CA certificate rotation revokes the old CA certificates at the end of the operation. This invalidates kubeconfig files that were based on an old certificate. Consequently, the credentials in the kubeconfig file stop working after a CA certificate rotation. This guide includes instructions on how to update your kubeconfig file. The same issue applies to authentication configuration files.\n\nLimitations\n\n- Note the following limitation with advanced clusters:\n\n - Version 1.31: CA rotation isn't supported on [advanced clusters](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/admin-cluster-configuration-file-latest#enable-advanced-cluster-field).\n - Version 1.32 and higher: CA rotation is supported on advanced clusters but there are some minor differences noted where applicable in this document.\n- CA certificate rotation limited to the etcd, cluster, and front-proxy\n certificates mentioned previously.\n\n- CA certificate rotation is limited to certificates issued automatically by\n Google Distributed Cloud. It does not update certificates issued manually by an\n administrator, even if those certificates are signed by the system CAs.\n\n- CA certificate rotation restarts the Kubernetes API server, other\n control-plane processes, and each node in the admin cluster multiple times.\n Each stage of a rotation progresses similarly to a cluster upgrade. While the\n admin cluster and the user clusters managed by the admin cluster do remain\n operational during a certificate rotation, you should expect that workloads\n in the admin cluster will be restarted and rescheduled. You should also expect\n brief periods of downtime for the admin cluster control plane and user cluster\n control plane.\n\n- You must update the admin cluster kubeconfig file in the middle of a\n certificate rotation and again after the rotation completes. This is because\n the old cluster certificate is revoked, and the credentials in the kubeconfig\n file will no longer work.\n\n- Once initiated, a CA certificate rotation cannot be rolled back.\n\n- A CA certificate rotation might take considerable time to complete, depending\n on the size of the cluster.\n\n- The certificate rotation process can be resumed by re-running the same\n command if it is interrupted. However, you must ensure that there is only one\n rotation command running at a time.\n\nStart the rotation\n\nTo start the certificate rotation, run the following command:\n\n```\ngkectl update credentials certificate-authorities rotate \\\n --admin-cluster \\\n --config ADMIN_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONFIG\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eADMIN_CLUSTER_CONFIG\u003c/var\u003e: the path of the admin cluster configuration\n file\n\n- \u003cvar translate=\"no\"\u003eADMIN_CLUSTER_KUBECONFIG\u003c/var\u003e: the path of the admin cluster kubeconfig\n file\n\nThe behavior of the command differs depending on whether advanced cluster\nis enabled: \n\nNot enabled\n\nThe `gkectl update credentials certificate-authorities rotate` command starts\nand performs the first half of the rotation. The command then pauses to let\nyou run the next command to update the kubeconfig file.\n\nUpdate the kubeconfig file\n\nWhen the `gkectl update credentials certificate-authorities rotate` command\npauses, update the kubeconfig file for the admin cluster. This places a new\nclient certificate and a new CA certificate in the kubeconfig file. The old\nclient certificate is removed from the kubeconfig file, and the old CA\ncertificate remains in the kubeconfig file.\n\n```\ngkectl update credentials certificate-authorities update-kubeconfig \\\n --admin-cluster \\\n --config ADMIN_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONFIG\n```\n\nContinue the rotation\n\nRun the following command to perform the second half of the procedure. The\ncommand doesn't proceed until `gkectl` verifies that the updated kubeconfig\nfile is in the current directory.\n\n```\ngkectl update credentials certificate-authorities rotate \\\n --admin-cluster \\\n --complete \\\n --config ADMIN_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONFIG\n```\n\nWhen the rotation is complete, it reports the current CA version.\n\nUpdate the kubeconfig file again\n\nAfter the second half of the rotation completes, update the kubeconfig file\nagain. This removes the old CA certificate from the kubeconfig file.\n\n```\ngkectl update credentials certificate-authorities update-kubeconfig \\\n --admin-cluster \\\n --config ADMIN_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONFIG\n```\n\nEnabled\n\nIf advanced cluster is enabled, the `gkectl update credentials\ncertificate-authorities rotate` command is synchronous. The command outputs\nstatus messages to the admin workstation as the CA rotation progresses.\n\nAfter the CA is rotated successfully, the command exits and a new kubeconfig\nfile is automatically generated. The kubeconfig file that you specified in the\ncommand is replaced with a new one. The command output is similar to the\nfollowing:\n\n```\nBeginning CA rotation with generated CA\n...\nSuccessfully rotated CA for admin cluster. The kubeconfig file\n\"/home/ubuntu/kubeconfig\" has been updated.\nDone rotating certificate-authorities\n```\n\nDistribute the new kubeconfig file\n\nDistribute the new admin cluster kubeconfig file to all cluster users."]]