Esta página foi traduzida pela API Cloud Translation.

Pular uma versão ao fazer upgrade de pools de nós

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 nas versões 1.16, 1.28 ou 1.29. Além disso, o Google Distributed Cloud permite pular uma versão secundária ao fazer upgrade de pools de nós. Usando o exemplo anterior, é possível fazer upgrade dos pools de nós na versão 1.16 diretamente para a versão 1.29 e ignorar o upgrade para a 1.28. Pular uma versão secundária ao fazer upgrade de pools de nós é chamado de upgrade de versão ignorada.

Nesta página, explicamos alguns dos benefícios de um upgrade de versão com skip e mostramos as etapas para realizar esse upgrade 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 tarefas de exemplo referenciados no conteúdo do Google Cloud , consulte Tarefas e funções de usuário comuns do GKE. Nesta página, presumimos que você esteja familiarizado com o planejamento e a execução de upgrades do Google Distributed Cloud, conforme descrito nos seguintes links:

Limitações

Os upgrades de versão têm as seguintes limitações:

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.
Versão 1.31: esse recurso não está disponível em clusters avançados.
Versão 1.32 e mais recentes: esse recurso está disponível em clusters avançados.
Devido a restrições do Kubernetes, o plano de controle de um cluster de usuário precisa ser atualizado uma versão secundária por vez. No entanto, fazer upgrade apenas do plano de controle leva muito menos tempo e é menos arriscado do que fazer upgrade dos pools de nós em que as cargas de trabalho são executadas.

Benefícios dos upgrades de versão com skip

Esta seção descreve alguns benefícios de usar upgrades de versão com skip.

É mais fácil manter os clusters em uma versão compatível.

Uma nova versão secundária do Google Distributed Cloud é lançada a cada quatro meses, e cada uma delas 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

Dezembro

Jan

Fev

Mar

Abr

Mai

Jun

Jul

Ago

Set

Out

Nov

Dezembro

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 longa janela de validação para verificar uma nova versão secundária e uma janela de manutenção curta para fazer upgrade dos clusters para a nova versão secundária. Para superar esses desafios, use um upgrade de versão ignorada, que permite que seus clusters permaneçam na janela compatível fazendo upgrade de um cluster a cada oito meses em vez de a cada quatro meses. A tabela a seguir mostra como pular o upgrade da versão 1.15 significa que você só vai fazer o upgrade depois de oito meses, em vez de quatro.

Dez

Jan

Fev

Mar

Abr

Mai

Jun

Jul

Ago

Set

Out

Nov

Dezembro

Jan

Fev

Mar

Abr

Mai

Jun

Jul

Ago

Set

Out

Nov

Dezembro

Jan

Fev

Mar

1.14

Fazer upgrade

1.15

1.16

Fazer upgrade

1.28

1,29

Pular uma versão secundária ao fazer upgrade dos pools de nós reduz o número de upgrades necessários para manter uma versão compatível. Além disso, não é necessário qualificar a versão secundária ignorada porque ela é usada apenas pelo plano de controle temporariamente.

Janela de manutenção mais curta

Com um upgrade de versão ignorada, não é necessário aumentar a janela de manutenção. Pular uma versão secundária ao fazer upgrade de pools de nós leva o mesmo tempo que fazer 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 ignorada economiza tempo e reduz a interrupção da carga de trabalho.

Resumo

Em resumo, um upgrade de versão ignorada oferece os seguintes benefícios:

Atualize os clusters para uma versão compatível: o Google Distributed Cloud é compatível com as 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 fazer upgrade dos pools de nós pode levar os clusters a uma versão compatível 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 ignorada leva aproximadamente metade do tempo de atualizar os pools de nós duas vezes. Da mesma forma, com um upgrade de versão ignorada, você tem apenas uma janela de validação, em comparação com duas em upgrades regulares.
Reduzir interrupções: intervalos mais longos entre upgrades e menos tempo gasto com 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 se 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 da versão

As regras para upgrades dependem da versão secundária do cluster.

Para as versões 1.30 e anteriores, a versão secundária do cluster de usuário precisa ser maior ou igual à versão secundária 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 à versão 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 que 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 traga 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, é possível fazer upgrade dos clusters de usuário para a mesma versão de 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.32 e versões mais recentes

Use essa sequência se a versão de destino for 1.32 ou mais recente. 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 com skip funciona da seguinte maneira:

Faça upgrade do cluster de administrador da versão 1.N para uma versão intermediária, 1.N+1.
Faça upgrade do cluster de administrador da versão intermediária 1.N+1 para a versão de destino 1.N+2.
Faça upgrade apenas do plano de controle do cluster de usuário da versão de origem, 1.N, para uma versão intermediária, 1.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 por vez.
Faça upgrade do plano de controle e dos pools de nós para a versão de destino, 1.N+2.

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. 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 1.28.
Se o cluster de administrador estiver na versão 1.28, faça upgrade para a 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 por 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 essa 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 com skip funciona da seguinte maneira:

Faça upgrade apenas do plano de controle da versão de origem, 1.N, para uma versão intermediária 1.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 por vez.
Faça upgrade do plano de controle e dos pools de nós para a versão de destino 1.N+2.

