Fazer upgrade de clusters

Quando você instala uma nova versão de bmctl, é possível fazer upgrade dos clusters atuais que foram criados com uma versão anterior. O upgrade de um cluster para a versão mais recente do Google Distributed Cloud traz recursos e correções a ele. Isso também garante que o cluster permaneça compatível. É possível fazer upgrade de clusters de administrador, híbridos, autônomos ou de usuário com o comando bmctl upgrade cluster ou usar kubectl.

Para saber mais sobre o processo de upgrade e as regras de controle de versões, consulte Ciclo de vida e estágios dos upgrades de cluster.

Observação: ao fazer upgrade do Google Distributed Cloud de uma versão com um patch de segurança para a próxima versão secundária, recomendamos que você faça upgrade para a versão de patch mais recente disponível para garantir que você tenha os patches de segurança mais recentes. Sempre revise as notas da versão antes de fazer upgrade para se informar sobre o que mudou, incluindo correções de segurança e problemas conhecidos. Não é possível fazer downgrade para uma versão anterior do cluster.

Planeje o upgrade.

Esta seção contém informações e links para informações que você precisa considerar antes de fazer upgrade de um cluster.

Práticas recomendadas

Para informações sobre como se preparar para um upgrade de cluster, consulte Práticas recomendadas para upgrades de cluster do Google Distributed Cloud.

Fazer upgrade das verificações de simulação

As verificações de simulação são executadas como parte do upgrade do cluster para validar o status do cluster e a integridade do nó. O upgrade do cluster não continuará se as verificações de simulação falharem. Para mais informações sobre verificações de simulação, consulte Entender as verificações de simulação.

Verifique se os clusters estão prontos para um upgrade executando a verificação de simulação antes de executar o upgrade. Para mais informações, consulte Verificações de simulação para upgrades.

Problemas conhecidos

Para informações sobre possíveis problemas relacionados a upgrades de cluster, consulte Problemas conhecidos do Google Distributed Cloud para Bare Metal e selecione a categoria de problema Upgrades e atualizações.

Configurar opções de upgrade

Antes de iniciar um upgrade de cluster, é possível configurar as opções de upgrade a seguir que controlam como o processo de upgrade funciona:

• Upgrades seletivos de pools de nós de trabalho: faça upgrade de pools de nós de trabalho específicos separado do restante do cluster.

• Upgrades paralelos: configure o processo de upgrade para fazer upgrade de grupos de nós ou pools de nós ao mesmo tempo.

Essas opções podem reduzir o risco de interrupções em aplicativos e serviços críticos e reduzir de forma significativa o tempo geral de upgrade. Essas opções são muito úteis para clusters grandes com vários nós e pools de nós executando cargas de trabalho importantes. Para mais informações sobre o que essas opções fazem e como usá-las, consulte as seções a seguir.

Upgrades seletivos do pool de nós de trabalho

Por padrão, a operação de upgrade do cluster atualiza todos os nós e pools de nós do cluster. Um upgrade de cluster pode ser disruptivo e demorado, porque resulta na drenagem de cada nó e na reinicialização e reprogramação de todos os pods associados. Nesta seção, descrevemos como incluir ou excluir alguns pools de nós de trabalho em um upgrade de cluster para minimizar a interrupção da carga de trabalho. Esse recurso se aplica apenas a clusters de usuário, híbridos e autônomos, já que os clusters de administrador não permitem pools de nós de trabalho.

É possível usar upgrades seletivos de pools de nós nas seguintes situações:

• Para receber correções de segurança sem interromper as cargas de trabalho: é possível fazer upgrade apenas dos nós do plano de controle (e dos nós do balanceador de carga) para aplicar correções de vulnerabilidades do Kubernetes sem interromper os pools de nós de trabalho.

• Para confirmar a operação adequada de um subconjunto atualizado de nós de trabalho antes de fazer upgrade de todos eles: é possível fazer upgrade dos pools de nós de trabalho de forma seletiva para garantir que as cargas de trabalho sejam executadas corretamente em um pool de nós atualizado antes de fazer upgrade de outro pool.

• Para reduzir a janela de manutenção: o upgrade de um cluster grande pode ser demorado e é difícil prever com precisão quando um upgrade será concluído. O tempo de upgrade do cluster é proporcional ao número de nós que estão sendo atualizados. Reduzir o número de nós que estão sendo atualizados com a exclusão de pools de nós reduz o tempo de upgrade. Você faz upgrade várias vezes, mas as janelas de manutenção menores e mais previsíveis podem ajudar com a programação.

