Quando atualiza o Google Distributed Cloud, o processo de atualização envolve vários passos e componentes. Para ajudar a monitorizar o estado da atualização ou diagnosticar e resolver problemas, é útil saber o que acontece quando executa o comando bmctl upgrade
cluster
. Este documento detalha os componentes e as fases de uma atualização do cluster.
Vista geral
O processo de atualização move o cluster do Google Distributed Cloud da versão atual para uma versão superior.
Estas informações de versão são armazenadas nas seguintes localizações como parte do recurso personalizado do cluster no cluster de administração:
status.anthosBareMetalVersion
: define a versão atual do cluster.spec.anthosBareMetalVersion
: define a versão de destino e é definida quando o processo de atualização começa a ser executado.
Uma operação de atualização bem-sucedida reconcilia status.anthosBareMetalVersion
com spec.anthosBareMetalVersion
para que ambos mostrem a versão de destino.
Diferença de versão do cluster
A variação da versão do cluster é a diferença entre as versões de um cluster de gestão (híbrido ou de administrador) e os respetivos clusters de utilizadores geridos. Quando adiciona ou atualiza um cluster de utilizadores, aplicam-se as seguintes regras de versão:
1.30 e posteriores
As seguintes regras aplicam-se aos clusters de utilizadores geridos por um cluster de administrador ou um cluster híbrido da versão 1.30 ou posterior:
As versões dos clusters de utilizadores não podem ser superiores à versão do cluster de gestão (administrador ou híbrido).
Os clusters de utilizadores podem ter até duas versões secundárias abaixo da versão do cluster de gestão. Por exemplo, um cluster de administrador da versão 1.30 pode gerir um cluster de utilizadores da versão 1.28. Esta capacidade de gestão de desvios de versão n-2 está disponível para todos para gerir clusters na versão 1.30.
Para um determinado cluster de gestão na versão 1.30 ou posterior, os clusters de utilizadores não têm de ter a mesma versão secundária entre si. Por exemplo, um cluster de administrador da versão 1.30 pode gerir clusters de utilizadores da versão 1.30, da versão 1.29 e da versão 1.28.
A capacidade de gestão de vários desvios dá-lhe mais flexibilidade para planear as atualizações da sua frota. Por exemplo, não tem de atualizar todos os clusters de utilizadores da versão 1.28 para a versão 1.29 antes de poder atualizar o cluster de administrador para a versão 1.30.
1,29
As seguintes regras aplicam-se aos clusters de utilizadores geridos por um cluster de administrador ou um cluster híbrido da versão 1.29:
As versões dos clusters de utilizadores não podem ser superiores à versão do cluster de gestão (administrador ou híbrido).
(1.29 Pré-visualização) Os clusters de utilizadores podem ter até duas versões secundárias abaixo da versão do cluster de gestão. Por exemplo, um cluster de administrador da versão 1.29 pode gerir um cluster de utilizador da versão 1.16. Esta gestão da diferença de versões n-2 está disponível como uma capacidade de pré-visualização para gerir clusters na versão 1.29.
(1.29 Pré-visualização) Para um determinado cluster de gestão, os clusters de utilizadores não têm de ter a mesma versão secundária entre si. Por exemplo, um cluster de administrador da versão 1.29 pode gerir clusters de utilizadores da versão 1.29, da versão 1.28 e da versão 1.16. Esta gestão de desvios de versões mistas está disponível como uma capacidade de pré-visualização para gerir clusters na versão 1.29.
A capacidade de pré-visualização da gestão de vários produtos dá-lhe mais flexibilidade para planear as atualizações da sua frota. Por exemplo, não tem de atualizar todos os clusters de utilizadores da versão 1.16 para a versão 1.28 antes de poder atualizar o cluster de administrador para a versão 1.29.
1.28 e anterior
As seguintes regras aplicam-se aos clusters de utilizadores geridos por um cluster de administrador ou um cluster híbrido da versão 1.28 ou anterior:
As versões dos clusters de utilizadores não podem ser superiores à versão do cluster de gestão (administrador ou híbrido).
Os clusters de utilizadores podem estar até uma versão secundária abaixo da versão do cluster de gestão. Por exemplo, um cluster de administrador da versão 1.28 não pode gerir um cluster de utilizador na versão 1.15.
Para um determinado cluster de gestão, todos os clusters de utilizadores geridos têm de estar na mesma versão secundária.
Para obter informações sobre as regras de desvio de versão para pools de nós, consulte o artigo Regras de controlo de versões de pools de nós.
Regras de versões
Quando transfere e instala uma nova versão do bmctl
, pode atualizar os clusters de administrador, híbridos, autónomos e de utilizador criados ou atualizados com uma versão anterior do bmctl
. Não é possível alterar os clusters para uma versão inferior.
Só pode atualizar um cluster para uma versão que corresponda à versão do bmctl
que está a usar. Ou seja, se estiver a usar a versão 1.33.0-gke.799 do bmctl
, só pode atualizar um cluster para a versão 1.33.0-gke.799.
Atualizações da versão de patch
Para uma determinada versão secundária, pode atualizar para qualquer versão de patch superior. Isto é, pode atualizar um cluster de versões 1.33.X
para a versão 1.33.Y
, desde que Y
seja superior a X
. Por exemplo, pode atualizar do
1.32.0
para o 1.32.100
e do
1.32.100
para o 1.32.300
. Recomendamos que atualize
para a versão de patch mais recente sempre que possível para garantir que os seus clusters têm as
correções de segurança mais recentes.
Atualizações de versões secundárias
Pode atualizar clusters de uma versão secundária para a seguinte, independentemente da versão de patch. Ou seja, pode atualizar de 1.N.X
para 1.N+1.Y
, em que 1.N.X
é a versão do cluster e N+1
é a próxima versão secundária disponível. As versões de patch, X
e
Y
, não afetam a lógica de atualização neste caso. Por exemplo, pode atualizar do 1.32.400-gke.68
para o 1.33.0-gke.799
.
Não pode ignorar versões secundárias quando atualiza clusters. Se tentar atualizar
para uma versão secundária que seja duas ou mais versões secundárias superior à versão atual
do cluster, o bmctl
emite um erro. Por exemplo, não pode atualizar um cluster da versão 1.31.0
para a versão 1.33.0
num único passo.
Conforme descrito anteriormente, um cluster de administrador pode gerir clusters de utilizadores que estejam na mesma versão ou numa versão inferior. A diferença nas versões entre os clusters de utilizadores e o respetivo cluster de gestão (por vezes, denominada desvio de versão) varia consoante a versão do cluster. Antes de atualizar um cluster de gestão para uma nova versão secundária, certifique-se de que as versões dos clusters de utilizadores geridos permanecem em conformidade com as regras de variação da versão do cluster para a versão de atualização de destino.
Regras de controlo de versões de node pools
Quando atualiza node pools seletivamente, aplicam-se as seguintes regras de versão:
1.30 e posteriores
A versão do cluster tem de ser superior ou igual à versão do conjunto de nós de trabalho.
A diferença máxima entre a versão de um conjunto de nós de trabalho e a versão do cluster é de duas versões secundárias.
Os conjuntos de nós de trabalho podem estar em qualquer versão de patch de uma versão secundária compatível.
1,29
A versão do cluster tem de ser superior ou igual à versão do conjunto de nós de trabalho.
(1.29 GA) A diferença máxima de versão entre um conjunto de nós de trabalho e o cluster é de duas versões secundárias.
Os conjuntos de nós de trabalho não podem estar numa versão lançada cronologicamente mais tarde do que a versão do cluster. O lançamento anterior não tem os detalhes abrangentes para o lançamento posterior, o que é um requisito para a compatibilidade.
Por exemplo, a versão 1.16.6 foi lançada depois da versão 1.28.100-gke.146. Por isso, não pode atualizar o cluster da versão 1.16.6 para a versão 1.28.100-gke.146 e deixar um conjunto de nós de trabalho na versão 1.16.6. Da mesma forma, se atualizar o cluster para a versão 1.28.100-gke.146, mas optar por deixar um conjunto de nós de trabalho na versão 1.16.5, não pode atualizar o conjunto de nós de trabalho para a versão 1.16.6 enquanto o cluster estiver na versão 1.28.100-gke.146.
1,28
A versão do cluster tem de ser superior ou igual à versão do conjunto de nós de trabalho.
(1.28 Pré-visualização) A diferença máxima entre a versão de um conjunto de nós de trabalho e o cluster é de duas versões secundárias quando a diferença entre a versão n-2 está ativada. Se não ativar esta capacidade, a diferença máxima de versão entre um conjunto de nós de trabalho e o cluster é de uma versão secundária.
Os conjuntos de nós de trabalho não podem estar numa versão lançada cronologicamente mais tarde do que a versão do cluster. O lançamento anterior não tem os detalhes abrangentes para o lançamento posterior, o que é um requisito para a compatibilidade.
Por exemplo, a versão 1.16.6 foi lançada depois da versão 1.28.100-gke.146. Por isso, não pode atualizar o cluster da versão 1.16.6 para a versão 1.28.100-gke.146 e deixar um conjunto de nós de trabalho na versão 1.16.6. Da mesma forma, se atualizar o cluster para a versão 1.28.100-gke.146, mas optar por deixar um conjunto de nós de trabalho na versão 1.16.5, não pode atualizar o conjunto de nós de trabalho para a versão 1.16.6 enquanto o cluster estiver na versão 1.28.100-gke.146.
1.16
A versão do cluster tem de ser superior ou igual à versão do conjunto de nós de trabalho.
A diferença máxima entre a versão de um conjunto de nós de trabalho e a versão do cluster é de uma versão secundária.
Os conjuntos de nós de trabalho não podem estar numa versão lançada cronologicamente mais tarde do que a versão do cluster. O lançamento anterior não tem os detalhes abrangentes para o lançamento posterior, o que é um requisito para a compatibilidade.
Por exemplo, a versão 1.16.6 foi lançada depois da versão 1.28.100-gke.146. Por isso, não pode atualizar o cluster da versão 1.16.6 para a versão 1.28.100-gke.146 e deixar um conjunto de nós de trabalho na versão 1.16.6. Da mesma forma, se atualizar o cluster para a versão 1.28.100-gke.146, mas optar por deixar um conjunto de nós de trabalho na versão 1.16.5, não pode atualizar o conjunto de nós de trabalho para a versão 1.16.6 enquanto o cluster estiver na versão 1.28.100-gke.146.
A tabela seguinte indica as versões do conjunto de nós suportadas permitidas para uma versão específica do cluster:
1.30 e posteriores
Para as versões 1.30 e posteriores do cluster, as versões do conjunto de nós podem ser até duas versões secundárias inferiores. Todas as versões de patch do conjunto de nós nas versões secundárias compatíveis são compatíveis.
1,29
Versão do cluster (plano de controlo) | Versões do conjunto de nós de trabalho suportadas (versões adicionadas a negrito) | |||
---|---|---|---|---|
1.29.1200-gke.98 |
|
|
|
|
1.29.1100-gke.84 |
|
|
|
|
1.29.1000-gke.93 |
|
|
|
|
1.29.900-gke.180 |
|
|
|
|
1.29.800-gke.111 |
|
|
|
|
1.29.700-gke.113 |
|
|
|
|
1.29.600-gke.105 |
|
|
|
|
1.29.500-gke.162 |
|
|
|
|
1.29.400-gke.86 |
|
|
|
|
1.29.300-gke.185 |
|
|
|
|
1.29.200-gke.243 |
|
|
|
|
1.29.100-gke.251 |
|
|
|
|
1.29.0-gke.1449 |
|
|
|
1,28
Versão do cluster (plano de controlo) | Versões do conjunto de nós de trabalho suportadas (versões adicionadas a negrito) | |||
---|---|---|---|---|
1.28.1400-gke.79 |
|
|
|
|
1.28.1300-gke.59 |
|
|
|
|
1.28.1200-gke.83 |
|
|
|
|
1.28.1100-gke.94 |
|
|
|
|
1.28.1000-gke.60 |
|
|
|
|
1.28.900-gke.112 |
|
|
|
|
1.28.800-gke.111 |
|
|
|
|
1.28.700-gke.150 |
|
|
|
|
1.28.600-gke.163 |
|
|
|
|
1.28.500-gke.120 |
|
|
|
|
1.28.400-gke.77 |
|
|
|
|
1.28.300-gke.131 |
|
|
|
|
1.28.200-gke.118 |
|
|
|
|
1.28.100-gke.146 |
|
|
|
|
1.28.0-gke.425 |
|
|
|
|
1.16
Versão do cluster (plano de controlo) | Versões do conjunto de nós de trabalho suportadas (versões adicionadas a negrito) | |||
---|---|---|---|---|
1.16.12 |
|
|
|
|
1.16.11 |
|
|
|
|
1.16.10 |
|
|
|
|
1.16.9 |
|
|
|
|
1.16.8 |
|
|
|
|
1.16.7 |
|
|
|
|
1.16.6 |
|
|
|
|
1.16.5 |
|
|
|
|
1.16.4 |
|
|
|
|
1.16.3 |
|
|
|
|
1.16.2 |
|
|
|
|
1.16.1 |
|
|
||
1.16.0 |
|
|
Atualize componentes
Os componentes são atualizados ao nível do nó e do cluster. Ao nível do cluster, os seguintes componentes são atualizados:
- Componentes de cluster para redes, observabilidade e armazenamento.
- Para clusters de administrador, híbridos e autónomos, os controladores do ciclo de vida.
- O
gke-connect-agent
.
Os nós num cluster são executados como uma das seguintes funções, com diferentes componentes atualizados consoante a função do nó:
Função do nó | Função | Componentes a atualizar |
---|---|---|
Worker | Executa cargas de trabalho do utilizador | Kubelet, tempo de execução do contentor (Docker ou containerd) |
Plano de controlo | Executa o painel de controlo do Kubernetes, os controladores do ciclo de vida do cluster e os Google Cloud suplementos da plataforma | Pods estáticos do plano de controlo do Kubernetes (kubeapi-server ,
kube-scheduler , kube-controller-manager , etcd)
Controladores do ciclo de vida, como lifecycle-controllers-manager e
anthos-cluster-operator Suplementos da plataforma Google Cloud , como stackdriver-log-aggregator e
gke-connect-agent |
Balanceador de carga do plano de controlo | Executa o HAProxy e o Keepalived que servem tráfego para
kube-apiserver e executa altifalantes MetalLB para reivindicar endereços IP
virtuais |
Pods estáticos do balanceador de carga do plano de controlo (HAProxy, Keepalived)
Altifalantes MetalLB |
Expetativa de período de descanso
A tabela seguinte detalha o tempo de inatividade esperado e o potencial impacto quando atualiza clusters. Esta tabela pressupõe que tem vários nós de cluster e um plano de controlo de HA. Se executar um cluster autónomo ou não tiver um plano de controlo de HA, conte com tempo de inatividade adicional. Salvo indicação em contrário, esta indisponibilidade aplica-se às atualizações de clusters de administrador e de utilizador:
Componentes | Expetativas de tempo de inatividade | Quando o período de descanso ocorre |
---|---|---|
Servidor da API do painel de controlo do Kubernetes (kube-apiserver ),
etcd e programador |
Sem inatividade | N/A |
Controladores do ciclo de vida e tarefa ansible-runner (apenas no cluster de administrador) |
Sem inatividade | N/A |
Plano de controlo do Kubernetes loadbalancer-haproxy e
keepalived |
Tempo de inatividade transitório (inferior a 1 a 2 minutos) quando o balanceador de carga redireciona o tráfego. | Início do processo de atualização. |
Observabilidade pipeline-stackdriver e
metrics-server |
O operador foi esgotado e atualizado. O tempo de inatividade deve ser inferior a 5 minutos.
Os DaemonSets continuam a funcionar sem período de descanso. |
Depois de os nós do plano de controlo terminarem a atualização. |
Interface de rede de contentores (CNI) | Sem tempo de inatividade para rotas de rede existentes. O DaemonSet foi implementado dois a dois sem tempo de inatividade. O operador está esgotado e atualizado. Tempo de inatividade inferior a 5 minutos. |
Depois de os nós do plano de controlo terminarem a atualização. |
MetalLB (apenas cluster de utilizadores) | O operador foi esgotado e atualizado. O tempo de inatividade é inferior a 5 minutos.
As experiências de serviço existentes têm um tempo de inatividade temporário (inferior a 1 minuto) quando o balanceador de carga redireciona o tráfego. |
Depois de os nós do plano de controlo terminarem a atualização. |
CoreDNS e redimensionador automático de DNS (apenas cluster de utilizador) | O CoreDNS tem várias réplicas com o escalador automático. Normalmente, não há período de descanso. | Depois de os nós do plano de controlo terminarem a atualização. |
Aprovisionador de volumes locais | Sem tempo de inatividade para volumes persistentes (PVs) aprovisionados existentes.
O operador pode ter 5 minutos de inatividade. |
Depois de os nós do plano de controlo terminarem a atualização. |
Istio / entrada | O operador do Istio é esgotado e atualizado. Cerca de 5 minutos de
indisponibilidade. As entradas configuradas existentes continuam a funcionar. |
Depois de os nós do plano de controlo terminarem a atualização. |
Outros operadores de sistemas | 5 minutos de inatividade quando está descarregado e atualizado. | Depois de os nós do plano de controlo terminarem a atualização. |
Cargas de trabalho do utilizador | Depende da configuração, por exemplo, se for altamente disponível. Reveja as suas implementações de cargas de trabalho para compreender o potencial impacto. |
Quando os nós de trabalho são atualizados. |
Detalhes da atualização do cluster de utilizadores
Esta secção detalha a ordem das atualizações de componentes e as informações de estado para uma atualização do cluster de utilizadores. A secção seguinte detalha os desvios deste fluxo para atualizações de clusters de administrador, híbridos ou autónomos.
O diagrama seguinte mostra o processo de verificação prévia para uma atualização de cluster de utilizadores:
O diagrama anterior detalha os passos que ocorrem durante uma atualização:
- O comando
bmctl upgrade cluster
cria um recurso personalizadoPreflightCheck
. - Esta verificação prévia executa verificações adicionais, como verificações de atualização do cluster, verificações de funcionamento da rede e verificações de funcionamento do nó.
- Os resultados destas verificações adicionais combinam-se para gerar relatórios sobre a capacidade de o cluster ser atualizado com êxito para a versão de destino.
Se as verificações de pré-produção forem bem-sucedidas e não existirem problemas de bloqueio, os componentes no cluster são atualizados por uma ordem específica, conforme mostrado no diagrama seguinte:
No diagrama anterior, os componentes são atualizados pela seguinte ordem:
- A atualização começa pela atualização do campo
spec.anthosBareMetalVersion
. - Os balanceadores de carga do plano de controlo são atualizados.
- O node pool do painel de controlo é atualizado.
- Em paralelo, o GKE Connect é atualizado, os suplementos do cluster são atualizados e o conjunto de nós do balanceador de carga é atualizado.
- Depois de atualizar com êxito o node pool do equilibrador de carga, os node pools de trabalhadores são atualizados.
Quando todos os componentes tiverem sido atualizados, são executadas verificações do estado do cluster.
As verificações de funcionamento continuam a ser executadas até que todas as verificações sejam aprovadas.
Quando todas as verificações de estado forem aprovadas, a atualização está concluída.
Cada componente tem o seu próprio campo de estado no recurso personalizado do cluster. Pode verificar o estado nestes campos para compreender o progresso da atualização:
Sequência | Nome do campo | Significado |
---|---|---|
1 | status.controlPlaneNodepoolStatus |
O estado é copiado do estado do conjunto de nós do plano de controlo. O campo inclui as versões dos nós dos node pools do plano de controlo |
2 | status.anthosBareMetalLifecycleControllersManifestsVersion
|
Versão do lifecycles-controllers-manager aplicada ao cluster. Este campo só está disponível para clusters de administrador, autónomos ou híbridos. |
2 | status.anthosBareMetalManifestsVersion |
Versão do cluster do manifesto aplicado mais recentemente. |
2 | status.controlPlaneLoadBalancerNodepoolStatus |
O estado é copiado do estado do conjunto de nós do balanceador de carga do plano de controlo. Este campo está vazio se não for especificado nenhum equilibrador de carga do plano de controlo separado em Cluster.Spec . |
3 | status.anthosBareMetalVersions |
Um mapa de versões agregado da versão para os números dos nós. |
4 | status.anthosBareMetalVersion |
Estado final da versão atualizada. |
Detalhes da atualização do cluster de administrador, híbrido e autónomo
A partir da bmctl
versão 1.15.0, o comportamento de atualização predefinido para clusters autogeridos (administrador, híbrido ou autónomo) é uma atualização no local.
Ou seja, quando atualiza um cluster para a versão 1.15.0 ou superior, a atualização usa controladores do ciclo de vida, em vez de um cluster de arranque, para gerir todo o processo de atualização. Esta alteração simplifica o processo e reduz os requisitos de recursos, o que torna as atualizações de clusters mais fiáveis e escaláveis.
Embora não seja recomendável usar um cluster de arranque para a atualização, a opção continua disponível. Para usar um cluster de arranque quando fizer a atualização, execute o comando
bmctl upgrade
com a flag --use-bootstrap=true
.
As fases da atualização são diferentes consoante o método que usa.
Atualizações no local
O processo de atualização no local predefinido para clusters autogeridos é semelhante ao
processo de atualização do cluster de utilizadores. No entanto, quando usa o processo de atualização no local, é implementada uma nova versão do preflightcheck-operator
antes de executar a verificação prévia do cluster e as verificações de funcionamento:
Tal como na atualização do cluster de utilizadores, o processo de atualização começa com a atualização do campo Cluster.spec.anthosBareMetalVersion
para a versão de destino. São executados dois passos adicionais antes de os componentes serem atualizados, conforme mostrado no diagrama seguinte: o lifecycle-controller-manager
atualiza-se para a versão de destino e, em seguida, implementa a versão de destino do anthos-cluster-operator
. Esta
anthos-cluster-operator
executa os passos restantes do processo de atualização:
Após o êxito, o anthos-cluster-operator
reconcilia a versão de destino de
spec.anthosBareMetalVersion
para status.anthosBareMetalVersion
.
Atualize com um cluster de arranque
O processo de atualização de um cluster de administrador, híbrido ou autónomo é semelhante ao de um cluster de utilizador abordado na secção anterior.
A principal diferença é que o comando bmctl upgrade cluster
inicia um processo
para criar um cluster de arranque. Este cluster de arranque é um cluster temporário que gere o cluster híbrido, de administrador ou autónomo durante uma atualização.
O processo de transferência da propriedade de gestão do cluster para o cluster de arranque chama-se pivô. O resto da atualização segue o mesmo processo que a atualização do cluster de utilizadores.
Durante o processo de atualização, os recursos no cluster de destino permanecem desatualizados. O progresso da atualização só se reflete nos recursos do cluster de arranque.
Se necessário, pode aceder ao cluster de arranque para ajudar a monitorizar e depurar o processo de atualização. Pode aceder ao cluster de arranque através de
bmctl-workspace/.kindkubeconfig
.
Para transferir novamente a propriedade de gestão do cluster após a conclusão da atualização, o cluster transfere os recursos do cluster de arranque para o cluster atualizado. Não existem passos manuais que execute para mudar o cluster durante o processo de atualização. O cluster de arranque é eliminado após a atualização do cluster ser bem-sucedida.
Drenagem de nós
As atualizações do cluster do Google Distributed Cloud podem levar a interrupções da aplicação à medida que os nós são esvaziados. Este processo de drenagem faz com que todos os pods que são executados num nó sejam encerrados e reiniciados nos nós restantes no cluster.
As implementações podem ser usadas para tolerar essa interrupção. Uma implementação pode especificar que devem ser executadas várias réplicas de uma aplicação ou um serviço. Uma aplicação com várias réplicas deve ter poucas ou nenhumas interrupções durante as atualizações.
PodDisruptionBudgets
(PDBs)
Quando atualiza um cluster, o Google Distributed Cloud usa o fluxo do modo de manutenção para esvaziar os nós.
A partir da versão 1.29, os nós são esvaziados com a API Eviction, que
respeita os PodDisruptionBudgets
(PDBs). Os PDBs podem ser usados para garantir que um número definido de réplicas é sempre executado no cluster em condições de execução normais.
Os PDBs permitem-lhe limitar a interrupção de uma carga de trabalho quando os respetivos pods precisam de ser reagendados. A drenagem de nós baseada em despejo está disponível como DG para a versão 1.29.
Nos lançamentos 1.28 e anteriores, o Google Distributed Cloud não respeita os PDBs quando os nós são esvaziados durante uma atualização. Em alternativa, o processo de esgotamento de nós é feito com base no melhor esforço. Alguns pods podem ficar presos num estado Terminating
e recusar-se a sair do nó. A atualização prossegue, mesmo com pods bloqueados, quando o processo de esgotamento num nó demora mais de 20 minutos.
Para mais informações, consulte o artigo Coloque os nós no modo de manutenção.
O que se segue?
- Reveja as práticas recomendadas para atualizações do Google Distributed Cloud
- Atualize o Google Distributed Cloud
- Resolva problemas de atualização de clusters