Ciclo de vida e etapas dos upgrades de cluster

Quando você faz upgrade do GKE em Bare Metal, 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. Neste documento, detalhamos os componentes e as etapas de um upgrade de cluster.

Visão geral

O processo de upgrade move o cluster do GKE em Bare Metal da versão atual para uma versão mais recente.

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 com spec.anthosBareMetalVersion para que ambos mostrem a versão de destino.

Versão skew

O desvio de versão é a diferença nas versões entre um cluster de administrador e os clusters de usuário gerenciados. Os clusters do GKE em Bare Metal seguem o mesmo estilo do Kubernetes: o cluster de administrador pode estar no máximo uma versão secundária à frente dos clusters gerenciados.

Upgrades de 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.16.8 de bmctl, poderá fazer upgrade de um cluster apenas para a versão 1.16.8.

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.16.X para a versão 1.16.Y, desde que Y seja maior que X. Por exemplo, é possível fazer upgrade de 1.15.0 para 1.15.1, bem como de 1.15.1 para 1.15.3. 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, é possível fazer upgrade de 1.15.3 para 1.16.8.

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.14.0 para a versão 1.16.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.

Os exemplos nas instruções de upgrade a seguir mostram o processo de upgrade da versão 1.15.2 para o GKE em Bare Metal 1.16.8.

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:

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

  • A distorção máxima entre a versão do cluster e a do pool de nós de trabalho é uma versão secundária.

  • Os pools de nós de trabalho não podem estar em uma versão lançada mais tarde que a versão do cluster.

    Por exemplo, com um cluster na versão 1.15.4, que não estava disponível quando a versão 1.16.0 foi lançada, não é possível fazer upgrade para a versão 1.16.0 e sair de um pool de nós de trabalho na versão 1.15.4. Da mesma forma, se você fez upgrade para a versão 1.16.0, mas optou por deixar um pool de nós de trabalho na versão 1.15.2, não poderá fazer upgrade desse pool posteriormente para a versão 1.15.4.

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:

Versão do cluster (plano de controle) Versões compatíveis do pool de nós de trabalho
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 GKE em Bare Metal podem levar à 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.

Orçamentos de interrupção de pod (PDBs)

Os orçamentos de interrupção de pod (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 a uma carga de trabalho quando os pods precisam ser reprogramados. No entanto, o GKE em Bare Metal faz jus a PDBs quando os nós são drenados durante um upgrade. Em vez disso, o processo de drenagem de nós é o melhor esforço. Alguns pods podem ficar travados no estado Terminating e se recusarem a desocupar o nó. O upgrade prossegue, mesmo com pods travados, quando o processo de drenagem em um nó leva mais de 20 minutos.

A seguir