Dois desvios da versão do pool de nós da versão secundária

Para clusters da versão 1.28 e superiores, uma versão do pool de nós de trabalho pode ser até duas versões secundárias atrás da versão do cluster (plano de controle). Com a compatibilidade com a distorção de versão n-2, também é possível pular uma versão de lançamento secundária ao fazer upgrade de um pool de nós de trabalho de duas versões secundárias atrás do cluster para a mesma versão secundária que o cluster.

O suporte a desvio de versão n-2 para pools de nós de trabalho oferece mais flexibilidade para planejar upgrades da frota.

Por exemplo, se você tiver um cluster da versão 1.28, poderá ter pools de nós de trabalho nas versões 1.28, 1.16 e 1.15 selecionadas. Para fazer upgrade do cluster para a versão 1.29, primeiro você precisa fazer o upgrade de qualquer pool de nós de trabalho 1.15 para uma versão compatível do cluster da versão 1.28 anterior ao upgrade. Não é necessário fazer upgrade dos pools de nós de trabalho da versão 1.16 para a versão 1.28 antes de fazer o upgrade do cluster para a versão 1.29. Depois que o cluster for atualizado para a versão 1.29, quando você decidir fazer upgrade dos pools de nós de trabalho da versão 1.16 para a versão 1.29, será possível fazer isso em uma única etapa, ignorando a versão 1.28.

Para mais informações, incluindo listas de versões do pool de nós de trabalho compatíveis com uma determinada versão do cluster, consulte Regras de controle de versão do pool de nós.

1.29

Na versão 1.29, o suporte à distorção da versão n-2 para pools de nós de trabalho está em disponibilidade geral para todos os tipos de cluster. Esse recurso é ativado por padrão para clusters na versão 1.29.

À medida que fazemos a transição desse recurso do Acesso antecipado para a disponibilidade geral, os clusters híbridos ainda exigem a anotação de visualização nas seguintes situações. Se você tiver um cluster híbrido da versão 1.28.x com um pool de nós de trabalho da versão 1.16.y, adicione a anotação preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable ao cluster antes de fazer upgrade para a versão 1.29.z:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.28.400-gke.77
  ...

1.28

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

O suporte a desvio da versão n-2 para pools de nós de trabalho está disponível para Pré-lançamento na versão 1.28. Para ativar esse recurso de pré-visualização, adicione a anotação preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable ao arquivo de configuração do cluster:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
...

Se você não ativar esse recurso em fase de pré-lançamento, a distorção máxima de versão entre um pool de nós de trabalho e o cluster será uma versão secundária.

Para mais informações sobre as regras de controle de versão para o upgrade seletivo de pools de nós de trabalho, consulte Regras de controle de versão do pool de nós em "Ciclo de vida" e nos estágios dos upgrades de cluster.

Fazer upgrade do plano de controle do cluster e dos pools de nós selecionados

Para fazer upgrade seletivo de pools de nós de trabalho no upgrade inicial do cluster:

1. Para os pools de nós de trabalho que você quer incluir no upgrade do cluster, faça uma das seguintes alterações na especificação NodePool:

   • Defina anthosBareMetalVersion na especificação NodePool como a versão de upgrade do destino do cluster.
   • Omita o campo anthosBareMetalVersion da especificação NodePool ou defina-o como uma string vazia. Por padrão, os pools de nós de trabalho são incluídos nos upgrades do cluster.

2. Para os pools de nós de trabalho que você quer excluir do upgrade, defina anthosBareMetalVersion como a versão atual (pré-upgrade) do cluster:

3. Continue com o upgrade conforme descrito em Iniciar o upgrade do cluster.

   A operação de upgrade do cluster faz upgrade dos seguintes nós:

   • Nós do plano de controle do cluster.
   • Pool de nós do balanceador de carga, se o cluster usar um (spec.loadBalancer.nodePoolSpec). Por padrão, os nós do balanceador de carga podem executar cargas de trabalho regulares. Não é possível fazer upgrade seletivo de um pool de nós do balanceador de carga. Ele está sempre incluído no upgrade inicial do cluster.
   • Pools de nós de trabalho que não foram excluídos do upgrade.

