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 pelo menos uma versão secundária posterior ao 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 foram modificados nas versões 1.28 e mais recentes. Para mais informações, consulte Distorção de versão.
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. 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 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 comogkectl.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 usandogkectlsã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
gkectlpara 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
gkectloferece 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 têm 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 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.
Em um ambiente de vários clusters, entender o desvio de versão compatível e as regras de versão para upgrades pode ajudar a planejar a ordem de 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.
1.16 e anteriores
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.
1.28 e mais recente
Na versão 1.28 e posterior, os clusters de usuário podem ter até duas versões secundárias
posteriores ao cluster de administrador. Por exemplo, se um cluster de administrador estiver na
1.15, os clusters de usuário gerenciados por ele poderão estar na
1.15, 1.16 ou 1.28 (1.28 é a
versão após 1.16 no
alinhamento da versão com o GKE).
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, 1.n+1 ou 1.n+2.
Não é possível fazer upgrade dos clusters de usuário em 1.n+2 para a próxima versão secundária até que o
cluster de administrador seja atualizado de pelo menos uma versão secundária.
Desvio da versão do pool de nós e do plano de controle do cluster de usuário
1.16 e anteriores
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.
1.28 e mais recente
Na versão 1.28 e posterior, o plano de controle de um cluster de usuário pode ter até duas versões secundárias
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,28, os pools de nós
podem estar em 1,15, 1,16 ou
1,28. 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, 1.n-1
ou 1.n-2.
Não é possível fazer upgrade dos planos de controle do cluster de usuário para a próxima versão secundária até
que todos os pools de nós estejam em 1.n ou 1.n-1.
Regras de versão para upgrades de cluster de administrador e de plano de controle do cluster de usuário
As regras de versão para clusters de administrador e upgrades de 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 versão secundária ou na próxima. Por exemplo, é possível fazer upgrade de 1.28.0 para 1.28.1 ou de 1.16.1 para 1.28.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.15.x para a versão 1.28.x, não será possível fazer upgrade diretamente. Primeiro, você precisa fazer upgrade da 1.15.x para a 1.16.x e, em seguida, fazer o upgrade para 1.28.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 do 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,28 e um pool de nós estiver em 1,15, pule 1.16 e faça upgrade do pool de nós diretamente para 1.28. As versões de patch não afetam as regras da 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 pelo qual você pode preferir 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 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.28.X
para a versão
1.28.Y, desde que
Y seja maior que
X. Por exemplo, é possível fazer upgrade de
1.16.0 para 1.16.1, bem como de
1.16.1 para 1.16.3.
A seguir
Consulte as Práticas recomendadas de upgrade e crie um plano para fazer upgrade dos clusters.