Ciclo de vida e etapas dos upgrades de cluster

Quando você faz upgrade do Google Distributed Cloud, o processo de upgrade envolve várias etapas e componentes. Para ajudar a monitorar o status do upgrade ou diagnosticar e resolver problemas, é útil saber o que acontece quando você executa o comando bmctl upgrade cluster. Este documento detalha os componentes e estágios de um upgrade de cluster.

Visão geral

O processo de upgrade move o cluster do Google Distributed Cloud da versão atual para uma versão superior.

Essas informações da versão são armazenadas nos seguintes locais como parte do recurso personalizado do cluster no cluster de administrador:

  • status.anthosBareMetalVersion: define a versão atual do cluster.

  • spec.anthosBareMetalVersion: define a versão de destino e é definido quando o processo de upgrade começa a ser executado.

Uma operação de upgrade bem-sucedida reconcilia status.anthosBareMetalVersion como spec.anthosBareMetalVersion para que ambos mostrem a versão de destino.

Desvio da versão do cluster

O desvio da versão do cluster é a diferença nas versões entre um cluster de gerenciamento (híbrido ou de administrador) e os clusters de usuário gerenciados dele. Quando você adiciona ou faz upgrade de um cluster de usuário, as seguintes regras de versão são aplicadas:

1.29

As regras a seguir se aplicam aos clusters de usuário gerenciados por um cluster de administrador da versão 1.29 ou um cluster híbrido:

  • As versões do cluster de usuário não podem ser superiores à versão do cluster de gerenciamento (admin ou híbrido).

  • (1.29 Prévia) Os clusters de usuário podem ter até duas versões secundárias abaixo da versão do cluster de gerenciamento. Por exemplo, um cluster de administrador da versão 1.29 pode gerenciar um cluster de usuário 1.16. O gerenciamento de distorção da versão n-2 está disponível como um recurso Pré-lançamento para gerenciar clusters na versão 1.29.

  • (Pré-lançamento 1.29) Para um determinado cluster de gerenciamento, os clusters de usuário não precisam ter a mesma versão secundária entre si. Por exemplo, um cluster de administrador da versão 1.29 pode gerenciar os clusters de usuário das versões 1.29, 1.28 e 1.16. Esse gerenciamento de distorção de versão está disponível como um recurso de pré-lançamento para gerenciamento de clusters na versão 1.29.

    O recurso de gerenciamento de vários desvios Pré-lançamento oferece mais flexibilidade para planejar os upgrades da frota. Por exemplo, não é necessário fazer upgrade de todos os clusters de usuário da versão 1.16 para a versão 1.28 antes de fazer upgrade do cluster de administrador para a versão 1.29.

1.28 e anteriores

As regras a seguir se aplicam aos clusters de usuário gerenciados por uma versão 1.28, um cluster de administrador anterior ou um cluster híbrido:

  • As versões do cluster de usuário não podem ser superiores à versão do cluster de gerenciamento (admin ou híbrido).

  • Os clusters de usuário podem ter até uma versão secundária abaixo da versão do cluster de gerenciamento. Por exemplo, um cluster de administrador da versão 1.28 não pode gerenciar um cluster de usuário na versão 1.15.

  • Para um determinado cluster de gerenciamento, todos os clusters de usuário gerenciados precisam estar na mesma versão secundária.

Para informações sobre as regras de distorção de versão para pools de nós, consulte Regras de controle de versão do pool de nós.

Regras de versão

Ao fazer o download e instalar uma nova versão de bmctl, será possível fazer upgrade dos clusters de administrador, híbridos, independentes e de usuário criados ou atualizados com uma versão anterior de bmctl. Não é possível fazer downgrade dos clusters para uma versão anterior.

Só é possível fazer upgrade de um cluster para uma versão que corresponda à de bmctl que você está usando. Ou seja, se você estiver usando a versão 1.29.100-gke.251 de bmctl, poderá fazer upgrade de um cluster apenas para a versão 1.29.100-gke.251.

Upgrades de versão de patchs

Para uma determinada versão secundária, é possível fazer upgrade para qualquer versão de patch superior. Ou seja, é possível fazer upgrade de um cluster de versão 1.29.X para a versão 1.29.Y, desde que Y seja maior que X. Por exemplo, é possível fazer upgrade de 1.28.0 para 1.28.100, bem como de 1.28.100 para 1.28.300. Recomendamos que você faça o upgrade para a versão de patch mais recente sempre que possível para garantir que os clusters tenham as correções de segurança mais recentes.

