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 ajudarão você a 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 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 dos 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 informações sobre os motivos para 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, o cluster 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 vai ser possível fazer upgrade dele.

  3. 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 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 a ser 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, 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. 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 os planos de controle de alta disponibilidade (HA, na sigla em inglês), o upgrade do plano de controle 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 com os do Windows.

Fazer upgrade seletivo 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 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 críticas. Quando você estiver convencido de que suas cargas de trabalho são executadas corretamente na nova versão, é possível fazer upgrade de pools de nós adicionais até que todos eles sejam atualizados.

Escolher uma ferramenta para fazer upgrade dos clusters de usuário

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

  • A ferramenta de linha de comando gkectl, executada 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 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ó pode ser usado para o 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. 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, registre o cluster depois de criá-lo.

      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 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).

  • 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 seletivo dos 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: apenas gkectl oferece suporte a esse caso de uso.

Upgrades do 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 da 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 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 no cluster de usuário.

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ário 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 ter uma versão secundária mais tarde que o 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 cluster 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 tarde 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, de um plano de controle do cluster de usuário e de pools de nós de clusters 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 de 1.15.0 para 1.15.1 ou de 1.14.1 para 1.15.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 upgrade para uma versão de cada versão secundária 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.13.x para a versão 1.15.x, não será possível fazer upgrade diretamente. Primeiro, você precisa fazer upgrade da 1.13.x para a 1.14.x e, em seguida, fazer upgrade para 1.15.x.

Em termos gerais, apenas os upgrades de 1.n para 1.n+1 são compatíveis com os 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 seus clusters tenham as correções de segurança mais recentes. As versões de patch não afetam o desvio de versão e as regras de upgrade. É possível fazer upgrade para qualquer versão secundária de uma determinada versão secundária. Ou seja, é possível fazer upgrade de um cluster de versão 1.15.X para a versão 1.15.Y, desde que Y seja maior que X. Por exemplo, é possível fazer upgrade de 1.14.0 para 1.14.1, bem como de 1.14.1 para 1.14.3.

A seguir

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