Ignore uma versão ao atualizar node pools

Na versão 1.29 e superior, o Google Distributed Cloud permite que o plano de controlo de um cluster de utilizadores seja até duas versões secundárias superior aos conjuntos de nós no cluster. Por exemplo, se o plano de controlo de um cluster de utilizadores estiver na versão 1.29, os conjuntos de nós no cluster podem estar nas versões 1.16, 1.28 ou 1.29. Além disso, o Google Distributed Cloud permite ignorar uma versão secundária ao atualizar os conjuntos de nós. Usando o exemplo anterior, pode atualizar os conjuntos de nós que estão na versão 1.16 diretamente para a versão 1.29 e ignorar a atualização para a versão 1.28. Ignorar uma versão secundária ao atualizar os node pools é denominado atualização de versão ignorada.

Esta página explica algumas das vantagens de uma atualização de versão com omissão e fornece passos sobre como realizar uma atualização de versão com omissão através da alteração de ficheiros de configuração e da execução de gkectl upgrade cluster.

Esta página destina-se a administradores de TI e operadores que gerem o ciclo de vida da infraestrutura tecnológica subjacente. Para saber mais sobre as funções comuns e as tarefas de exemplo a que fazemos referência no Google Cloud conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Esta página pressupõe que tem algum conhecimento sobre o planeamento e a execução de atualizações do Google Distributed Cloud, conforme descrito no seguinte:

Limitações

As atualizações com ignorância de versões têm as seguintes limitações:

  • As atualizações de versões são suportadas para pools de nós do Ubuntu e do COS, mas não para pools de nós do Windows.

  • Versão 1.31: esta funcionalidade não está disponível em clusters avançados.

  • Versão 1.32 e superior: esta funcionalidade está disponível em clusters avançados.

  • Devido às restrições do Kubernetes, o painel de controlo de um cluster de utilizador tem de ser atualizado uma versão secundária de cada vez. No entanto, tenha em atenção que a atualização apenas do plano de controlo demora significativamente menos tempo e é menos arriscada do que a atualização dos conjuntos de nós onde as suas cargas de trabalho são executadas.

Vantagens das atualizações com omissão de versões

Esta secção descreve algumas vantagens da utilização de atualizações com omissão de versões.

É mais fácil manter os seus clusters numa versão suportada

É lançada uma nova versão secundária do Google Distributed Cloud a cada quatro meses, e cada versão secundária tem um período de apoio técnico de um ano. Para que os seus clusters permaneçam dentro do período suportado, tem de fazer uma atualização da versão secundária aproximadamente a cada quatro meses, conforme mostrado no seguinte:

Dez

Jan

Fev

Mar

Abr

Maio

Jun

Jul

Ago

Set

Out

Nov

Dez

Jan

Fev

Mar

Abr

Maio

Jun

Jul

Ago

Set

Out

Nov

Dez

Jan

Fev

Mar
1.14 Atualize
1.15 Atualize
1.16 Atualize
1,28 Atualize
1,29 Atualize

Este requisito impõe desafios quando precisa de um longo período de validação para validar uma nova versão secundária e um curto período de manutenção para atualizar os clusters para a nova versão secundária. Para superar estes desafios, pode usar uma atualização de versão com omissão, que permite que os seus clusters permaneçam dentro do período suportado atualizando um cluster a cada oito meses, em vez de a cada quatro meses. A tabela seguinte mostra como ignorar a atualização para a versão 1.15 significa que só faz a atualização após oito meses em vez de quatro.

Dez

Jan

Fev

Mar

Abr

Maio

Jun

Jul

Ago

Set

Out

Nov

Dez

Jan

Fev

Mar

Abr

Maio

Jun

Jul

Ago

Set

Out

Nov

Dez

Jan

Fev

Mar
1.14 Atualize
1.15
1.16 Atualize
1,28
1,29

Ignorar uma versão secundária ao atualizar os conjuntos de nós reduz o número de atualizações necessárias para permanecer numa versão suportada. Além disso, não precisa de qualificar a versão secundária ignorada porque só é usada temporariamente pelo plano de controlo.

Período de manutenção mais curto