Upgrades de versão secundária

É possível fazer upgrade de clusters de uma versão secundária para a próxima, independentemente da versão do patch. Ou seja, é possível fazer upgrade de 1.N.X para 1.N+1.Y, em que 1.N.X é a versão do seu 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 upgrade neste caso. Por exemplo, você pode fazer upgrade de 1.28.500-gke.120 para 1.29.100-gke.251.

Não é possível pular versões secundárias ao fazer upgrade de clusters. Se você tentar fazer upgrade para uma versão secundária que seja duas ou mais versões secundárias mais recentes que a versão do cluster, bmctl emitirá um erro. Por exemplo, não é possível fazer upgrade de um cluster da versão 1.16.0 para a versão 1.29.0.

Um cluster de administrador pode gerenciar clusters de usuário que estão em uma versão secundária igual ou anterior. Os clusters de usuário gerenciados não podem ser mais que uma versão secundária anterior ao cluster de administrador. Portanto, antes de fazer upgrade de um cluster de administrador para uma nova versão secundária, verifique se todos os clusters de usuário gerenciados estão na mesma versão secundária que o cluster de administrador.

Regras de controle de versões do pool de nós

Quando você faz upgrade de pools de nós seletivamente, as seguintes regras de versão se aplicam:

1.29

  • A versão do cluster precisa ser maior ou igual à versão do pool de nós de trabalho.

  • (1.29 GA) O desvio máximo de versão entre um pool de nós de trabalho e o cluster é de duas versões secundárias.

  • Os pools de nós de trabalho não podem estar em uma versão lançada cronologicamente posteriormente à versão do cluster. A versão anterior não tem os detalhes abrangentes da versão posterior, o que é um requisito para compatibilidade.

    Por exemplo, a versão 1.16.6 lançada após a versão 1.28.100-gke.146, não é possível fazer upgrade do cluster da versão 1.16.6 para a versão 1.28.100-gke.146 e sair de um pool de nós de trabalho na versão 1.16.6. Da mesma forma, se você fizer upgrade do cluster para a versão 1.28.100-gke.146, mas optar por deixar um pool de nós de trabalho na versão 1.16.5, não será possível fazer upgrade do pool 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 precisa ser maior ou igual à versão do pool de nós de trabalho.

  • (1.28 Visualização) O desvio máximo de versão entre um pool de nós de trabalho e o cluster é duas versões secundárias quando o recurso de distorção de versão n-2 Visualização está ativado. Se você não ativar esse recurso, a distorção máxima da versão entre um pool de nós de trabalho e o cluster será uma versão secundária.

  • Os pools de nós de trabalho não podem estar em uma versão lançada cronologicamente posteriormente à versão do cluster. A versão anterior não tem os detalhes abrangentes da versão posterior, o que é um requisito para compatibilidade.

    Por exemplo, a versão 1.16.6 lançada após a versão 1.28.100-gke.146, não é possível fazer upgrade do cluster da versão 1.16.6 para a versão 1.28.100-gke.146 e sair de um pool de nós de trabalho na versão 1.16.6. Da mesma forma, se você fizer upgrade do cluster para a versão 1.28.100-gke.146, mas optar por deixar um pool de nós de trabalho na versão 1.16.5, não será possível fazer upgrade do pool 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 precisa ser maior ou igual à versão do pool de nós de trabalho.

  • O desvio máximo de versão entre um pool de nós de trabalho e o cluster é uma versão secundária.

  • Os pools de nós de trabalho não podem estar em uma versão lançada cronologicamente posteriormente à versão do cluster. A versão anterior não tem os detalhes abrangentes da versão posterior, o que é um requisito para compatibilidade.

    Por exemplo, a versão 1.16.6 lançada após a versão 1.28.100-gke.146, não é possível fazer upgrade do cluster da versão 1.16.6 para a versão 1.28.100-gke.146 e sair de um pool de nós de trabalho na versão 1.16.6. Da mesma forma, se você fizer upgrade do cluster para a versão 1.28.100-gke.146, mas optar por deixar um pool de nós de trabalho na versão 1.16.5, não será possível fazer upgrade do pool de nós de trabalho para a versão 1.16.6 enquanto o cluster estiver na versão 1.28.100-gke.146.

Na tabela a seguir, há uma lista das versões compatíveis do pool de nós que são permitidas em uma versão específica do cluster:

