Visão geral do upgrade

Nesta página, você terá uma visão geral do processo de upgrade e informações de desvio de versão que ajudam a planejar a ordem de upgrade de 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:

Faça upgrade da estação de trabalho do administrador. Recomendamos que você faça isso mesmo que precise usar o console do Google Cloud, a Google Cloud CLI ou o Terraform para fazer upgrade dos clusters de usuários.
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 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 dele, o cluster de usuário será completamente atualizado.

Um cluster de administrador não pode estar em uma versão secundária mais recente do que qualquer um dos 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.
Quando todos os clusters de usuário forem uma versão secundária posterior ao cluster de administrador, será possível fazer upgrade do cluster de administrador.

Upgrades de cluster de usuário

Ao fazer upgrade de clusters de usuário, é possível optar por 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) ou fazer upgrade do plano de controle do cluster de usuário e deixar os pools de nós na versão atual. A abordagem adotada depende de vários fatores, como:

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

Por exemplo, em um ambiente de desenvolvimento, talvez você queira manter o processo simples e fazer upgrade do plano de controle do cluster de usuário e de todos os pools de nós. No entanto, em um ambiente de produção com uma janela de manutenção curta, convém atualizar apenas o plano de controle, porque isso leva menos tempo e, com planos de controle de alta disponibilidade (HA, na sigla em inglês), o upgrade não interrompe as cargas de trabalho do usuário.

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 do Windows.

Fazer upgrade seletivo de 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 upgrade do plano de controle, é possível fazer upgrade de um pool de nós que tenha tráfego leve ou execute as cargas de trabalho menos importantes. Depois de se convencer de que as cargas de trabalho são executadas corretamente na nova versão, é possível fazer upgrade de mais pools de nós até que todos sejam atualizados.

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

O GKE no VMware oferece várias ferramentas para fazer upgrade de clusters de usuários.

A ferramenta de linha de comando gkectl, que é executada na estação de trabalho do administrador. Antes do upgrade, você modifica o arquivo de configuração do cluster de usuário para definir a versão de destino do 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.
- O Terraform só poderá ser usado para upgrade se você tiver criado o cluster de usuário com ele.
- Se o cluster de usuário foi criado usando gkectl, ele precisa estar registrado na API GKE On-Prem para usar o console ou a CLI gcloud para o upgrade. Nas versões 1.16 e posteriores, 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 inscrevê-los depois da criação.
  
  Mesmo que você decida 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 que você vai usar depende de como você planeja fazer upgrade dos clusters de usuário:

Fazer upgrade do cluster como um todo: é possível usar 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).
Faça 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 oferece suporte ao upgrade apenas do plano de controle.
Fazer upgrade dos pools de nós seletivamente 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: apenas gkectl oferece suporte a esse 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 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 em 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 juntos como um todo.

Além disso, o desvio da 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 nesse cluster.

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.

Na versão 1.16 e anteriores, os clusters de usuário só podem ser uma versão secundária posterior ao cluster de administrador. Por exemplo, se um cluster de administrador estiver em 1,15, os clusters de usuário gerenciados por ele poderão estar em 1,15 ou 1.16. Em termos gerais, se 1.n for a versão secundária do cluster de administrador, os clusters de usuário poderão estar em 1.n ou 1.n+1.

Não é possível fazer upgrade dos clusters de usuário para a próxima versão secundária até que o cluster de administrador esteja na mesma versão secundária que o de usuário.

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

Na versão 1.16 e anteriores, o plano de controle de um cluster de usuário só pode ser uma versão secundária mais recente que os pools de nós no cluster. Por exemplo, se o plano de controle de um cluster de usuário estiver em 1,16, os pools de nós no cluster podem estar em 1,15 ou 1,16. Em termos gerais, se 1.n for a versão secundária de um plano de controle do cluster de usuário, os pools de nós no cluster poderão estar em 1.n ou 1.n-1.

Não é possível fazer upgrade dos clusters de usuário para a próxima versão secundária até que todos os pools de nós estejam na mesma versão secundária que o plano de controle.

Regras de versão para upgrades de cluster de administrador e de usuário

As regras de versão para fazer upgrade de um cluster de administrador, um plano de controle do cluster de usuário e os pools de nós do cluster de usuário são as mesmas. É possível fazer upgrade diretamente para qualquer versão que esteja na mesma versão secundária ou na próxima. Por exemplo, é possível fazer upgrade da versão 1.16.0 para 1.16.1 ou de 1.15.1 para 1.16.0. As versões de patch não afetam as regras da 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 upgrade para cada versão secundária entre a 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.14.x para a versão 1.16.x, não será possível fazer upgrade diretamente. Primeiro, você precisa fazer upgrade da 1.14.x para a 1.15.x e, em seguida, para a 1.16.x.

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

Upgrades de versão de patchs

Recomendamos que você faça 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. As versões de patch não afetam as regras de desvio e upgrade de versão. 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.

A seguir

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