Visão geral do upgrade

Nesta página, você encontra uma visão geral do processo de upgrade e informações de desvio da versão para planejar a ordem de upgrade dos clusters em um ambiente de vários clusters. Para informações de planejamento mais detalhadas, incluindo uma lista de verificação para ajudar você a planejar o upgrade, consulte Práticas recomendadas de upgrade.

Fazer upgrade da sequência

Os upgrades no local desde a versão 1.7 precisam sempre seguir uma sequência de upgrade específica:

1. Faça upgrade da estação de trabalho do administrador. Recomendamos que você faça isso mesmo que planeje usar o console do Google Cloud, a Google Cloud CLI ou o Terraform para fazer upgrade de clusters de usuários.

2. Upgrade de clusters de usuário, um de cada vez. Na versão 1.14 e mais recentes, é possível fazer upgrade do plano de controle de um cluster de usuário separadamente dos pools de nós no cluster de usuário. Para mais informações sobre por que fazer isso, consulte Upgrades de cluster de usuário.

   Depois que todos os pools de nós em um cluster de usuário estiverem na mesma versão que o plano de controle do cluster de usuário, esse cluster será completamente atualizado.

   Um cluster de administrador não pode estar em uma versão secundária posterior aos clusters de usuário que ele gerencia. Se algum dos clusters de usuário estiver na mesma versão secundária que o cluster de administrador, não será possível fazer upgrade dele.

3. Quando todos os clusters de usuário forem pelo menos uma versão secundária mais recente que o cluster de administrador, será possível fazer upgrade do cluster de administrador.

O desvio de versão e as regras de versão para upgrades mudaram na versão 1.28 e posteriores. Para mais informações, consulte Desvio de versão.

Upgrades de cluster de usuário

Ao fazer upgrade de clusters de usuário, é possível fazer upgrade do cluster de usuário como um todo, ou seja, fazer upgrade do plano de controle e de todos os pools de nós no cluster. Também é possível fazer upgrade do plano de controle do cluster de usuário e deixar os pools de nós na versão atual. A abordagem a ser adotada depende de vários fatores, como:

• O ambiente (de produção ou não produção) em que o cluster está.
• A duração da janela de manutenção.
• A versão do cluster de usuário.

Por exemplo, em um ambiente de desenvolvimento, convém manter o processo simples e fazer upgrade do plano de controle do cluster de usuário e de todos os pools de nós. Mas, em um ambiente de produção com uma janela de manutenção curta, convém fazer upgrade apenas do plano de controle, porque isso leva menos tempo e, com planos de controle de alta disponibilidade (HA, na sigla em inglês), o upgrade do plano de controle não deve interromper as cargas de trabalho do usuário. Quando o plano de controle estiver na versão 1.28 ou mais recente, será possível pular uma versão secundária ao fazer upgrade dos pools de nós.

O upgrade de pools de nós separadamente do plano de controle é compatível com os pools de nós do Ubuntu e do COS, mas não para os pools de nós do Windows.

Fazer upgrade dos pools de nós

Em determinadas situações, pode ser necessário fazer upgrade de alguns, mas não de todos os pools de nós em um cluster de usuário. Por exemplo, depois de fazer o upgrade do plano de controle, é possível fazer o upgrade de um pool de nós que tenha tráfego leve ou que execute as cargas de trabalho menos críticas. Depois de se convencer de que suas cargas de trabalho são executadas corretamente na nova versão, você poderá fazer upgrade de outros pools de nós até que todos os pools de nós sejam atualizados.

Escolha uma ferramenta para fazer upgrade dos clusters de usuários

O Google Distributed Cloud oferece várias ferramentas para fazer upgrade de clusters de usuários.

• A ferramenta de linha de comando gkectl, que você executa na estação de trabalho do administrador. Antes do upgrade, modifique o arquivo de configuração do cluster de usuário para definir a versão de destino para o plano de controle do cluster e, opcionalmente, para os pools de nós. Esse arquivo é especificado na linha de comando como gkectl.

• O console do Google Cloud, a Google Cloud CLI ou o Terraform, que pode ser executado em qualquer computador que tenha conectividade de rede com a API GKE On-Prem. Essas ferramentas padrão são clientes da API GKE On-Prem, que é executada na infraestrutura do Google Cloud.

  • Só será possível usar o Terraform para o upgrade se você tiver criado o cluster de usuário com ele.

  • Se o cluster de usuário tiver sido criado usando gkectl, ele precisará estar registrado na API GKE On-Prem para usar o console ou a CLI gcloud para o upgrade. Na versão 1.16 e mais recentes, os clusters criados usando gkectl são registrados na API GKE On-Prem por padrão. Para clusters criados em versões anteriores, é possível registrar o cluster depois da criação.

    Mesmo se você decidir usar gkectl para o upgrade, convém registrar o cluster na API GKE On-Prem para receber informações sobre os clusters usando o console ou a CLI gcloud.