1.29

Versão do cluster (plano de controle) Versões compatíveis do pool de nós de trabalho
1.29.100-gke.251
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 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
1.29.0-gke.1449
  • 1.29.0-gke.1449
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0

1.28

Versão do cluster (plano de controle) Versões compatíveis do pool de nós de trabalho
1.28.500-gke.120
  • 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.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.400-gke.77
  • 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.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.300-gke.131
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.200-gke.118
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.100-gke.146
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.0-gke.425
  • 1.28.0-gke.425
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

     

     

     

1.16

Versão do cluster (plano de controle) Versões compatíveis do pool de nós de trabalho
1.16.9
  • 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
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.8
  • 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
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.7
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.6
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.5
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.4
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.3
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.2
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.1
  • 1.16.1
  • 1.16.0
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.0
  • 1.16.0
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

Fazer upgrade dos componentes

Os componentes são atualizados no nível do nó e do cluster. No nível do cluster, os seguintes componentes são atualizados:

  • Componentes de cluster para rede, observabilidade e armazenamento.
  • Para clusters de administrador, híbridos e autônomos, os controladores de ciclo de vida.
  • O gke-connect-agent.

Os nós em um cluster são executados com um dos seguintes papéis, com diferentes componentes atualizados dependendo do papel do nó:

Papel do nó Função Componentes para fazer upgrade
Worker Executa cargas de trabalho de usuários Kubelet, ambiente de execução do contêiner (Docker ou containerd)
Plano de controle Executa o plano de controle do Kubernetes, os controladores do ciclo de vida do cluster e os complementos da plataforma da edição Google Kubernetes Engine (GKE) Enterprise Pods estáticos do plano de controle do Kubernetes (kubeapi-server, kube-scheduler, kube-controller-manager etcd)

Controladores de ciclo de vida, como lifecycle-controllers-manager e anthos-cluster-operator

complementos da plataforma da edição Google Kubernetes Engine (GKE) Enterprise, como stackdriver-log-aggregator e gke-connect-agent
Balanceador de carga do plano de controle Executa HAProxy e Keepalived que veiculam tráfego para kube-apiserver e executa alto-falantes MetalLB para reivindicar endereços IP virtuais Pods estáticos do balanceador de carga do plano de controle (HAProxy, Keepalived)

Alto-falantes MetalLB

Expectativa de inatividade

Na tabela a seguir, detalhamos a inatividade esperada e o possível impacto ao fazer upgrade dos clusters. Nesta tabela, presumimos que você tenha vários nós de cluster e um plano de controle de alta disponibilidade. Se você executar um cluster autônomo ou não tiver um plano de controle de alta disponibilidade, espere mais inatividade. A menos que indicado, essa inatividade se aplica aos upgrades de cluster de administrador e usuário:

Componentes Expectativas de inatividade Quando ocorre inatividade
Servidor de API do plano de controle do Kubernetes (kube-apiserver), etcd e programador Sem inatividade N/A
Controladores de ciclo de vida e job ansible-runner (somente cluster de administrador) Sem inatividade N/A
Plano de controle do Kubernetes loadbalancer-haproxy e keepalived Inatividade temporária (menos de 1 a 2 minutos) quando o balanceador de carga redireciona o tráfego. Início do processo de upgrade.
Observabilidade pipeline-stackdriver e metrics-server Operador drenado e atualizado. O tempo de inatividade deve ser inferior a cinco minutos.

Os DaemonSets continuam funcionando sem inatividade.		 Depois que o upgrade dos nós do plano de controle for concluído.
Interface de rede de contêiner (CNI) Não há inatividade para as rotas de rede atuais.

O DaemonSet implantou dois por dois sem inatividade.

O operador é drenado e atualizado. Inatividade com menos de 5 minutos.		 Depois que o upgrade dos nós do plano de controle for concluído.
MetalLB (somente cluster de usuário) Operador drenado e atualizado. A inatividade é inferior a 5 minutos.

Sem inatividade para o serviço atual		 Depois que o upgrade dos nós do plano de controle for concluído.
CoreDNS e escalonador automático de DNS (somente cluster de usuário) O CoreDNS tem várias réplicas com o escalonador automático. Geralmente, não há inatividade. Depois que o upgrade dos nós do plano de controle for concluído.
Provisionador de volume local Sem inatividade para volumes permanentes provisionados (PVs).