Com uma atualização de versão ignorada, não precisa de aumentar o período de manutenção. Ignorar uma versão secundária ao atualizar os node pools demora o mesmo tempo que atualizar os node pools para a versão secundária seguinte, porque cada nó num node pool é esvaziado e recriado uma vez. Por isso, uma atualização de versão com omissão de versões poupa tempo no geral e reduz a interrupção da carga de trabalho.

Resumo

Em resumo, uma atualização com omissão de versões oferece as seguintes vantagens:

  • Atualize os clusters para uma versão suportada: o Google Distributed Cloud suporta as três versões secundárias mais recentes. Se os seus clusters estiverem numa versão não suportada, dependendo da versão do cluster, ignorar uma versão secundária ao atualizar os conjuntos de nós pode fazer com que os seus clusters passem para uma versão suportada com menos atualizações.

  • Poupe tempo: ignorar uma versão secundária ao atualizar os conjuntos de nós demora o mesmo tempo que atualizar os conjuntos de nós para a versão secundária seguinte. Por conseguinte, uma atualização de versão com omissão demora aproximadamente metade do tempo de atualizar os node pools duas vezes. Da mesma forma, com uma atualização de versão ignorada, tem apenas uma janela de validação, em comparação com duas com atualizações normais.

  • Reduza as interrupções: os intervalos mais longos entre atualizações e o menor tempo gasto na atualização e validação significam que as suas cargas de trabalho são executadas durante mais tempo com menos interrupções.

Controlar as versões do painel de controlo e do node pool durante uma atualização

No ficheiro de configuração do cluster de utilizadores, 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, controla quando um conjunto de nós é atualizado quando executa gkectl upgrade cluster. Se não incluir nodePools[i].gkeOnPremVersion no ficheiro de configuração ou se definir o campo como uma string vazia, os conjuntos de nós são atualizados para a mesma versão de destino que especificar em gkeOnPremVersion.

Regras de versões

As regras para atualizações dependem da versão secundária do cluster.

  • Para as versões 1.30 e inferiores, a versão secundária do cluster de utilizadores tem de ser superior ou igual à versão secundária do cluster de administrador. A versão do patch não é importante. Por exemplo, se um cluster de utilizadores estiver na versão 1.30.1, o cluster de administrador pode ser atualizado para uma versão de patch superior, como a 1.30.3.

  • Para as versões 1.31 e superiores, a versão do cluster de administrador, incluindo a versão de patch, tem de ser superior ou igual à versão do cluster de utilizador. Por exemplo, se um cluster de administrador estiver na versão 1.31.1, a versão mais elevada para a qual o cluster de utilizador pode ser atualizado é 1.31.1.

Quando quiser atualizar os seus clusters para a versão 1.31, tem de atualizar primeiro todos os seus clusters para a versão 1.30. Depois de todos os clusters estarem na versão 1.30, atualize o cluster de administrador para a versão 1.31. Depois disso, pode atualizar os clusters de utilizadores para a mesma versão de patch 1.31 que o cluster de administrador.

Sequência de atualização de versões ignoradas

A sequência em que atualiza os clusters de administrador e de utilizador depende da versão do cluster para a qual está a fazer a atualização, denominada versão de destino:

1.32 e superior

Use esta sequência se a versão de destino for 1.32 ou superior. Suponhamos que o plano de controlo do cluster de utilizadores e todos os conjuntos de nós estão na versão secundária 1.N. A um nível elevado, a atualização do cluster de 1.N para 1.N+2 através de uma atualização de versão ignorada funciona da seguinte forma:

  1. Atualize o cluster de administrador da versão 1.N para uma versão intermédia, 1.N+1.
  2. Atualize o cluster de administrador da versão intermédia, 1.N+1 para a versão de destino 1.N+2.
  3. Atualize apenas o plano de controlo do cluster de utilizadores da versão de origem, 1.N, para uma versão intermédia, 1.N+1. Deixar os conjuntos de nós na versão de origem. A versão intermédia é necessária porque o plano de controlo tem de ser atualizado uma versão secundária de cada vez.
  4. Atualize o plano de controlo e os node pools para a versão de destino, 1.N+2.

1.31