A ferramenta usada depende de como você planeja fazer upgrade dos clusters de usuário:

• Fazer upgrade do cluster como um todo: é possível usar o gkectl, o console do Google Cloud, a Google Cloud CLI ou o Terraform para fazer upgrade de um cluster de usuário (o plano de controle com todos os pools de nós).

• Fazer upgrade apenas do plano de controle: é possível usar gkectl, a CLI gcloud ou o Terraform para fazer upgrade do plano de controle de um cluster de usuário separadamente dos pools de nós. O console não dá suporte ao upgrade apenas do plano de controle.

• Fazer o upgrade seletivo de pools de nós após o upgrade do plano de controle: é possível usar gkectl, a CLI gcloud ou o Terraform para fazer upgrade de pools de nós específicos após o upgrade do plano de controle.

• Fazer upgrade do plano de controle e de um ou mais pools de nós ao mesmo tempo: somente gkectl oferece suporte a este caso de uso.

Upgrades de cluster de administrador

Quando o plano de controle e os pools de nós em todos os clusters de usuário são pelo menos uma versão secundária mais recente que o cluster de administrador, é possível fazer upgrade do cluster de administrador. Apenas gkectl oferece suporte ao upgrade de clusters de administrador. Os clientes da API GKE On-Prem não são compatíveis com o upgrade de clusters de administrador.

Versão skew

O desvio de versão é a diferença nas versões secundárias entre um cluster de administrador e os clusters de usuário gerenciados. Nas seções a seguir, a versão do cluster de usuário se refere à versão do plano de controle e dos pools de nós como um todo.

Além disso, o desvio de versão é a diferença nas versões secundárias entre o plano de controle de um cluster de usuário e os pools de nós no cluster de usuário.

Em um ambiente de vários clusters, entender o desvio de versão com suporte e as regras de versão para upgrades pode ajudar a planejar a ordem em que você fará o upgrade dos clusters.

Desvio da versão do cluster de administrador e de usuário

Um cluster de administrador pode gerenciar clusters de usuários que estejam em versões diferentes. Esse recurso permite fazer upgrade de uma frota de clusters de usuários de acordo com uma programação que funcione para sua organização.

Desvio da versão do pool de nós e do plano de controle do cluster de usuário

Regras de versão para clusters de administrador e upgrades do plano de controle do cluster de usuário

As regras de versão para clusters de administrador e upgrades do plano de controle do cluster de usuário são as mesmas. É possível fazer upgrade diretamente para qualquer versão que esteja na mesma outra versão secundária. Por exemplo, é possível fazer upgrade de 1.29.0 para 1.29.1 ou de 1.28.1 para 1.29.0. As versões de patch não afetam as regras de versão de upgrade.

Se você estiver fazendo upgrade para uma versão que não faz parte do próximo lançamento secundário, será necessário fazer o upgrade por meio de uma versão de cada lançamento secundário entre a versão atual e a de destino. Não é possível pular uma versão secundária. Por exemplo, se você quiser fazer upgrade da versão 1.16.x para a versão 1.29.x, não será possível fazer isso diretamente. Primeiro, é necessário fazer upgrade de 1.16.x para 1.28.x e depois para 1.29.x.

Em termos gerais, apenas upgrades de 1.n para 1.n+1 são compatíveis com upgrades de cluster de administrador e de plano de controle do cluster de usuário.

Regras de versão para upgrades de pool de nós

Na versão 1.28 e mais recentes, é possível pular uma versão secundária ao fazer upgrade de um pool de nós em um cluster de usuário. Por exemplo, se um plano de controle do cluster de usuário estiver em 1,29 e um pool de nós estiver em 1,16, pule 1,28 e faça upgrade do pool de nós diretamente para 1,29. As versões de patch não afetam as regras de versão de upgrade.

Em termos gerais, se um plano de controle do cluster de usuário estiver em 1.n, será possível fazer upgrade dos pools de nós que estão em 1.n-2 diretamente para 1.n. Ignorar uma versão secundária ao fazer upgrade de pools de nós pode reduzir o tempo do que fazer dois upgrades de pool de nós (para fazer upgrade de 1.n-2 para 1.n-1 e depois para 1.n). Esse é outro motivo para fazer upgrade do plano de controle de um cluster de usuário separadamente dos pools de nós executados no cluster de usuário.

Upgrades de versão de patchs

Recomendamos que você faça o upgrade para a versão de patch mais recente sempre que possível para garantir que seus clusters tenham as últimas correções de segurança. As versões de patch não afetam as regras de desvio e upgrade da versão. Para uma determinada versão secundária, é possível fazer upgrade para qualquer versão de patch mais recente. 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.1, bem como de 1.28.1 para 1.28.3.

A seguir

Consulte as Práticas recomendadas de upgrade e crie um plano para fazer upgrade dos clusters.