O operador pode ter cinco minutos de inatividade.		 Depois que o upgrade dos nós do plano de controle for concluído.
Istio / entrada O operador do Istio foi drenado e atualizado. Cerca de cinco minutos de inatividade.

A entrada configurada atual continuará funcionando.		 Depois que o upgrade dos nós do plano de controle for concluído.
Outros operadores do sistema Inatividade de cinco minutos quando drenado e atualizado. Depois que o upgrade dos nós do plano de controle for concluído.
Cargas de trabalho de usuário Depende da configuração, como se for altamente disponível.

Revise suas implantações de carga de trabalho para entender o possível impacto.		 Quando os nós de trabalho são atualizados.

Detalhes do upgrade do cluster de usuário

Nesta seção, detalhamos a ordem dos upgrades de componentes e as informações de status para um upgrade de cluster de usuário. A seção a seguir detalha os desvios desse fluxo para upgrades de cluster de administrador, híbrido ou autônomo.

O diagrama a seguir mostra o processo de verificação de simulação para um upgrade de cluster de usuário:

A verificação de simulação do cluster executa verificações de integridade adicionais no cluster antes do início do processo de upgrade.

O diagrama anterior detalha as etapas que acontecem durante um upgrade:

  • O comando bmctl upgrade cluster cria um recurso personalizado PreflightCheck.
  • Essa verificação de simulação executa outras verificações, como verificações de upgrade de cluster, de integridade da rede e de nó.
  • Os resultados dessas verificações adicionais se combinam para informar a capacidade do cluster de fazer upgrade para a versão de destino.

Se as verificações de simulação forem bem-sucedidas e não houver problemas de bloqueio, os componentes no cluster serão atualizados em uma ordem especificada, como mostrado no diagrama a seguir:

Os balanceadores de carga e o pool de nós do plano de controle são atualizados. Em seguida, o GKE Connect, os complementos de cluster e os pools de nós de trabalho e de balanceador de carga são atualizados.

No diagrama anterior, os componentes são atualizados na ordem abaixo:

  1. O upgrade começa com a atualização do campo spec.anthosBareMetalVersion.
  2. Os balanceadores de carga do plano de controle são atualizados.
  3. O pool de nós do plano de controle é atualizado.
  4. Paralelamente, o GKE Connect é atualizado, os complementos do cluster e o pool de nós do balanceador de carga são atualizados.
    1. Depois que o pool de nós do balanceador de carga é atualizado, os pools de nós de trabalho são atualizados.

  5. Quando todos os componentes tiverem sido atualizados, as verificações de integridade do cluster serão executadas.

    As verificações de integridade continuam em execução até que todas sejam aprovadas.

  6. Quando todas as verificações de integridade forem aprovadas, o upgrade será concluído.

Cada componente tem o próprio campo de status no recurso personalizado de cluster. Verifique o status nestes campos para entender o progresso do upgrade:

Sequência Nome do campo Significado
1 status.controlPlaneNodepoolStatus O status é copiado do status do pool de nós do plano de controle. O campo inclui as versões dos nós dos pools de nós do plano de controle.
2 status.anthosBareMetalLifecycleControllersManifestsVersion Versão de lifecycles-controllers-manager aplicada ao cluster. Esse campo está disponível apenas para clusters de administrador, autônomos ou híbridos.
2 status.anthosBareMetalManifestsVersion Versão do cluster do último manifesto aplicado.
2 status.controlPlaneLoadBalancerNodepoolStatus O status é copiado do status do pool de nós do balanceador de carga do plano de controle. Este campo ficará vazio se nenhum balanceador de carga do plano de controle separado for especificado em Cluster.Spec.
3 status.anthosBareMetalVersions Um mapa de versão agregada da versão para números de nó.
4 status.anthosBareMetalVersion Status final da versão atualizada.

Detalhes do upgrade de cluster de administrador, híbrido e autônomo

A partir da versão 1.15.0 do bmctl, o comportamento de upgrade padrão para clusters autogerenciados (de administradores, híbridos ou independentes) é um upgrade no local. Ou seja, quando você faz o upgrade de um cluster para a versão 1.15.0 ou mais recente, o upgrade usa controladores de ciclo de vida, em vez de um cluster de inicialização, para gerenciar todo o processo de upgrade. Essa alteração simplifica o processo e reduz os requisitos de recursos, o que torna os upgrades de cluster mais confiáveis e escalonáveis.