Use esta sequência especial se o cluster de utilizadores estiver na versão 1.29, o que significa que a versão de destino é 1.31. Quando um cluster de utilizadores está na versão 1.29, um cluster de administrador que gere o cluster de utilizadores pode estar na versão 1.27, 1.28 ou 1.29.

  1. Se o cluster de administrador estiver na versão 1.27, atualize-o para a versão 1.28.
  2. Se o cluster de administrador estiver na versão 1.28, atualize-o para a versão 1.29.
  3. Atualize apenas o plano de controlo do cluster de utilizadores da versão de origem, 1.29, para uma versão intermédia, 1.30. Deixe os conjuntos de nós na versão de origem. A versão 1.30 intermédia é necessária porque o plano de controlo tem de ser atualizado uma versão secundária de cada vez.
  4. Atualize o cluster de administrador da versão 1.29 para a versão intermédia, 1.30.
  5. Atualize o cluster de administrador para a versão de destino, 1.31.
  6. Atualize o painel de controlo do cluster de utilizador e os node pools para a versão de destino 1.31.

1,30 e inferior

Use esta sequência se a versão de destino for 1.30 ou inferior.

Suponhamos que o plano de controlo do cluster de utilizadores e todos os conjuntos de nós estão na versão secundária 1.N. A um nível elevado, a atualização do cluster de 1.N para 1.N+2 através de uma atualização de versão ignorada funciona da seguinte forma:

  1. Atualize apenas o plano de controlo da versão de origem, 1.N, para uma versão intermédia 1.N+1. Deixe os conjuntos de nós na versão de origem. A versão intermédia é necessária porque o plano de controlo tem de ser atualizado uma versão secundária de cada vez.
  2. Atualize o plano de controlo e os node pools para a versão de destino 1.N+2.

Faça uma atualização de versão ignorada

Esta secção fornece os passos para fazer uma atualização com omissão de versão.

Antes de começar

  1. Certifique-se de que a versão atual (a versão de origem) do cluster é a versão 1.16 ou superior. Certifique-se de que verifica a versão do plano de controlo (gkeOnPremVersion) e de todos os node pools (nodePools[i].gkeOnPremVersion).

  2. Na versão 1.29 e posteriores, as verificações prévias do lado do servidor estão ativadas por predefinição. Certifique-se de que reveja as regras da firewall para fazer as alterações necessárias.

  3. Para atualizar para a versão 1.28 e posteriores, tem de ativar o kubernetesmetadata.googleapis.com e conceder a função de IAM kubernetesmetadata.publisher à conta de serviço de registo e monitorização. Para ver detalhes, consulte os requisitos da API Google e da IAM.

Faça a atualização

1.31

Use esta sequência especial se o cluster de utilizadores estiver na versão 1.29, o que significa que a versão de destino é 1.31. Esta sequência é necessária porque as regras de versão foram alteradas na versão 1.31.

