Os clusters do Anthos em bare metal agora são o Google Distributed Cloud (somente software) em bare metal. Para mais informações, consulte a visão geral do produto.
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O Google Distributed Cloud usa certificados e chaves privadas para autenticar e criptografar
conexões entre componentes do sistema em clusters. A autoridade
certificadora (CA, na sigla em inglês) do cluster gerencia esses certificados e chaves. Quando você executa
o comando bmctl update credentials certificate-authorities rotate,
o Google Distributed Cloud realiza as seguintes ações:
Cria e faz upload de novas autoridades de certificação de cluster (CAs) para a
CA do cluster, a CA etcd e a CA do proxy frontal para o namespace do cluster
de usuário no cluster de administrador.
Os controladores do cluster de administrador substituem as autoridades de certificação do cluster de usuário pelas recém-geradas.
os controladores do cluster de administrador distribuem os novos certificados de CA públicos e
pares de chaves de certificado de folha para os componentes do sistema do cluster de usuário.
Para manter a comunicação segura no cluster, rotacione a CA do cluster de usuário
periodicamente e sempre que houver uma possível violação de segurança.
Antes de começar
Antes de fazer a rotação da autoridade de certificação do cluster, planeje-se de acordo com
as seguintes condições e impactos:
Verifique se os clusters de administrador e de usuário estão na versão 1.9.0 ou superior antes
de iniciar a rotação de CA.
A rotação da CA é incremental, permitindo que componentes do sistema se comuniquem durante a
rotação.
O processo de rotação de CA reinicia o servidor da API, os processos do plano de controle
e os pods no cluster de usuário.
Espere que as cargas de trabalho sejam reiniciadas e reprogramadas durante a rotação da CA.
Para configurações de cluster que não sejam de alta disponibilidade, espere breves períodos
de inatividade no plano de controle durante a rotação da CA.
As operações de gerenciamento de cluster não são permitidas durante a rotação da CA.
A duração da rotação de CA depende do tamanho do cluster. Por exemplo, a
rotação de CA pode levar quase duas horas para ser concluída para um cluster com um
plano de controle e 50 nós de trabalho.
Limitações
O recurso de rotação da autoridade de certificação tem as
seguintes limitações:
A rotação da CA não atualiza os certificados emitidos manualmente por um
administrador, mesmo se a CA do cluster assinar os certificados. Atualize e redistribua
quaisquer certificados emitidos manualmente após a conclusão da rotação da CA do cluster de usuário;
Depois de iniciada, a rotação de CA não pode ser pausada ou revertida.
Iniciar uma rotação da CA do cluster
Use este comando para iniciar o processo de rotação da CA:
CLUSTER_NAME: o nome do cluster em que você quer rotacionar as CAs.
KUBECONFIG: o caminho até o arquivo kubeconfig
do cluster de administrador. Para o gerenciamento automático de clusters, esse arquivo é o
kubeconfig do cluster.
O comando bmctl é encerrado depois que a CA do cluster é rotacionada com êxito e um novo
arquivo kubeconfig é gerado. O caminho padrão para o arquivo kubeconfig é
bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.
Resolver problemas com uma rotação de CA do cluster
O comando bmctl update credentials exibe o progresso da rotação da CA.
O arquivo update-credentials.log associado é salvo neste
diretório com carimbo de data/hora:
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-01-31 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"]]