Por exemplo, suponha que o cluster esteja na versão 1.28.0 e tenha dois pools de nós de trabalho: wpool01 e wpool02. Suponha também que você queira fazer upgrade do plano de controle e do wpool01 para 1.29.100-gke.251, mas quer que wpool02 permaneça na versão 1.28.0.

O trecho do arquivo de configuração de cluster a seguir mostra como modificar a configuração para aceitar esse upgrade parcial:

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.100-gke.251
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.28.0
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

Fazer upgrade dos pools de nós para a versão atual do cluster

Se você excluiu pools de nós de um upgrade de cluster, pode executar um upgrade de cluster que os atualize para a versão do cluster de destino. Os pools de nós de trabalho que foram excluídos de um upgrade de cluster têm o campo anthosBareMetalVersion na especificação NodePool definida como a versão anterior (pré-upgrade).

Para atualizar os pools de nós de trabalho para a versão atual com upgrade feito do cluster:

1. Edite as especificações NodePool no arquivo de configuração do cluster para os pools de nós de trabalho que você quer atualizar para a versão atual do cluster. Defina anthosBareMetalVersion como a versão atual do cluster (pós-upgrade).

   Se vários pools de nós de trabalho forem selecionados para upgrade, o valor de spec.nodePoolUpgradeStrategy.concurrentNodePools na especificação do cluster vai determinar quantos pools de nós vão ser atualizados em paralelo, se houver. Se você não quiser fazer upgrade dos pools de nós de trabalho ao mesmo tempo, selecione um pool de cada vez.

2. Continue com o upgrade conforme descrito em Iniciar o upgrade do cluster.

   A operação de upgrade do cluster faz upgrade apenas dos pools de nós de trabalho excluídos antes para os quais você definiu anthosBareMetalVersion para a versão atual com upgrade feito do cluster.

Por exemplo, suponha que você fez upgrade do cluster para a versão 1.29.100-gke.251, mas o pool de nós wpool02 ainda está na versão 1.28.0 antiga do cluster anterior ao upgrade. As cargas de trabalho estão sendo executadas da maneira correta no pool de nós atualizado, wpool01, então agora você também quer trazer wpool02 para a versão atual do cluster. Para fazer upgrade de wpool02, remova o campo anthosBareMetalVersion ou defina o valor como a string vazia.

O trecho do arquivo de configuração de cluster a seguir mostra como modificar a configuração para aceitar esse upgrade parcial:

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.100-gke.251
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: ""
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

Reverter um upgrade do pool de nós

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Há muitas dependências, como compatibilidade com kubelet ou plug-ins, que podem afetar o desempenho das cargas de trabalho. Caso você encontre um problema depois de fazer upgrade de um pool de nós de trabalho, reverta o pool de nós para a versão anterior dele.

O recurso de reversão do pool de nós está disponível para pré-lançamento nos clusters da versão 1.29 (clusters com nós do plano de controle na versão 1.29). Enquanto esse recurso estiver em Pré-lançamento, você precisará adicionar a anotação preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable ao recurso Cluster para ativá-lo.

Para reverter um upgrade de pool de nós, siga estas etapas:

bmctl

Ao usar bmctl para reverter um upgrade de pool de nós, edite o arquivo de configuração do cluster e aplique as alterações com o comando bmctl update:

1. Edite as especificações NodePool no arquivo de configuração do cluster para os pools de nós de worker que você quer reverter para a versão anterior. Defina anthosBareMetalVersion como a versão anterior do cluster (pré-upgrade).

   ...
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: NodePool
   metadata:
     name: wpool01
     namespace: cluster-user001
   spec:
     clusterName: user001
     anthosBareMetalVersion: 1.28.500-gke.120
     nodes:
     - address:  10.200.0.1
     - address:  10.200.0.2
     - address:  10.200.0.3
     ...
   

   Se vários pools de nós de trabalho forem selecionados para reversão, o valor de spec.nodePoolUpgradeStrategy.concurrentNodePools na especificação do cluster determinará quantos pools de nós serão revertidos em paralelo. Se você não quiser reverter os pools de nós de trabalho simultaneamente, selecione um pool de nós por vez para reverter ou atualize as configurações de nodePoolUpgradeStrategy. Da mesma forma, o valor de spec.upgradeStrategy.parallelUpgrade.concurrentNodes na especificação NodePool determina quantos nós são revertidos em paralelo.

2. Use bmctl update para aplicar as mudanças nas especificações de NodePool:

   bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
   

   Substitua:

   • CLUSTER_NAME: o nome do cluster que você quer atualizar.

   • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de gerenciamento (administrador, híbrido ou autônomo).

   A reversão começa automaticamente.

3. Conforme a reversão é executada, o Google Distributed Cloud realiza as seguintes atividades para cada nó:

   • Colocar o nó no modo de manutenção.
   • Execute um job de redefinição no nó para trazê-lo para um estado limpo.
   • Execute verificações de simulação da máquina no nó.
   • Execute um job de inicialização de máquina no nó para reinstalá-lo na versão de reversão de destino (pré-upgrade).
   • Remova o nó do modo de manutenção.

   No final de uma reversão bem-sucedida, o valor de nodePool.status.anthosBareMetalVersion no recurso NodePool será definido como a versão da reversão de destino.

Não use bmctl update e kubectl apply -f alternadamente ao editar o arquivo de configuração do cluster. Quando esses comandos são usados alternadamente, o conteúdo preenchido pelo cabeçalho da especificação do cluster pode ser removido acidentalmente. Por exemplo, é possível usar bmctl update para atualizar o arquivo de configuração do cluster e configurar um espelho de registro. O cluster terá spec.nodeConfig.registryMirrors preenchido após a reconciliação.

Se você tentar fazer alterações no cluster usando a configuração do cluster com o comando kubectl apply -f, o spec.nodeConfig.registryMirrors preenchido pelo reconciliador no cluster será removido. Esse comportamento acontece porque a configuração não existe na especificação de configuração do cluster, mas sim no cluster.

kubectl

É possível reverter um upgrade de pool de nós usando kubectl para editar o recurso NodePool diretamente:

1. Para reverter um pool de nós de trabalho, abra o recurso NodePool para edição:

   kubectl edit nodepool NODE_POOL_NAME \
       --namespace CLUSTER_NAMESPACE \
       --kubeconfig ADMIN_KUBECONFIG
   

   Substitua:

   • NODE_POOL_NAME: o nome do pool de nós que você está revertendo.

   • CLUSTER_NAMESPACE: o nome do namespace em que o pool de nós é implantado. Esse é o namespace do cluster.

   • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de gerenciamento (administrador, híbrido ou autônomo).

2. Altere o valor de spec.anthosBareMetalVersion para a versão anterior (pré-upgrade).

   ...
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: NodePool
   metadata:
     name: wpool01
     namespace: cluster-user001
   spec:
     clusterName: user001
     anthosBareMetalVersion: 1.28.500-gke.120
     nodes:
     - address:  10.200.0.1
     - address:  10.200.0.2
     - address:  10.200.0.3
     ...
   

3. Salve e feche o recurso NodePool no editor.

   A reversão começa automaticamente.

4. Conforme a reversão é executada, o Google Distributed Cloud realiza as seguintes atividades para cada nó:

   • Colocar o nó no modo de manutenção.
   • Execute um job de redefinição no nó para trazê-lo para um estado limpo.
   • Execute verificações de simulação da máquina no nó.
   • Execute um job de inicialização de máquina no nó para reinstalá-lo na versão de reversão de destino (pré-upgrade).
   • Remova o nó do modo de manutenção.

   No final de uma reversão bem-sucedida, o valor de nodePool.status.anthosBareMetalVersion no recurso NodePool será definido como a versão da reversão de destino.

Upgrades paralelos

Em upgrades de clusters padrão típicos, o upgrade de cada nó de cluster é feito em sequência, um após o outro. Nesta seção, mostramos como configurar seu cluster e os pools de nós de trabalho para que vários nós façam upgrade em paralelo quando você fizer upgrade do cluster. O upgrade de nós em paralelo acelera significativamente os upgrades do cluster, sobretudo em clusters com centenas de nós.

Cuidado: se você usa serviços de dados gerenciados, como o Portworx, para ajudar a gerenciar cargas de trabalho com estado nos clusters, recomendamos não usar upgrades em paralelo

.

Há duas estratégias de upgrade paralelas que podem ser usadas para acelerar o upgrade do cluster:

• Upgrade de nó simultâneo: é possível configurar seus pools de nós de trabalho para que vários nós façam upgrade em paralelo. Os upgrades paralelos de nós são configurados na especificação do NodePool (spec.upgradeStrategy.parallelUpgrade) e somente os nós em um pool de nós de trabalho podem ser atualizados em paralelo. Só é possível fazer upgrade de um nó em planos de controle ou pools de nós do balanceador de carga de cada vez. Para mais informações, consulte Estratégia de upgrade de nó.

• Upgrade de pool de nós simultâneo: é possível configurar o cluster para que vários pools de nós façam upgrade em paralelo. Somente os pools de nós de trabalho podem ser atualizados em paralelo. Só é possível fazer upgrade de um pool de nós do plano de controle e do balanceador de carga por vez.

Estratégia de upgrade de nós

É possível configurar pools de nós de trabalho para que vários nós sejam atualizados simultaneamente (concurrentNodes). Também é possível definir um limite mínimo para o número de nós que podem executar cargas de trabalho durante todo o processo de upgrade (minimumAvailableNodes). Essa configuração é feita na especificação do NodePool. Para mais informações sobre esses campos, consulte a referência do campo de configuração do cluster.

Importante: Os upgrades paralelos não respeitam o orçamento de interrupção de pods (PDB, na sigla em inglês). Se as cargas de trabalho forem sensíveis a interrupções, recomendamos usar o campo minimumAvailableNodes. É possível especificar a quantidade mínima de nós que precisam permanecer disponíveis para executar cargas de trabalho durante o processo de upgrade.

A estratégia de upgrade de nós se aplica apenas a pools de nós de trabalho. Não é possível especificar uma estratégia de upgrade de nós para pools de nós do plano de controle ou do balanceador de carga. Durante um upgrade de cluster, os nós nos pools do plano de controle e do balanceador de carga fazem upgrade sequencialmente. Os pools de nós do plano de controle e os pools de nós do balanceador de carga são especificados na especificação do cluster (controlPlane.nodePoolSpec.nodes e loadBalancer.nodePoolSpec.nodes).

Ao configurar upgrades paralelos para nós, observe as seguintes restrições:

• O valor de concurrentNodes não pode exceder 50% do número de nós no pool de nós ou o número fixo 15, o que for menor. Por exemplo, se o pool de nós tem 20 nós, não é possível especificar um valor maior que 10. Se o pool de nós tem 100 nós, 15 é o valor máximo que pode ser especificado.

• Quando você usa concurrentNodes com minimumAvailableNodes, os valores combinados não podem exceder o número total de nós no pool de nós. Por exemplo, se o pool de nós tem 20 nós e minimumAvailableNodes está definido com 18, concurrentNodes não pode exceder 2. Da mesma forma, se concurrentNodes estiver definido como 10, minimumAvailableNodes não poderá exceder 10.

O exemplo a seguir mostra um pool de nós de trabalho np1 com 10 nós. Em um upgrade, os nós fazem upgrade de cinco por vez, e pelo menos quatro nós precisam permanecer disponíveis para que o upgrade continue:

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  - address:  10.200.0.4
  - address:  10.200.0.5
  - address:  10.200.0.6
  - address:  10.200.0.7
  - address:  10.200.0.8
  - address:  10.200.0.9
  - address:  10.200.0.10 
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 4 

Estratégia de upgrade do pool de nós

É possível configurar um cluster para fazer o upgrade em paralelo de vários pools de nós de trabalho. O campo booleano nodePoolUpgradeStrategy.concurrentNodePools na especificação do cluster especifica se é necessário fazer upgrade de todos os pools de nós de trabalho de um cluster simultaneamente. Por padrão (1), os pools de nós são atualizados sequencialmente, um após o outro. Quando você define concurrentNodePools como 0, os upgrades de todos os pools de nós de trabalho no cluster são feitos em paralelo.

O plano de controle e os pools de nós de balanceamento de carga não são afetados por essa configuração. Esses pools de nós sempre fazem upgrade sequencialmente, um por vez. Os pools de nós do plano de controle e os pools de nós do balanceador de carga são especificados na especificação do cluster (controlPlane.nodePoolSpec.nodes e loadBalancer.nodePoolSpec.nodes).

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

Como fazer um upgrade paralelo

Nesta seção, descrevemos como configurar um cluster e um pool de nós de trabalho para upgrades paralelos.

Para executar um upgrade paralelo de pools de nós de trabalho e nós em um pool de nós de trabalho, faça o seguinte:

1. Adicione uma seção upgradeStrategy à especificação do NodePool.

   Você pode aplicar esse manifesto separadamente ou como parte do arquivo de configuração do cluster ao realizar uma atualização de cluster.

   Veja um exemplo:

   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: NodePool
   metadata:
     name: np1
     namespace: cluster-ci-bf8b9aa43c16c47
   spec:
     clusterName: ci-bf8b9aa43c16c47
     nodes:
     - address:  10.200.0.1
     - address:  10.200.0.2
     - address:  10.200.0.3
     ...
     - address:  10.200.0.30
     upgradeStrategy:
       parallelUpgrade:
         concurrentNodes: 5
         minimumAvailableNodes: 10
   

   Neste exemplo, o valor do campo concurrentNodes é 5, o que significa que cinco nós farão upgrade em paralelo. O campo minimumAvailableNodes está definido como 10, o que significa que pelo menos 10 nós precisam permanecer disponíveis para cargas de trabalho durante o upgrade.

   Observação: não é possível especificar uma estratégia de upgrade de nó para um plano de controle ou pools de nós do balanceador de carga.

2. Adicione uma seção nodePoolUpgradeStrategy à especificação do cluster no arquivo de configuração do cluster.

   ---
   apiVersion: v1
   kind: Namespace
   metadata:
     name: cluster-user001
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: user001
     namespace: cluster-user001
   spec:
     type: user
     profile: default
     anthosBareMetalVersion: 1.29.100-gke.251
     ...
     nodePoolUpgradeStrategy:
       concurrentNodePools: 0
     ...
   

   Neste exemplo, o campo concurrentNodePools está definido como 0, o que significa que todos os pools de nós de trabalho são atualizados simultaneamente durante o upgrade do cluster. A estratégia de upgrade dos nós nos pools é definida nas especificações do NodePool.

3. Faça upgrade do cluster conforme descrito na seção anterior Upgrade de clusters administrativos, independentes, híbridos ou de usuário.

Valores padrão do upgrade paralelo

Os upgrades paralelos estão desativados por padrão, e os campos relacionados a eles são mutáveis. Você pode remover os campos ou defini-los como valores padrão a qualquer momento para desativar o recurso antes de um upgrade subsequente.

A tabela a seguir lista os campos de upgrade paralelos e os valores padrão:

Campo	Valor padrão	Significado
(Especificação de cluster) nodePoolUpgradeStrategy.concurrentNodePools	1	Faça upgrade dos pools de nós de trabalho sequencialmente, um após o outro.
(Especificação do NodePool) upgradeStrategy.parallelUpgrade.concurrentNodes	1	Faça upgrade dos nós sequencialmente, um após o outro.
(Especificação do NodePool) upgradeStrategy.parallelUpgrade.minimumAvailableNodes	O valor padrão de minimumAvailableNodes depende do valor de concurrentNodes. Se você não especificar concurrentNodes, minimumAvailableNodes por padrão será 2/3 do tamanho do pool de nós. Se você especificar concurrentNodes, minimumAvailableNodes por padrão será o tamanho do pool de nós menos concurrentNodes.	O upgrade é interrompido quando minimumAvailableNodes é atingido e só continua quando o número de nós disponíveis é maior que minimumAvailableNodes.

Iniciar o upgrade do cluster

Esta seção contém instruções para fazer upgrade de clusters.

Observação: é necessário fazer o upgrade de um cluster de administrador antes de fazer upgrade de clusters de usuários associados. No entanto, antes de fazer upgrade do cluster de administrador para 1.29.100-gke.251, verifique se os clusters de usuário associados estão na versão 1.28.0 ou mais recente. bmctl emite um erro quando descobre que algum cluster de usuário tem uma versão anterior a 1.28.0.

bmctl

Ao fazer o download e instalar uma nova versão do bmctl, é possível fazer o upgrade dos clusters de administrador, híbridos, autônomos e de usuários criados com uma versão anterior. Para uma determinada versão de bmctl, um cluster só pode ser atualizado para a mesma versão.

1. Faça o download do bmctl mais recente conforme descrito nos downloads do Google Distributed Cloud.

2. Atualize anthosBareMetalVersion no arquivo de configuração do cluster para a versão de destino do upgrade.

   A versão de destino do upgrade precisa corresponder à versão do arquivo bmctl transferido por download. O snippet de arquivo de configuração do cluster a seguir mostra o campo anthosBareMetalVersion atualizado para a versão mais recente:

   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: cluster1
     namespace: cluster-cluster1
   spec:
     type: admin
     # Anthos cluster version.
     anthosBareMetalVersion: 1.29.100-gke.251
   