Quando um cluster de utilizadores está na versão 1.29, um cluster de administrador que gere o cluster de utilizadores pode estar na versão 1.27, 1.28 ou 1.29.

  1. Se o cluster de administrador estiver na versão 1.27, siga os passos para atualizar a estação de trabalho de administrador e atualizar o cluster de administrador para a versão 1.28.

  2. Se o cluster de administração estiver na versão 1.28, siga os passos para atualizar a estação de trabalho de administração e atualizar o cluster de administração para a versão 1.29.

  3. Para poupar 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 utilizadores estiverem na versão 1.29, pode iniciar a atualização de versão de ignorar.

  1. Defina a versão de origem (1.29), uma versão intermédia (1.30) e a versão de destino (1.31) nas seguintes variáveis de marcadores de posição. Todas as versões têm de ser o número da versão completo no formato x.y.z-gke.N, como 1.29.700-gke.110.

    Versão
    Obtenha a versão 1.29 do cluster de utilizadores atual. Esta é a versão de origem. SOURCE_VERSION
    Escolha uma versão intermédia 1.30. INTERMEDIATE_VERSION
    Escolha a versão de destino 1.31. Selecione a correção recomendada da versão secundária 1.31. TARGET_VERSION

  2. Atualize a sua estação de trabalho de administrador para a versão 1.30 intermédia, INTERMEDIATE_VERSION. Aguarde uma mensagem que indique que a atualização foi bem-sucedida.

  3. Instale o pacote correspondente:

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

  4. Atualize novamente a estação de trabalho do administrador, mas desta vez para a versão 1.31 de destinoTARGET_VERSION. Aguarde uma mensagem que indique que a atualização foi bem-sucedida.

  5. Instale o pacote correspondente:

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

  6. Atualize apenas o plano de controlo do cluster de utilizadores para a versão intermédia da seguinte forma:

    1. Faça as seguintes alterações no ficheiro de configuração do cluster de utilizadores:

      • Defina o campo gkeOnPremVersion para a versão intermédia, INTERMEDIATE_VERSION.

      • Defina todas as versões do node pool em nodePools[i].gkeOnPremVersion para a versão de origem, SOURCE_VERSION.

      Depois de atualizar o ficheiro de configuração, este deve ter um aspeto semelhante ao seguinte:

      gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...

    2. Atualize o painel de controlo:

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

      Substitua USER_CLUSTER_CONFIG pelo caminho do ficheiro de configuração do cluster de utilizadores.

  7. Defina o campo bundlePath no ficheiro de configuração do cluster de administrador para a versão 1.30 intermédia do pacote:

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

  8. Atualize o cluster de administrador para a versão 1.30 intermédia:

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

  9. Defina o campo bundlePath no ficheiro de configuração do cluster de administrador para a versão 1.31 de destino do pacote:

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

  10. Upgrade the admin cluster to the target 1.31 version:

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

  11. Atualize o painel de controlo e os node pools para a versão de destino da seguinte forma:

    1. Faça as seguintes alterações no ficheiro de configuração do cluster de utilizadores:

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

      • Defina todos os nodePools[i].gkeOnPremVersion como uma string vazia.

      Depois de atualizar o ficheiro de configuração, este deve ter um aspeto semelhante ao seguinte:

      gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...

    2. Atualize o plano de controlo e os node pools:

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

1,30 e inferior

Use esta sequência se a versão de destino for 1.30 ou inferior.

  1. Defina a versão de origem (1.N), a versão intermédia (1.N+1) e a versão de destino (1.N+2) nas seguintes variáveis de marcadores de posição. Todas as versões têm de ser o número da versão completo no formato x.y.z-gke.N, como 1.16.11-gke.25.

    Versão
    Obtenha a versão atual do cluster. Esta é a versão de origem (1.N). SOURCE_VERSION
    Escolha uma versão intermédia (1.N+1). INTERMEDIATE_VERSION
    Escolha a versão de destino (1.N+2). Selecione o patch recomendado da versão secundária de destino. TARGET_VERSION

  2. Atualize a sua estação de trabalho de administrador para a versão intermédia, INTERMEDIATE_VERSION. Aguarde uma mensagem que indique que a atualização foi bem-sucedida.

  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 ficheiro do cluster de administrador kubeconfig.

  4. Atualize novamente a estação de trabalho do administrador, mas desta vez para a versão de destino, TARGET_VERSION. Aguarde uma mensagem que indique que a atualização foi bem-sucedida.

  5. Instale o pacote correspondente:

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

  6. Atualize apenas o plano de controlo para a versão intermédia da seguinte forma:

    1. Faça as seguintes alterações no ficheiro de configuração do cluster de utilizadores:

      • Defina o campo gkeOnPremVersion para a versão intermédia, INTERMEDIATE_VERSION.

      • Defina todas as versões do node pool em nodePools[i].gkeOnPremVersion para a versão de origem, SOURCE_VERSION.

      Depois de atualizar o ficheiro de configuração, este deve ter um aspeto semelhante ao seguinte:

      gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...

    2. Atualize o painel de controlo:

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

      Substitua USER_CLUSTER_CONFIG pelo caminho do ficheiro de configuração do cluster de utilizadores.

  7. Atualize o painel de controlo e os node pools para a versão de destino da seguinte forma:

    1. Faça as seguintes alterações no ficheiro de configuração do cluster de utilizadores:

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

      • Defina todos os nodePools[i].gkeOnPremVersion como uma string vazia.

      Depois de atualizar o ficheiro de configuração, este deve ter um aspeto semelhante ao seguinte:

      gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...

    2. Atualize o plano de controlo e os node pools:

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

Se não tiver outros clusters de utilizadores para atualizar, remova os pacotes da estação de trabalho de administração para poupar espaço:

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

O que se segue?