Na versão 1.29 e mais recentes, o Google Distributed Cloud permite que o plano de controle de um cluster de usuário tenha até duas versões secundárias mais recentes que os pools de nós no cluster. Por exemplo, se o plano de controle de um cluster de usuário estiver na versão 1.29, os pools de nós no cluster poderão estar na versão 1.16, 1.28 ou 1.29. Além disso, o Google Distributed Cloud permite pular uma versão secundária ao atualizar pools de nós. Usando o exemplo anterior, é possível fazer upgrade de pools de nós da versão 1.16 diretamente para a versão 1.29 e ignorar o upgrade para a 1.28. Ignorar uma versão secundária ao fazer upgrade de pools de nós é chamado de upgrade de pular versão.
Os upgrades de versão ignorada são compatíveis com pools de nós do Ubuntu e do COS, mas não com pools de nós do Windows. Além disso, esse recurso não está disponível se você tiver clusters avançados ativados.
Devido às restrições do Kubernetes, o plano de controle de um cluster de usuário precisa ser atualizado uma versão secundária de cada vez. No entanto, o upgrade apenas do plano de controle leva muito menos tempo e é menos arriscado do que atualizar os pools de nós em que as cargas de trabalho são executadas.
Esta página explica alguns dos benefícios de um upgrade de versão pulada e
fornece etapas para realizar um upgrade de versão pulada fazendo
mudanças no arquivo de configuração e executando gkectl upgrade cluster.
Esta página é destinada a administradores de TI e operadores que gerenciam o ciclo de vida da infraestrutura de tecnologia subjacente. Para saber mais sobre papéis comuns e exemplos de tarefas que mencionamos no conteúdo do Google Cloud , consulte Tarefas e funções de usuário comuns do GKE Enterprise. Nesta página, presumimos que você tenha algum conhecimento sobre como planejar e executar upgrades do Google Distributed Cloud, conforme descrito abaixo:
Benefícios dos upgrades de versão pulada
Esta seção descreve alguns benefícios do uso de upgrades de versão de salto.
É mais fácil manter os clusters em uma versão com suporte
Uma nova versão secundária do Google Distributed Cloud é lançada a cada quatro meses, e cada versão secundária tem um período de suporte de um ano. Para que seus clusters permaneçam dentro da janela de suporte, faça um upgrade de versão secundária aproximadamente a cada quatro meses, conforme mostrado abaixo:
Dez |
Jan |
Fev |
Mar |
Abr |
Mai |
Jun |
Jul |
Ago |
Set |
Out |
Nov |
Dez |
Jan |
Fev |
Mar |
Abr |
Mai |
Jun |
Jul |
Ago |
Set |
Out |
Nov |
Dez |
Jan |
Fev |
Mar |
| 1.14 | Fazer upgrade | ||||||||||||||||||||||||||
| 1.15 | Fazer upgrade | ||||||||||||||||||||||||||
| 1.16 | Fazer upgrade | ||||||||||||||||||||||||||
| 1.28 | Fazer upgrade | ||||||||||||||||||||||||||
| 1,29 | Fazer upgrade |
Esse requisito impõe desafios quando você precisa de uma janela de validação longa para verificar uma nova versão secundária e uma janela de manutenção curta para atualizar seus clusters para a nova versão secundária. Para superar esses desafios, use um upgrade de versão pulada, que permite que seus clusters permaneçam dentro da janela de suporte fazendo upgrade de um cluster a cada oito meses em vez de quatro meses. A tabela a seguir mostra como pular o upgrade para a versão 1.15 significa que você só faz o upgrade após oito meses em vez de quatro.
Dez |
Jan |
Fev |
Mar |
Abr |
Mai |
Jun |
Jul |
Ago |
Set |
Out |
Nov |
Dez |
Jan |
Fev |
Mar |
Abr |
Mai |
Jun |
Jul |
Ago |
Set |
Out |
Nov |
Dez |
Jan |
Fev |
Mar |
| 1.14 | Fazer upgrade | ||||||||||||||||||||||||||
| 1.15 | |||||||||||||||||||||||||||
| 1.16 | Fazer upgrade | ||||||||||||||||||||||||||
| 1.28 | |||||||||||||||||||||||||||
| 1,29 |
Pular uma versão secundária ao atualizar os pools de nós reduz o número de upgrades necessários para permanecer em uma versão com suporte. Além disso, não é necessário qualificar a versão secundária pulada, porque ela é usada apenas temporariamente pelo plano de controle.
Janela de manutenção mais curta
Com um upgrade de versão ignorada, não é necessário aumentar a janela de manutenção. O salto de uma versão secundária ao fazer upgrade de pools de nós leva o mesmo tempo que o upgrade para a próxima versão secundária, porque cada nó em um pool de nós é drenado e recriado uma vez. Portanto, um upgrade de versão de salto economiza tempo e reduz a interrupção da carga de trabalho.
Resumo
Em resumo, um upgrade de versão pulada oferece os seguintes benefícios:
Atualizar clusters para uma versão com suporte: o Google Distributed Cloud oferece suporte às três versões secundárias mais recentes. Se os clusters estiverem em uma versão sem suporte, dependendo da versão do cluster, pular uma versão secundária ao atualizar os pools de nós pode levar os clusters a uma versão com suporte com menos upgrades.
Economize tempo: pular uma versão secundária ao fazer upgrade de pools de nós leva o mesmo tempo que fazer upgrade dos pools de nós para a próxima versão secundária. Portanto, um upgrade de versão de salto leva aproximadamente a metade do tempo de fazer upgrade de pools de nós duas vezes. Da mesma forma, com um upgrade de versão de salto, você tem apenas uma janela de validação, em comparação com duas com upgrades regulares.
Redução de interrupções: intervalos mais longos entre upgrades e menos tempo gasto fazendo upgrades e validações significam que suas cargas de trabalho são executadas por mais tempo com menos interrupções.
Como controlar as versões do plano de controle e do pool de nós durante um upgrade
No arquivo de configuração do cluster de usuário, o campo
nodePools[i].gkeOnPremVersion
permite que um pool de nós específico use uma versão diferente do campo
gkeOnPremVersion
de nível superior. Ao mudar o valor do campo nodePools[i].gkeOnPremVersion, você
controla quando um pool de nós é atualizado ao executar gkectl upgrade cluster.
Se você não incluir nodePools[i].gkeOnPremVersion no arquivo de configuração ou definir o campo como uma string vazia, os pools de nós serão atualizados para a mesma versão de destino especificada em gkeOnPremVersion.
Regras de versão
As regras para upgrades dependem da versão secundária do cluster.
Nas versões 1.30 e anteriores, a versão secundária do cluster de usuário precisa ser igual ou maior que a do cluster de administrador. A versão do patch não importa. Por exemplo, se um cluster de usuário estiver na versão 1.30.1, o cluster de administrador poderá ser atualizado para uma versão de patch mais recente, como 1.30.3.
Para as versões 1.31 e mais recentes, a versão do cluster de administrador, incluindo a versão do patch, precisa ser maior ou igual à do cluster de usuário. Por exemplo, se um cluster de administrador estiver na versão 1.31.1, a versão mais recente para a qual o cluster de usuário pode ser atualizado é 1.31.1.
Quando você quiser fazer upgrade dos clusters para a versão 1.31, primeiro é necessário levar todos os clusters para a versão 1.30. Depois que todos os clusters estiverem na versão 1.30, faça upgrade do cluster de administrador para a versão 1.31. Depois disso, você pode fazer upgrade dos clusters de usuário para a mesma versão do patch 1.31 do cluster de administrador.
Sequência de upgrade de versão ignorada
A sequência em que você faz upgrade dos clusters de administrador e de usuário depende da versão do cluster para a qual você está fazendo upgrade, chamada de versão de destino:
1.31
Use essa sequência especial se o cluster de usuários estiver na versão 1.29, o que significa que a versão de destino é 1.31. Quando um cluster de usuário está na versão 1.29, um cluster de administrador que gerencia o cluster de usuário pode estar na versão 1.27, 1.28 ou 1.29.
- Se o cluster de administrador estiver na versão 1.27, faça upgrade para a versão 1.28.
- Se o cluster de administrador estiver na versão 1.28, faça upgrade para a versão 1.29.
- Faça upgrade apenas do plano de controle do cluster de usuário da versão de origem, 1.29, para uma versão intermediária, 1.30. Deixe os pools de nós na versão de origem. A versão intermediária 1.30 é necessária porque o plano de controle precisa ser atualizado uma versão secundária de cada vez.
- Faça upgrade do cluster de administrador da versão 1.29 para a versão intermediária, 1.30.
- Faça upgrade do cluster de administrador para a versão de destino, 1.31.
- Faça upgrade do plano de controle do cluster de usuário e dos pools de nós para a versão de destino, 1.31.
1.30 e versões anteriores
Use esta sequência se a versão de destino for 1.30 ou anterior.
Suponha que o plano de controle do cluster de usuário e todos os pools de nós estejam na versão
secundária 1.N. De modo geral, o upgrade do cluster de
1.N para 1.N+2 usando um upgrade de versão de salto funciona
da seguinte maneira:
- Faça upgrade apenas do plano de controle da versão de origem,
1.N, para uma versão intermediária1.N+1. Deixe os pools de nós na versão de origem. A versão intermediária é necessária porque o plano de controle precisa ser atualizado uma versão secundária de cada vez. - Faça upgrade do plano de controle e dos pools de nós para a versão de destino
1.N+2.
Fazer upgrade de uma versão pulada
Esta seção mostra as etapas para fazer upgrade de uma versão.
Antes de começar
Verifique se a versão atual (a versão de origem) do cluster está na versão 1.16 ou mais recente. Verifique a versão do plano de controle (
gkeOnPremVersion) e de todos os pools de nós (nodePools[i].gkeOnPremVersion).Na versão 1.29 e mais recentes, as verificações de simulação do lado do servidor são ativadas por padrão. Revise suas regras de firewall para fazer as mudanças necessárias.
Para fazer upgrade para a versão 1.28 ou mais recente, é necessário ativar o
kubernetesmetadata.googleapis.come conceder o papel do IAMkubernetesmetadata.publisherà conta de serviço de monitoramento de registros. Para mais detalhes, consulte Requisitos da API Google e do IAM.
Faça upgrade
1.31
Use essa sequência especial se o cluster de usuário estiver na versão 1.29, o que significa que a versão de destino é 1.31. Essa sequência é necessária porque as regras de versão foram alteradas na versão 1.31.
Quando um cluster de usuário está na versão 1.29, um cluster de administrador que gerencia o cluster de usuário pode estar na versão 1.27, 1.28 ou 1.29.
Se o cluster de administrador estiver na versão 1.27, siga as etapas para fazer upgrade da estação de trabalho do administrador e fazer upgrade do cluster de administrador para a versão 1.28.
Se o cluster de administrador estiver na versão 1.28, siga as etapas para fazer upgrade da estação de trabalho do administrador e do cluster de administrador para a versão 1.29.
Para economizar espaço na estação de trabalho do administrador, remova os pacotes transferidos:
rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz
Quando o cluster de administrador e todos os clusters de usuário estiverem na versão 1.29, será possível iniciar o upgrade de versão de salto.
Defina a versão de origem (1.29), uma versão intermediária (1.30) e a versão de destino (1.31) nas variáveis de marcador de posição a seguir. Todas as versões precisam ser o número completo da versão no formato
x.y.z-gke.N, como1.29.700-gke.110.Versão Acesse a versão 1.29 do cluster de usuário atual. Esta é a versão de origem. SOURCE_VERSIONEscolha uma versão intermediária 1.30. INTERMEDIATE_VERSIONEscolha a versão de destino 1.31. Selecione o patch recomendado da versão secundária 1.31. TARGET_VERSIONFaça upgrade da estação de trabalho do administrador para a versão intermediária 1.30,
INTERMEDIATE_VERSION. Aguarde uma mensagem indicando que o upgrade foi concluído.Instale o pacote correspondente:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGFaça upgrade da estação de trabalho do administrador novamente, mas desta vez para a versão de destino 1.31,
TARGET_VERSION. Aguarde uma mensagem indicando que o upgrade foi concluído.Instale o pacote correspondente:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGFaça upgrade apenas do plano de controle do cluster de usuário para a versão intermediária da seguinte maneira:
Faça as seguintes alterações no arquivo de configuração do cluster de usuário:
Defina o campo
gkeOnPremVersioncomo a versão intermediária,INTERMEDIATE_VERSION.Defina todas as versões do pool de nós em
nodePools[i].gkeOnPremVersionpara a versão de origem,SOURCE_VERSION.
Depois de atualizar o arquivo de configuração, ele vai ficar parecido com este:
gkeOnPremVersion: INTERMEDIATE_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: SOURCE_VERSION ... - name: pool-2 gkeOnPremVersion: SOURCE_VERSION ...
Faça upgrade do plano de controle:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILESubstitua
USER_CLUSTER_CONFIGpelo caminho do arquivo de configuração do cluster de usuário.
Defina o campo
bundlePathno arquivo de configuração do cluster de administrador como a versão intermediária 1.30 do pacote:bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"
Faça upgrade do cluster de administrador para a versão intermediária 1.30:
gkectl upgrade admin \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG_FILEDefina o campo
bundlePathno arquivo de configuração do cluster de administrador como a versão 1.31 do pacote:bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"
Upgrade the admin cluster to the target 1.31 version:
gkectl upgrade admin \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG_FILEFaça upgrade do plano de controle e dos pools de nós para a versão de destino da seguinte maneira:
Faça as seguintes alterações no arquivo de configuração do cluster de usuário:
Defina o campo
gkeOnPremVersioncomo a versão de destino,TARGET_VERSION.Defina todos os
nodePools[i].gkeOnPremVersioncomo uma string vazia.
Depois de atualizar o arquivo de configuração, ele vai ficar parecido com este:
gkeOnPremVersion: TARGET_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: "" ... - name: pool-2 gkeOnPremVersion: "" ...
Faça upgrade do plano de controle e dos pools de nós:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
1.30 e versões anteriores
Use esta sequência se a versão de destino for 1.30 ou anterior.
Defina a versão de origem (
1.N), a versão intermediária (1.N+1) e a versão de destino (1.N+2) nas variáveis de marcador de posição a seguir. Todas as versões precisam ser o número completo da versão no formatox.y.z-gke.N, como1.16.11-gke.25.Versão Receba a versão atual do cluster. Esta é a versão de origem ( 1.N).SOURCE_VERSIONEscolha uma versão intermediária ( 1.N+1).INTERMEDIATE_VERSIONEscolha a versão de destino ( 1.N+2). Selecione o patch recomendado da versão secundária de destino.TARGET_VERSIONFaça upgrade da estação de trabalho do administrador para a versão intermediária,
INTERMEDIATE_VERSION. Aguarde uma mensagem indicando que o upgrade foi concluído.Instale o pacote correspondente:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGSubstitua
ADMIN_CLUSTER_KUBECONFIGpelo caminho do arquivokubeconfigdo cluster de administrador.Faça upgrade da estação de trabalho do administrador novamente, mas desta vez para a versão de destino,
TARGET_VERSION. Aguarde uma mensagem indicando que o upgrade foi concluído.Instale o pacote correspondente:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGFaça upgrade apenas do plano de controle para a versão intermediária da seguinte maneira:
Faça as seguintes alterações no arquivo de configuração do cluster de usuário:
Defina o campo
gkeOnPremVersioncomo a versão intermediária,INTERMEDIATE_VERSION.Defina todas as versões do pool de nós em
nodePools[i].gkeOnPremVersionpara a versão de origem,SOURCE_VERSION.
Depois de atualizar o arquivo de configuração, ele vai ficar parecido com este:
gkeOnPremVersion: INTERMEDIATE_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: SOURCE_VERSION ... - name: pool-2 gkeOnPremVersion: SOURCE_VERSION ...
Faça upgrade do plano de controle:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILESubstitua
USER_CLUSTER_CONFIGpelo caminho do arquivo de configuração do cluster de usuário.
Faça upgrade do plano de controle e dos pools de nós para a versão de destino da seguinte maneira:
Faça as seguintes alterações no arquivo de configuração do cluster de usuário:
Defina o campo
gkeOnPremVersioncomo a versão de destino,TARGET_VERSION.Defina todos os
nodePools[i].gkeOnPremVersioncomo uma string vazia.
Depois de atualizar o arquivo de configuração, ele vai ficar parecido com este:
gkeOnPremVersion: TARGET_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: "" ... - name: pool-2 gkeOnPremVersion: "" ...
Faça upgrade do plano de controle e dos pools de nós:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
Se você não tiver outros clusters de usuários para fazer upgrade, remova os pacotes da estação de trabalho do administrador para economizar espaço:
rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz