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

Os upgrades de versão ignorada permitem que você pule uma versão secundária ao fazer upgrade dos pools de nós de trabalho depois de atualizar o plano de controle do cluster de usuário, o que reduz o número de ciclos de drenagem e reinicialização de nós. Por exemplo, se um pool de nós de trabalho estiver na versão 1.29, será possível fazer upgrade do plano de controle do cluster de usuário para 1.30 e, em seguida, para 1.31. Depois, faça upgrade do pool de nós de trabalho diretamente de 1.29 para 1.31. Esse recurso é compatível com clusters avançados e não avançados, exceto em clusters avançados da versão 1.31 e no software do Google Distributed Cloud somente para versões do VMware anteriores à 1.28.

Antes de começar, leia as seções Visão geral do upgrade, Regras de versão de upgrade, Práticas recomendadas de upgrade e Fazer upgrade de um cluster.

Limitações

Confira a seguir as limitações dos upgrades de versões ignoradas:

  • Os upgrades de versões ignoradas são compatíveis com pools de nós do Ubuntu e do Container-Optimized OS, 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.

  • Os pools de nós do balanceador de carga (pools de nós com enableLoadBalancer: true) não aceitam upgrades de versão ignorada ou desvio de versão. A versão de um pool de nós do balanceador de carga precisa corresponder à versão do cluster.

  • Devido às 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, o upgrade apenas do plano de controle leva muito menos tempo e é menos arriscado do que o upgrade de pools de nós em que as cargas de trabalho são executadas.

Benefícios dos upgrades de versão com salto

Nesta seção, descrevemos alguns benefícios de usar upgrades de versões ignoradas.

É 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 versão secundária tem uma janela de suporte de um ano. Para que os clusters permaneçam dentro da janela de suporte, é necessário fazer 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 fazer upgrade dos clusters para a nova versão secundária. Para superar esses desafios, use um upgrade de versão de salto, que permite que os clusters permaneçam na janela com suporte, 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 para a versão 1.15 significa que você só fará 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 fazer upgrade dos pools de nós reduz o número de upgrades necessários para permanecer em uma versão compatível. Além disso, não é necessário qualificar a versão secundária ignorada, 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. 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, porque cada nó em um pool de nós é drenado e recriado uma vez. Portanto, um upgrade de versão de salto economiza tempo geral e reduz a interrupção da carga de trabalho.

Resumo

Em resumo, um upgrade de versão de salto 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 não compatível, dependendo da versão do cluster, pular uma versão secundária ao fazer upgrade dos pools de nós poderá 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 de salto leva aproximadamente metade do tempo de fazer upgrade de 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 com upgrades regulares.

  • Reduzir as interrupções: períodos mais longos entre os upgrades e menos tempo gasto com upgrades e validações significam que as 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 alterar 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.

Sequência de upgrade com versões ignoradas

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 esta 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. Em um nível geral, o upgrade do cluster de 1.N para 1.N+2 usando um upgrade de versão de salto funciona da seguinte maneira:

  1. Faça upgrade do cluster de administrador da versão 1.N para uma versão intermediária, 1.N+1.
  2. Faça upgrade do cluster de administrador da versão intermediária, 1.N+1 para a versão de destino 1.N+2.
  3. 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.
  4. 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 o gerencia pode estar na versão 1.16, 1.28 ou 1.29.

  1. Se o cluster de administrador estiver na versão 1.16, faça upgrade para a versão 1.28.
  2. Se o cluster de administrador estiver na versão 1.28, faça upgrade para a 1.29.
  3. 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.
  4. Faça upgrade do cluster de administrador da versão 1.29 para a versão intermediária, 1.30.
  5. Faça upgrade do cluster de administrador para a versão de destino, 1.31.
  6. 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. Em um nível geral, o upgrade do cluster de 1.N para 1.N+2 usando um upgrade de versão de salto funciona da seguinte maneira:

  1. 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.
  2. 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 com salto

Nesta seção, mostramos as etapas para realizar um upgrade de versão ignorada.

Antes de começar

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

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

  3. Para fazer upgrade para a versão 1.28 ou mais recente, é necessário ativar o kubernetesmetadata.googleapis.com e conceder o papel do Identity and Access Management (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.32 e versões mais recentes

Use esta sequência se a versão de destino for 1.32 ou mais recente.

Antes de começar, verifique se o cluster de administrador está pelo menos na mesma versão secundária (1.N) que o cluster de usuário. Se o cluster de usuário estiver na versão 1.30 e o cluster de administrador estiver na versão 1.28 ou 1.29, faça upgrade do cluster de administrador uma versão secundária por vez até chegar à 1.30. Se você já tiver feito upgrade do cluster de administrador para 1.N+1 ou 1.N+2, por exemplo, ao fazer upgrade de outro cluster de usuário, pule as etapas de upgrade do cluster de administrador concluídas.

  1. 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. Especifique números de versão completos no formato X.Y.Z-gke.N, como 1.34.1000-gke.111:

    Descrição Versão
    Consiga a versão atual do cluster de usuário. Essa é a versão de origem (1.N). SOURCE_VERSION
    Selecione uma versão intermediária (1.N+1). INTERMEDIATE_VERSION
    Selecione o patch recomendado na versão secundária de destino (1.N+2). TARGET_VERSION

  2. Faça upgrade da estação de trabalho e do cluster de administrador da versão de origem (1.N) para a versão intermediária (1.N+1):

    1. Faça upgrade da estação de trabalho do administrador para a versão intermediária, INTERMEDIATE_VERSION, e aguarde a conclusão do upgrade.

    2. Importe as imagens do SO do pacote intermediário para o vSphere:

      gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

    3. Defina o campo bundlePath no arquivo de configuração do cluster de administrador como o pacote intermediário:

      bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"

    4. Faça upgrade do cluster de administrador para a versão intermediária:

      gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

      Substitua ADMIN_CLUSTER_CONFIG_FILE pelo caminho do arquivo de configuração do cluster de administrador.

  3. Faça upgrade da estação de trabalho e do cluster de administrador da versão intermediária (1.N+1) para a versão de destino (1.N+2):

    1. Faça upgrade da estação de trabalho do administrador para a versão de destino, TARGET_VERSION, e aguarde a conclusão do upgrade.

    2. Importe as imagens do SO do pacote de destino para o vSphere:

      gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    3. Defina o campo bundlePath no arquivo de configuração do cluster de administrador como o pacote de destino:

      bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"

    4. Faça upgrade do cluster de administrador para a versão de destino:

      gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

  4. Faça upgrade apenas do plano de controle do cluster de usuário da versão de origem (1.N) para a versão intermediária (1.N+1):

    1. Faça as seguintes alterações 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 de trabalho em nodePools[i].gkeOnPremVersion como a versão de origem, SOURCE_VERSION. Se o cluster tiver pools de nós do balanceador de carga (enableLoadBalancer: true), defina o campo gkeOnPremVersion como uma string vazia ("") para que eles sejam atualizados com o plano de controle.

      Depois de atualizar o arquivo de configuração, ele vai ficar parecido com o exemplo a seguir:

      gkeOnPremVersion: INTERMEDIATE_VERSION
# Omitted fields
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  # Omitted fields
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  # Omitted fields

    2. Faça upgrade do plano de controle do cluster de usuário:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

      Substitua USER_CLUSTER_CONFIG_FILE pelo caminho para o arquivo de configuração do cluster de usuário.

  5. Faça upgrade do plano de controle do cluster de usuário e dos pools de nós de trabalho para a versão de destino (1.N+2):

    1. Faça as seguintes alterações no arquivo de configuração do cluster de usuário:

      • Defina o campo gkeOnPremVersion como a versão de destino, TARGET_VERSION.

      • Defina nodePools[i].gkeOnPremVersion para cada pool de nós como uma string vazia ("").

      Depois de atualizar o arquivo de configuração, ele vai ficar parecido com o exemplo a seguir:

      gkeOnPremVersion: TARGET_VERSION
# Omitted fields
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  # Omitted fields
- name: pool-2
  gkeOnPremVersion: ""
  # Omitted fields

    2. Faça upgrade do plano de controle do cluster de usuário e dos pools de nós:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

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 o gerencia pode estar na versão 1.16, 1.28 ou 1.29.

  1. Se o cluster de administrador estiver na versão 1.16, 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.28.

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

  3. Para economizar espaço na estação de trabalho do administrador, remova os pacotes que você baixou:

    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.

  1. 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 de versão completo no formato x.y.z-gke.N, como 1.29.700-gke.110.

    Versão
    Consiga a versão 1.29 do cluster de usuário atual. Essa é 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 da versão secundária 1.31. TARGET_VERSION

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

  3. Instale o pacote correspondente:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  4. Faça upgrade da estação de trabalho de 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.

  5. Instale o pacote correspondente:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  6. 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 alterações 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 como 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.

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

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

  9. 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"

  10. Faça upgrade do cluster de administrador para a versão 1.31 de destino:

    gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

  11. 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 alterações 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 esta sequência se a versão de destino for 1.30 ou anterior.

  1. 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 de versão completo no formato x.y.z-gke.N, como 1.16.11-gke.25.

    Versão
    Confira a versão atual do cluster. Essa é 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

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

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

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

  5. Instale o pacote correspondente:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  6. Faça upgrade apenas do plano de controle para a versão intermediária da seguinte maneira:

    1. Faça as seguintes alterações 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 como 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.

  7. 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 alterações 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

A seguir