Ainda que o uso de um cluster de inicialização para upgrade não seja recomendado, a opção ainda está disponível. Para usar um cluster de inicialização ao fazer upgrade, execute o comando bmctl upgrade com a sinalização --use-bootstrap=true. Os estágios do upgrade são diferentes, dependendo do método usado.

Upgrades no local

O processo de upgrade padrão para clusters autogerenciados no local é semelhante ao processo de upgrade do cluster de usuário. No entanto, ao usar o processo de upgrade no local, uma nova versão do preflightcheck-operator é implantada antes da verificação de simulação do cluster e das verificações de integridade:

Uma nova versão do operador de verificação de simulação é implantada antes da verificação de simulação do cluster executar verificações de integridade adicionais no cluster.

Assim como o upgrade do cluster de usuário, o processo de upgrade começa atualizando o campo Cluster.spec.anthosBareMetalVersion para a versão de destino. Mais duas etapas são executadas antes que os componentes sejam atualizados, conforme mostrado no diagrama a seguir: o lifecycle-controller-manager faz upgrade para a versão de destino e, em seguida, implanta a versão de destino de anthos-cluster-operator. Esse anthos-cluster-operator executa as etapas restantes do processo de upgrade:

O lifecycle-controller-manager e o anthos-cluster-operator-cluster são implantados antes do upgrade do restante do cluster na mesma ordem dos componentes no cluster de usuário.

Após a conclusão, o anthos-cluster-operator reconcilia a versão de destino de spec.anthosBareMetalVersion para status.anthosBareMetalVersion.

Fazer upgrade com um cluster de inicialização

O processo de upgrade de um cluster de administrador, híbrido ou autônomo é semelhante a um cluster de usuário discutido na seção anterior.

A principal diferença é que o comando bmctl upgrade cluster inicia um processo para criar um cluster de inicialização. Esse cluster de inicialização é um cluster temporário que gerencia o cluster híbrido, de administrador ou autônomo durante um upgrade.

O processo para transferir a propriedade de gerenciamento do cluster para o cluster de inicialização é chamado de tabela dinâmica. O restante do upgrade segue o mesmo processo que o upgrade do cluster de usuário.

Durante o processo de upgrade, os recursos no cluster de destino permanecem desatualizados. O progresso do upgrade só é refletido nos recursos do cluster de inicialização.

Se necessário, é possível acessar o cluster de inicialização para ajudar a monitorar e depurar o processo de upgrade. O cluster de inicialização pode ser acessado usando bmctl-workspace/.kindkubeconfig.

Para transferir a propriedade de gerenciamento do cluster novamente após a conclusão do upgrade, o cluster dinamiza os recursos do cluster de inicialização para o cluster atualizado. Não há etapas manuais para dinamizar o cluster durante o processo de upgrade. O cluster de inicialização é excluído após o upgrade do cluster.

Drenagem de nós

Os upgrades de cluster do Google Distributed Cloud podem causar a interrupção do aplicativo à medida que os nós são drenados. Esse processo faz com que todos os pods executados em um nó sejam encerrados e reiniciados nos nós restantes no cluster.

As implantações podem ser usadas para tolerar essa interrupção. Uma implantação pode especificar várias réplicas de um aplicativo ou serviço que precisa ser executado. Um aplicativo com várias réplicas precisa sofrer pouca ou nenhuma interrupção durante os upgrades.

PodDisruptionBudgets (PDBs)

Quando você faz upgrade de um cluster, o Google Distributed Cloud usa o fluxo do modo de manutenção para drenar os nós.

A partir da versão 1.29, os nós são drenados com a API Eviction, que respeita a PodDisruptionBudgets (PDBs). Os PDBs podem ser usados para garantir que um número definido de réplicas seja sempre executado no cluster em condições normais de execução. Os PDBs permitem limitar a interrupção de uma carga de trabalho quando os pods dela precisam ser reprogramados. A drenagem de nós baseada em remoção está disponível como GA na versão 1.29.

Nas versões 1.28 e anteriores, o Google Distributed Cloud não respeita PDBs quando os nós drenam durante um upgrade. Em vez disso, o processo de drenagem de nós é o melhor esforço. Alguns pods podem ficar travados em um estado Terminating e se recusar a liberar o nó. O upgrade continua, mesmo com pods travados, quando o processo de drenagem em um nó leva mais de 20 minutos.

Para mais informações, consulte Colocar nós no modo de manutenção.

A seguir