3. Use o comando bmctl upgrade cluster para concluir o upgrade:

   bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

   Substitua:

   • CLUSTER_NAME: o nome do cluster a se fazer upgrade.
   • ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.

   A operação de upgrade do cluster executa verificações de simulação para validar o status do cluster e a integridade do nó. O upgrade do cluster não continuará se as verificações de simulação falharem. Para informações sobre solução de problemas, consulte Resolver problemas de upgrade ou instalação de cluster.

   Quando todos os componentes do cluster tiverem sido atualizados, a operação de upgrade do cluster realizará verificações de integridade. Essa última etapa verifica se o cluster está em boas condições operacionais. Se o cluster não for aprovado em todas as verificações de integridade, eles continuarão em execução até serem aprovados. Quando todas as verificações de integridade forem aprovadas, o upgrade será concluído.

   Para mais informações sobre a sequência de eventos para upgrades de cluster, consulte Ciclo de vida e etapas dos upgrades de cluster.

kubectl

Para fazer upgrade de um cluster com o kubectl, siga estas etapas:

1. Edite o arquivo de configuração do cluster para definir anthosBareMetalVersion como a versão de destino do upgrade.

2. Para iniciar o upgrade, execute o seguinte comando:

   kubectl apply -f CLUSTER_CONFIG_PATH
   

   Substitua CLUSTER_CONFIG_PATH pelo caminho do arquivo de configuração do cluster editado.

   Assim como no processo de upgrade com bmctl, as verificações de simulação são executadas como parte do upgrade do cluster para validar o status do cluster e a integridade do nó. Se as verificações de simulação falharem, o upgrade do cluster será interrompido. Para solucionar falhas, examine o cluster e os registros relacionados, já que nenhum cluster de inicialização foi criado. Para mais informações, consulte Resolver problemas de instalação ou upgrade de cluster.

Embora você não precise da versão mais recente do bmctl para fazer upgrade com kubectl , recomendamos que faça o download do bmctl mais recente. Você precisa de bmctl para executar outras tarefas, como verificações de integridade e backups, garantindo que o cluster continue em ordem.

Pausar e retomar upgrades

O recurso de pausa e retomada de upgrade permite pausar um upgrade de cluster antes que ele seja concluído. Quando um upgrade de cluster é pausado, nenhum upgrade de nó de trabalho novo é acionado até que o upgrade seja retomado.

Esse recurso está disponível em pré-lançamento para clusters com todos os nós do plano de controle na versão secundária 1.28 ou mais recente. O recurso está disponível para clusters com todos os nós do plano de controle na versão secundária 1.29 ou mais recente.

É possível pausar um upgrade pelos seguintes motivos:

• Você detectou algo errado com as cargas de trabalho do cluster durante o upgrade e quer pausar o upgrade

• Você tem janelas de manutenção curtas, então quer pausar o upgrade entre elas

Enquanto um upgrade de cluster está pausado, as seguintes operações são suportadas:

• Como adicionar ou remover nós
• Como adicionar ou remover pools de nós
• Aumentar o intervalo da rede de serviços
• Restaurar um cluster de um backup

Quando um novo nó é adicionado enquanto um upgrade está pausado, os jobs de verificação da máquina não são executados nele até que o upgrade seja retomado e concluído.

Enquanto o upgrade do cluster estiver pausado, as seguintes operações de cluster não serão aceitas:

• Rotação de autoridades certificadoras
• Como fazer backup de um cluster

Não é possível iniciar um novo upgrade de cluster enquanto um upgrade de cluster ativo está pausado.

Ativar pausa e retomada do upgrade

Google Distributed Cloud 1.29

O recurso de pausa e retomada de upgrade é ativado por padrão para clusters com todos os nós do plano de controle na versão secundária 1.29 ou mais recente.

Google Distributed Cloud 1.28

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Enquanto o recurso de pausa e retomada do upgrade estiver em pré-lançamento, ele poderá ser ativado com uma anotação no recurso do cluster.

Para ativar a pausa e retomar o upgrade, siga estas etapas:

1. Adicione a anotação preview.baremetal.cluster.gke.io/upgrade-pause-and-resume ao arquivo de configuração do cluster:

   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: baremetal-demo
     namespace: cluster-baremetal-demo
     annotations:
       preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
   spec:
   ...
   

2. Para aplicar a alteração, atualize o cluster:

   bmctl update CLUSTER_NAME
   

   O campo nodePoolUpgradeStrategy.pause é mutável. Você pode adicionar e atualizar essas informações a qualquer momento.

