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 y encriptar conexiones entre los componentes del sistema en clústeres. La autoridad certificadora (CA) del clúster administra estos certificados y claves. Cuando ejecutas el comando bmctl
update credentials certificate-authorities rotate, Google Distributed Cloud realiza las siguientes acciones:
El comando crea y sube nuevas autoridades certificadoras (CA) de clúster para la AC del clúster, la AC de etcd y la AC del proxy principal al espacio de nombres del clúster de usuario en el clúster de administrador.
Los controladores del clúster de administrador reemplazan las autoridades certificadoras del clúster de usuario por las que se generaron hace poco.
Los controladores del clúster de administrador distribuyen los nuevos certificados de CA públicos y los pares de claves de certificado de hoja a los componentes del sistema del clúster de usuario.
El comando también actualiza el Secret stackdriver-prometheus-etcd-scrape,
que Google Distributed Cloud creó durante la creación del clúster.
Prometheus requiere este secreto para recopilar métricas de etcd.
Para mantener la comunicación segura del clúster, rota la CA del clúster de usuario de forma periódica y siempre que haya una posible violación de la seguridad.
Antes de comenzar
Antes de rotar la autoridad certificadora de tu clúster, planifica de acuerdo con las siguientes condiciones e impactos:
Asegúrate de que los clústeres de administrador y de usuario estén en la versión 1.9.0 o superior antes de comenzar la rotación de CA.
La rotación del CA es incremental, lo que permite que los componentes del sistema se comuniquen durante la rotación.
Una rotación de AC reinicia el servidor de la API, otros procesos del plano de control y cada nodo en el clúster varias veces. Cada etapa de una rotación de CA avanza de manera similar a una actualización de clúster. Si bien el clúster de usuario permanece operativo durante una rotación de AC, debes esperar que las cargas de trabajo se reinicien y se reprogramen.
Si tu clúster de usuario no tiene un plano de control de alta disponibilidad, puedes esperar períodos breves de tiempo de inactividad del plano de control durante la rotación de las AC.
No se permiten operaciones de administración de clústeres durante la rotación de la CA.
La duración de la rotación de la CA depende del tamaño de tu clúster. Por ejemplo, la rotación de la CA puede tardar alrededor de dos horas en completarse para un clúster con un plano de control y 50 nodos trabajadores.
Limitaciones
La capacidad de rotación de autoridades certificadoras tiene las siguientes limitaciones:
La rotación de la CA del clúster de usuario no actualiza los certificados que emite un administrador de forma manual, incluso si la CA del clúster firma los certificados. Actualiza y redistribuye los certificados emitidos de forma manual después de que se complete la rotación de la CA del clúster de usuario.
Una vez iniciada, no se puede pausar ni revertir la rotación de la CA.
Inicia una rotación de CA del clúster
De forma predeterminada, los certificados TLS tienen un período de vencimiento de 1 año.
Google Distributed Cloud renueva estos certificados cuando rotas las autoridades certificadoras. Google Distributed Cloud también renueva los certificados TLS durante las actualizaciones del clúster. Te recomendamos que actualices tus clústeres con regularidad para mantenerlos seguros y compatibles, y evitar que venzan los certificados TLS.
Usa el siguiente comando para iniciar el proceso de rotación de la CA:
CLUSTER_NAME: Es el nombre del clúster en el que deseas rotar las CA.
KUBECONFIG es la ruta al archivo kubeconfig del clúster de administrador. Para los clústeres autoadministrados, este archivo es el archivo kubeconfig del clúster.
El comando de bmctl se cierra después de que la CA se rota con éxito y se genera un archivo kubeconfig nuevo. La ruta estándar para el archivo kubeconfig es bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.
Soluciona problemas de rotación de CA de clústeres
El comando bmctl update credentials muestra el progreso de la rotación de la CA.
El archivo update-credentials.log asociado se guarda en el siguiente directorio con marca de tiempo:
[[["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-01 (UTC)"],[],[],null,["Google Distributed Cloud uses certificates and private keys to authenticate and encrypt\nconnections between system components in clusters. The cluster certificate\nauthority (CA) manages these certificates and keys. When you run the `bmctl\nupdate credentials certificate-authorities rotate` command,\nGoogle Distributed Cloud performs the following actions:\n\n- The command creates and uploads new cluster certificate authorities (CAs)\n for the cluster CA, the etcd CA, and the front-proxy CA to the user cluster\n namespace in the admin cluster.\n\n- The admin cluster controllers replace the user cluster certificate\n authorities with the newly generated ones.\n\n- The admin cluster controllers distribute the new public CA certificates and\n leaf certificate key pairs to user cluster system components.\n\n- The command also updates the `stackdriver-prometheus-etcd-scrape` Secret,\n which was created by Google Distributed Cloud during cluster creation.\n Prometheus requires this secret to collect etcd metrics.\n\nTo maintain secure cluster communication, rotate your user cluster CA\nperiodically and whenever there is a possible security breach.\n| **Important:** If your cluster certificates have expired, you must renew them manually to regain cluster operation. For more information and instructions, see [Renew expired cluster certificates manually](/kubernetes-engine/distributed-cloud/bare-metal/docs/troubleshooting/expired-certs).\n\nBefore you begin\n\nBefore you rotate your cluster's certificate authority, plan according to the\nfollowing conditions and impacts:\n\n- Ensure admin and user clusters are at version 1.9.0 or higher before\n starting the CA rotation.\n\n- CA rotation is incremental, allowing system components to communicate during\n the rotation.\n\n- A CA rotation restarts the API server, other control-plane processes, and\n each node in the cluster multiple times. Each stage of a CA rotation\n progresses similarly to a cluster upgrade. While the user cluster does\n remain operational during a CA rotation, you should expect that workloads\n will be restarted and rescheduled.\n\n- If your user cluster doesn't have a [high-availability control plane](/kubernetes-engine/distributed-cloud/bare-metal/docs/reference/cluster-config-ref#controlplane-nodepoolspec-nodes),\n expect brief periods of control-plane downtime during CA rotation.\n\n- Cluster management operations aren't allowed during CA rotation.\n\n- CA rotation duration depends on the size of your cluster. For example, CA\n rotation may take close to two hours to complete for a cluster with one\n control plane and 50 worker nodes.\n\nLimitations\n\nThe certificate authority rotation capability has the\nfollowing limitations:\n\n- CA rotation doesn't update certificates issued manually by an administrator,\n even if the cluster CA signs the certificates. Update and redistribute any\n manually issued certificates after user cluster CA rotation is complete.\n\n- Once started, CA rotation can't be paused or rolled back.\n\nStart a cluster CA rotation\n\nBy default, TLS certificates have a 1-year expiration period.\nGoogle Distributed Cloud renews these certificates when you rotate certificate\nauthorities. Google Distributed Cloud also renews the TLS certificates during\ncluster upgrades. We recommend that you upgrade your clusters regularly to keep\nthem secure, supported, and to prevent TLS certificates from expiring.\n\nUse the following command to start the CA rotation process: \n\n bmctl update credentials certificate-authorities rotate --cluster \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --kubeconfig \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of the cluster for which you want to rotate CAs.\n- \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e: the path to the admin cluster kubeconfig file. For self-managing clusters, this file is the cluster's kubeconfig file.\n\nThe `bmctl` command exits after the CA is rotated successfully and a new\nkubeconfig file is generated. The standard path for the kubeconfig file is\n`bmctl-workspace/`\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e`/`\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e`-kubeconfig`.\n\nTroubleshoot a cluster CA rotation\n\nThe `bmctl update credentials` command displays the progress of the CA rotation.\nThe associated `update-credentials.log` file is saved to the following\ntimestamped directory: \n\n bmctl-workspace/\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e/log/update-credentials-\u003cvar translate=\"no\"\u003eTIMESTAMP\u003c/var\u003e"]]