Fazer um upgrade de versão ignorada

Esta seção mostra as etapas para realizar um upgrade de versão ignorada.

Antes de começar

Verifique se a versão atual (a versão de origem) do cluster é a 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 as 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.com e conceder o papel do IAM kubernetesmetadata.publisher à conta de serviço de monitoramento de registros. Para mais detalhes, consulte Requisitos da API do 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 mudaram 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 de administrador e fazer upgrade do cluster de administrador para a versão 1.29.
Para economizar espaço na estação de trabalho de administrador, remova os pacotes baixados:
```
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 ignorada.

Defina a versão de origem (1.29), uma versão intermediária (1.30) e a versão de destino (1.31) nas seguintes variáveis de marcador de posição. Todas as versões precisam ser o número completo no formato x.y.z-gke.N, como 1.29.700-gke.110.

Versão
Confira a versão 1.29 do cluster de usuário atual. Esta é a versão de origem.	`SOURCE_VERSION`
Escolha uma versão intermediária 1.30.	`INTERMEDIATE_VERSION`
Escolha a versão de destino 1.31. Selecione o patch recomendado na versão secundária 1.31.	`TARGET_VERSION`

Faç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_KUBECONFIG

Faça upgrade da estação de trabalho do administrador de novo, mas desta vez para a versão 1.31 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_KUBECONFIG

Faça upgrade apenas do plano de controle do cluster de usuário para a versão intermediária da seguinte maneira:
1. Faça as seguintes mudanças no arquivo de configuração do cluster de usuário:
  - Defina o campo gkeOnPremVersion como a versão intermediária, INTERMEDIATE_VERSION.
  - Defina todas as versões do pool de nós em nodePools[i].gkeOnPremVersion para a versão de origem, SOURCE_VERSION.
  Depois de atualizar o arquivo de configuração, ele vai ficar assim:
```
gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...
```
2. Faça upgrade do plano de controle:
```
gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
```
  Substitua USER_CLUSTER_CONFIG pelo caminho do arquivo de configuração do cluster de usuário.
Defina o campo bundlePath no 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_FILE

Defina o campo bundlePath no arquivo de configuração do cluster de administrador como a versão 1.31 de destino 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_FILE

Faça upgrade do plano de controle e dos pools de nós para a versão de destino da seguinte maneira:
1. Faça as seguintes mudanças no arquivo de configuração do cluster de usuário:
  - Defina o campo gkeOnPremVersion como a versão de destino, TARGET_VERSION.
  - Defina todos os nodePools[i].gkeOnPremVersion como uma string vazia.
  Depois de atualizar o arquivo de configuração, ele vai ficar assim:
```
gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...
```
2. 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 essa 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 seguintes variáveis de marcador de posição. Todas as versões precisam ser o número completo no formato x.y.z-gke.N, como 1.16.11-gke.25.

Versão
Confira a versão atual do cluster. Esta é a versão de origem (`1.N`).	`SOURCE_VERSION`
Escolha uma versão intermediária (`1.N+1`).	`INTERMEDIATE_VERSION`
Escolha a versão de destino (`1.N+2`). Selecione o patch recomendado na versão secundária de destino.	`TARGET_VERSION`

Faç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_KUBECONFIG

Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de administrador.

Faça upgrade da estação de trabalho do administrador de novo, 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_KUBECONFIG

Faça upgrade apenas do plano de controle para a versão intermediária da seguinte maneira:
1. Faça as seguintes mudanças no arquivo de configuração do cluster de usuário:
  - Defina o campo gkeOnPremVersion como a versão intermediária, INTERMEDIATE_VERSION.
  - Defina todas as versões do pool de nós em nodePools[i].gkeOnPremVersion para a versão de origem, SOURCE_VERSION.
  Depois de atualizar o arquivo de configuração, ele vai ficar assim:
```
gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...
```
2. Faça upgrade do plano de controle:
```
gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
```
  Substitua USER_CLUSTER_CONFIG pelo 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:
1. Faça as seguintes mudanças no arquivo de configuração do cluster de usuário:
  - Defina o campo gkeOnPremVersion como a versão de destino, TARGET_VERSION.
  - Defina todos os nodePools[i].gkeOnPremVersion como uma string vazia.
  Depois de atualizar o arquivo de configuração, ele vai ficar assim:
```
gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...
```
2. 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ário para fazer upgrade, remova os pacotes da estação de trabalho de administrador para economizar espaço:

rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz

Pular uma versão ao fazer upgrade de pools de nós Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Limitações

Benefícios dos upgrades de versão com skip

É mais fácil manter os clusters em uma versão compatível.

Janela de manutenção mais curta

Resumo

Como controlar as versões do plano de controle e do pool de nós durante um upgrade

Regras da versão

Sequência de upgrade de versão ignorada

1.32 e versões mais recentes

1.31

1.30 e versões anteriores

Fazer um upgrade de versão ignorada

Antes de começar

Faça upgrade

1.31

1.30 e versões anteriores

A seguir

Pular uma versão ao fazer upgrade de pools de nós