Pausar um upgrade

Pause um upgrade de cluster definindo nodePoolUpgradeStrategy.pause como true na especificação do cluster.

Para pausar um upgrade de cluster ativo, siga estas etapas:

1. Adicione nodePoolUpgradeStrategy.pause ao arquivo de configuração do cluster e defina-o como true:

   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: baremetal-demo
     namespace: cluster-baremetal-demo
     ...
   spec:
     ...
     nodePoolUpgradeStrategy:
       pause: true
     ...
   

   Se você usou bmctl para iniciar o upgrade, será necessária uma nova janela de terminal para executar a próxima etapa.

2. Para aplicar a alteração, atualize o cluster:

   bmctl update CLUSTER_NAME
   

   A operação de upgrade está pausada. Nenhum upgrade de nó novo é acionado.

3. Se você usou bmctl para iniciar o upgrade e está planejando uma pausa longa, pressione Control+C para sair do bmctl. Caso contrário, mantenha bmctl em execução.

   A CLI bmctl não detecta mudanças no status de pausa do upgrade, portanto, não fecha automaticamente. No entanto, quando você sai do bmctl, ele para de registrar o progresso do upgrade para o arquivo de registro cluster-upgrade-TIMESTAMP na pasta do cluster na estação de trabalho do administrador e para o Cloud Logging. Portanto, para pausas curtas, é recomendável manter o bmctl em execução. Se você deixar bmctl em execução por um período prolongado enquanto o upgrade estiver pausado, ele vai expirar.

Retomar um upgrade pausado

Para retomar um upgrade de cluster pausado, defina nodePoolUpgradeStrategy.pause como false na especificação do cluster ou remova nodePoolUpgradeStrategy.pause dela.

Para retomar um upgrade de cluster que foi pausado, siga estas etapas:

1. Defina nodePoolUpgradeStrategy.pause como o arquivo de configuração do cluster e como false:

   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: baremetal-demo
     namespace: cluster-baremetal-demo
     ...
   spec:
     ...
     nodePoolUpgradeStrategy:
       pause: false
     ...
   

   Se preferir, remova o campo pause, porque o padrão é false.

2. Para aplicar a alteração, atualize o cluster:

   bmctl update CLUSTER_NAME
   

   A operação de upgrade é retomada de onde parou.

3. Para verificar o status do upgrade, primeiro acesse uma lista dos recursos que têm anthosBareMetalVersion no status:

   kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces
   

   Substitua:

   • RESOURCE: o nome do recurso que você quer receber. Os recursos Cluster, NodePool e BareMetalMachine contêm informações de status anthosBareMetalVersion.

   • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.

   O exemplo a seguir mostra o formato da resposta para recursos personalizados BareMetalMachine. Cada BareMetalMachine corresponde a um nó do cluster.

   NAMESPACE              NAME         CLUSTER        READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
   cluster-nuc-admin001   192.0.2.52   nuc-admin001   true    baremetal://192.0.2.52   192.0.2.52   1.28.0        1.28.0
   cluster-nuc-user001    192.0.2.53   nuc-user001    true    baremetal://192.0.2.53   192.0.2.53   1.16.2        1.16.2
   cluster-nuc-user001    192.0.2.54   nuc-user001    true    baremetal://192.0.2.54   192.0.2.54   1.16.2        1.16.2
   

4. Para verificar a status.anthosBareMetalVersion (versão atual do recurso), recupere detalhes de recursos individuais:

   kubectl describe RESOURCE RESOURCE_NAME \
       --kubeconfig ADMIN_KUBECONFIG \
       --namespace CLUSTER_NAMESPACE
   

   O exemplo a seguir mostra os detalhes de BareMetalMachine para o nó do cluster com o endereço IP 192.0.2.53:

   Name:         192.0.2.53
   Namespace:    cluster-nuc-user001
   ...
   API Version:  infrastructure.baremetal.cluster.gke.io/v1
   Kind:         BareMetalMachine
   Metadata:
     Creation Timestamp:  2023-09-22T17:52:09Z
     ...
   Spec:
     Address:                    192.0.2.53
     Anthos Bare Metal Version:  1.16.2
     ...
   Status:
     Anthos Bare Metal Version:  1.16.2
   

   Neste exemplo, o nó está na versão 1.16.2 do Google Distributed Cloud.