Atualize clusters

Quando instala uma nova versão do bmctl, pode atualizar os clusters existentes que foram criados com uma versão anterior. A atualização de um cluster para a versão mais recente do Google Distributed Cloud traz funcionalidades adicionais e correções ao seu cluster. Também garante que o cluster permanece suportado. Pode atualizar clusters de administrador, híbridos, autónomos ou de utilizadores com o comando bmctl upgrade cluster ou pode usar kubectl.

Para saber mais sobre o processo de atualização e as regras de controlo de versões, consulte o artigo Ciclo de vida e fases das atualizações de clusters.

Esta página destina-se a administradores, arquitetos 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 que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Google Cloud

Planeie a atualização

Esta secção contém informações e links para informações que deve considerar antes de atualizar um cluster. Para mais informações sobre atualizações, incluindo regras de controlo de versões para clusters e conjuntos de nós, consulte o artigo Ciclo de vida e fases das atualizações de clusters.

Práticas recomendadas

Para obter informações que ajudam a preparar-se para uma atualização do cluster, consulte o artigo Práticas recomendadas para atualizações de clusters do Google Distributed Cloud.

Verificações prévias de atualização

As verificações pré-voo são executadas como parte da atualização do cluster para validar o estado do cluster e o estado dos nós. A atualização do cluster não prossegue se as verificações preliminares falharem. Para mais informações sobre as verificações prévias, consulte o artigo Compreenda as verificações prévias.

Pode verificar se os clusters estão prontos para uma atualização executando a verificação prévia antes de executar a atualização. Para mais informações, consulte o artigo Verificações pré-voo para atualizações.

Problemas conhecidos

Para obter informações sobre potenciais problemas relacionados com atualizações de clusters, consulte os problemas conhecidos do Google Distributed Cloud para bare metal e selecione a categoria de problemas Atualizações.

Configure as opções de atualização

Antes de iniciar uma atualização do cluster, pode configurar as seguintes opções de atualização que controlam o funcionamento do processo de atualização:

Estas opções podem reduzir o risco de interrupções nas aplicações e nos serviços críticos, bem como reduzir significativamente o tempo de atualização geral. Estas opções são especialmente úteis para grandes clusters com vários nós e conjuntos de nós que executam cargas de trabalho importantes. Para mais informações sobre o que estas opções fazem e como as usar, consulte as secções seguintes.

Atualizações seletivas do node pool de nós trabalhadores

Por predefinição, a operação de atualização do cluster atualiza todos os nós e node pools no cluster. Uma atualização do cluster pode ser disruptiva e demorada, uma vez que resulta na drenagem de cada nó e no reinício e reagendamento de todos os pods associados. Esta secção descreve como pode incluir ou excluir determinados grupos de nós de trabalho para uma atualização do cluster de modo a minimizar a interrupção da carga de trabalho. Esta funcionalidade aplica-se apenas a clusters de utilizador, híbridos e autónomos, uma vez que os clusters de administrador não permitem conjuntos de nós de trabalho.

Pode usar atualizações seletivas do conjunto de nós nas seguintes situações:

  • Para receber correções de segurança sem interromper as cargas de trabalho: pode atualizar apenas os nós do plano de controlo (e os nós do balanceador de carga) para aplicar correções de vulnerabilidades do Kubernetes sem interromper os seus pools de nós de trabalho.

  • Para confirmar o funcionamento adequado de um subconjunto atualizado de nós de trabalho antes de atualizar todos os nós de trabalho: pode atualizar os seus conjuntos de nós de trabalho seletivamente para garantir que as cargas de trabalho estão a ser executadas corretamente num conjunto de nós atualizado antes de atualizar outro conjunto de nós.

  • Para reduzir o período de manutenção: a atualização de um cluster grande pode demorar muito tempo e é difícil prever com precisão quando uma atualização vai ser concluída. O tempo de atualização do cluster é proporcional ao número de nós que estão a ser atualizados. Reduzir o número de nós que estão a ser atualizados excluindo os grupos de nós reduz o tempo de atualização. Faz atualizações várias vezes, mas os períodos de manutenção mais pequenos e previsíveis podem ajudar com o agendamento.

Diferença de versão do conjunto de nós de duas versões secundárias

Para clusters com a versão 1.28 e superior, a versão de um conjunto de nós de trabalho pode estar até duas versões secundárias atrás da versão do cluster (plano de controlo). Com o suporte de desvio de versão n-2, também pode ignorar uma versão de lançamento secundária quando atualiza um conjunto de nós de trabalho de duas versões secundárias anteriores ao cluster para a mesma versão secundária do cluster.

Este suporte de desvio da versão n-2 para pools de nós de trabalho oferece-lhe mais flexibilidade para planear as atualizações da sua frota.

Por exemplo, se tiver um cluster da versão 1.33, pode ter pools de nós de trabalho nas versões 1.33, 1.32 e 1.31 selecionadas.

Antes de poder atualizar um cluster, todos os conjuntos de nós de trabalho têm de estar numa versão compatível com a versão atual do cluster e a versão de destino do cluster.

Por exemplo, se tiver um cluster na versão 1.29 e pools de nós de trabalho na versão 1.29, na versão 1.28 e na versão 1.16, tem de atualizar os pools de nós da versão 1.16 para a versão 1.28 ou 1.29 antes de poder atualizar o cluster para a versão 1.30.

Para mais informações, incluindo listas de versões de pools de nós de trabalho suportadas por uma determinada versão do cluster (aplicável à versão 1.29 e anteriores), consulte o artigo Regras de controlo de versões de pools de nós

1,30

Na versão 1.30, o suporte de variação da versão n-2 para pools de nós de trabalho está disponível para todos os tipos de clusters. Esta funcionalidade está ativada por predefinição para clusters na versão 1.30.

Os conjuntos de nós em qualquer versão de patch das versões secundárias 1.28 e 1.29 podem ser atualizados para qualquer versão de patch da versão 1.30, se a versão do conjunto de nós for igual ou inferior à versão do cluster.

1,29

Na versão 1.29, o suporte de variação da versão n-2 para pools de nós de trabalho está disponível para todos os tipos de clusters. Esta funcionalidade está ativada por predefinição para clusters na versão 1.29.

À medida que fazemos a transição desta funcionalidade da Pré-visualização pública para a disponibilidade geral, os clusters híbridos continuam a exigir a anotação de pré-visualização na seguinte situação. Se tiver um cluster híbrido da versão 1.28.x com um conjunto de nós de trabalho da versão 1.16.y, tem de adicionar a anotação preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable ao cluster antes de o atualizar 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

O suporte de variação da versão n-2 para pools de nós de trabalho está disponível para pré-visualização na versão 1.28. Para ativar esta capacidade de pré-visualização, adicione a anotação preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable ao ficheiro 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 não ativar esta capacidade de pré-visualização, a diferença máxima entre a versão de um conjunto de nós de trabalho e o cluster é de uma versão secundária.

Para mais informações sobre as regras de controlo de versões para atualizar seletivamente os conjuntos de nós de trabalho, consulte as Regras de controlo de versões do conjunto de nós em Ciclo de vida e fases das atualizações do cluster.

Atualize o painel de controlo do cluster e os node pools selecionados

Para atualizar seletivamente os node pools de nós de trabalho na atualização inicial do cluster:

  1. Para os conjuntos de nós de trabalho que quer incluir na atualização do cluster, faça uma das seguintes alterações à especificação NodePool:

    • Defina anthosBareMetalVersion na especificação NodePool para a versão de atualização de destino do cluster.
    • Omita o campo anthosBareMetalVersion da especificação NodePool ou defina-o como a string vazia. Por predefinição, os conjuntos de nós de trabalho estão incluídos nas atualizações de clusters.

  2. Para os conjuntos de nós de trabalho que quer excluir da atualização, defina anthosBareMetalVersion para a versão atual (pré-atualização) do cluster:

  3. Continue com a atualização conforme descrito em Inicie a atualização do cluster.

    A operação de atualização do cluster atualiza os seguintes nós:

    • Nós do plano de controlo do cluster.
    • Pool de nós do balanceador de carga, se o cluster usar um (spec.loadBalancer.nodePoolSpec). Por predefinição, os nós do balanceador de carga podem executar cargas de trabalho normais. Não pode atualizar seletivamente um conjunto de nós do equilibrador de carga. Este está sempre incluído na atualização inicial do cluster.
    • Grupos de nós de trabalho que não excluiu da atualização.

Por exemplo, suponhamos que o seu cluster está na versão 1.32.0 e tem dois node pools de trabalho: wpool01 e wpool02. Suponhamos também que quer atualizar o plano de controlo e o wpool01 para a versão 1.33.0-gke.799, mas quer que o wpool02 permaneça na versão 1.32.0.

O excerto do ficheiro de configuração do cluster seguinte mostra como pode modificar a configuração do cluster para suportar esta atualização parcial:

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.33.0-gke.799
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.33.0-gke.799
  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.32.0
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

Atualize os node pools para a versão atual do cluster

Se excluiu node pools de uma atualização do cluster, pode executar uma atualização do cluster que os atualiza para a versão do cluster de destino. Os node pools de trabalhadores que foram excluídos de uma atualização do cluster têm o campo anthosBareMetalVersion na respetiva especificação NodePool definido para a versão anterior (pré-atualização) do cluster.

Para atualizar os node pools de nós de trabalho para a versão atualizada do cluster:

  1. Edite as NodePoolespecificações no ficheiro de configuração do cluster para os conjuntos de nós de trabalho que quer atualizar para a versão atual do cluster. Defina anthosBareMetalVersion para a versão atual do cluster (após a atualização).

    Se forem selecionados vários conjuntos de nós de trabalho para atualização, o valor de spec.nodePoolUpgradeStrategy.concurrentNodePools na especificação do cluster determina quantos conjuntos de nós são atualizados em paralelo, se houver. Se não quiser atualizar os conjuntos de nós de trabalho em simultâneo, selecione um conjunto de nós de cada vez para a atualização.

  2. Continue com a atualização conforme descrito em Inicie a atualização do cluster.

    A operação de atualização do cluster atualiza apenas os node pools de trabalho excluídos anteriormente para os quais definiu anthosBareMetalVersion para a versão atual do cluster atualizado.

Por exemplo, suponhamos que atualizou o cluster para a versão 1.33.0-gke.799, mas o conjunto de nós wpool02 ainda está na versão 1.32.0 do cluster anterior à atualização. As cargas de trabalho estão a ser executadas corretamente no node pool atualizado, wpool01, por isso, agora, também quer atualizar wpool02 para a versão atual do cluster. Para atualizar wpool02, pode remover o campo anthosBareMetalVersion ou definir o respetivo valor como a string vazia.

O excerto do ficheiro de configuração do cluster seguinte mostra como pode modificar a configuração do cluster para suportar esta atualização parcial:

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.33.0-gke.799
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.33.0-gke.799
  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

Reverta uma atualização de um node pool

Existem muitas dependências, como a compatibilidade com o kubelet ou os plug-ins, que podem afetar o desempenho das suas cargas de trabalho. Caso encontre um problema após atualizar um node pool de trabalho, pode reverter o node pool para a versão anterior.

Esta funcionalidade não está na mesma fase de lançamento para todas as versões de cluster suportadas:

1,30

Para clusters da versão 1.30 (clusters com nós do plano de controlo na versão 1.30), a capacidade de reversão do conjunto de nós está em DG e ativada por predefinição.

1,29

A capacidade de reversão do conjunto de nós está disponível para pré-visualização para clusters da versão 1.29 (clusters com nós do plano de controlo na versão 1.29). Enquanto esta funcionalidade estiver em pré-visualização, tem de adicionar a seguinte anotação ao recurso Cluster para ativar a funcionalidade:

preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable

1,28

A capacidade de reversão do conjunto de nós não está disponível para clusters na versão 1.28 ou anterior.

Para reverter uma atualização de um conjunto de nós, siga estes passos:

bmctl

Quando usa bmctl para reverter uma atualização de um conjunto de nós, edita o ficheiro de configuração do cluster e aplica as alterações com o comando bmctl update:

  1. Edite as NodePool especificações no ficheiro de configuração do cluster para os pools de nós de trabalho que quer reverter para a versão anterior. Defina anthosBareMetalVersion para a versão anterior (pré-atualização) do cluster.

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

    Se forem selecionados vários conjuntos de nós de trabalho para reversão, o valor de spec.nodePoolUpgradeStrategy.concurrentNodePools na especificação do cluster determina quantos conjuntos de nós são revertidos em paralelo. Se não quiser reverter os conjuntos de nós de trabalho em simultâneo, selecione um conjunto de nós de cada vez para a reversão ou atualize as definiçõ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 alterações às especificações de NodePool:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster que quer atualizar.

    • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de gestão (administrador, híbrido ou autónomo).

    A reversão é iniciada automaticamente. O comando bmctl update cluster sai imediatamente, mas a reversão continua a progredir. Não execute outras operações no cluster enquanto o reversão estiver em curso.

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

    • Coloque o nó no modo de manutenção.
    • Execute uma tarefa de reposição no nó para o colocar num estado limpo.
    • Execute verificações prévias da máquina no nó.
    • Execute uma tarefa de inicialização da máquina no nó para o reinstalar na versão de reversão (pré-atualização) de destino.
    • 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 é definido para a versão de reversão de destino.

kubectl

Pode reverter uma atualização do node pool usando kubectl para editar o recurso NodePool diretamente:

  1. Para reverter um conjunto 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 o seguinte:

    • NODE_POOL_NAME: o nome do node pool que está a reverter.

    • CLUSTER_NAMESPACE: o nome do espaço de nomes no qual o node pool está implementado. Este é o namespace do cluster.

    • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de gestão (administrador, híbrido ou autónomo).

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

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

  3. Guarde e feche o recurso NodePool no editor.

    A reversão é iniciada automaticamente. Não execute outras operações no cluster enquanto a reversão estiver em curso.

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

    • Coloque o nó no modo de manutenção.
    • Execute uma tarefa de reposição no nó para o colocar num estado limpo.
    • Execute verificações prévias da máquina no nó.
    • Execute uma tarefa de inicialização da máquina no nó para o reinstalar na versão de reversão (pré-atualização) de destino.
    • 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 é definido para a versão de reversão de destino.

Atualizações paralelas

Numa atualização de cluster predefinida típica, cada nó do cluster é atualizado sequencialmente, um após o outro. Esta secção mostra como configurar os conjuntos de nós do cluster e de trabalho para que vários nós sejam atualizados em paralelo quando atualiza o cluster. A atualização de nós em paralelo acelera significativamente as atualizações de clusters, especialmente para clusters com centenas de nós.

Existem duas estratégias de atualização paralelas que pode usar para acelerar a atualização do cluster:

  • Atualização de nós em simultâneo: pode configurar os seus conjuntos de nós de trabalho para que vários nós sejam atualizados em paralelo. As atualizações paralelas de nós são configuradas na especificação do NodePool (spec.upgradeStrategy.parallelUpgrade) e apenas os nós num node pool de nós de trabalho podem ser atualizados em paralelo. Só é possível atualizar os nós nos conjuntos de nós do plano de controlo ou do balanceador de carga um de cada vez. Para mais informações, consulte o artigo Estratégia de atualização de nós.

  • Atualização simultânea de node pools: pode configurar o cluster para que vários node pools sejam atualizados em paralelo. Só é possível atualizar em paralelo os conjuntos de nós de trabalho. Só é possível atualizar um de cada vez os conjuntos de nós do painel de controlo e do equilibrador de carga.

Estratégia de atualização de nós

Pode configurar pools de nós de trabalho para que vários nós sejam atualizados em simultâneo (concurrentNodes). Também pode definir um limite mínimo para o número de nós capazes de executar cargas de trabalho durante o processo de atualização (minimumAvailableNodes). Esta configuração é feita na especificação NodePool. Para mais informações acerca destes campos, consulte a referência do campo de configuração do cluster.

A estratégia de atualização de nós aplica-se apenas a conjuntos de nós de trabalho. Não é possível especificar uma estratégia de atualização de nós para o painel de controlo ou os conjuntos de nós do equilibrador de carga. Durante uma atualização do cluster, os nós no painel de controlo e os conjuntos de nós do equilibrador de carga são atualizados sequencialmente, um de cada vez. Os node pools do plano de controlo e os node pools do equilibrador de carga são especificados na especificação do cluster (controlPlane.nodePoolSpec.nodes e loadBalancer.nodePoolSpec.nodes).

Quando configura atualizações paralelas para nós, tenha em atenção as seguintes restrições:

  • O valor de concurrentNodes não pode exceder 50% do número de nós no conjunto de nós nem o número fixo 15, consoante o que for inferior. Por exemplo, se o seu conjunto de nós tiver 20 nós, não pode especificar um valor superior a 10. Se o seu conjunto de nós tiver 100 nós, 15 é o valor máximo que pode especificar.

  • Quando usa concurrentNodes juntamente com minimumAvailableNodes, os valores combinados não podem exceder o número total de nós no conjunto de nós. Por exemplo, se o seu conjunto de nós tiver 20 nós e minimumAvailableNodes estiver definido como 18, concurrentNodes não pode exceder 2. Da mesma forma, se concurrentNodes estiver definido como 10, minimumAvailableNodes não pode exceder 10.

O exemplo seguinte mostra um conjunto de nós de trabalho np1 com 10 nós. Numa atualização, os nós são atualizados 5 de cada vez e, pelo menos, 4 nós têm de permanecer disponíveis para que a atualização 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 atualização do node pool

Pode configurar um cluster para que vários conjuntos de nós de trabalho sejam atualizados em paralelo. O campo booleano nodePoolUpgradeStrategy.concurrentNodePools na especificação do cluster especifica se deve ou não atualizar todos os grupos de nós de trabalho de um cluster em simultâneo. Por predefinição (1), os node pools são atualizados sequencialmente, um após o outro. Quando define concurrentNodePools como 0, todos os conjuntos de nós de trabalho no cluster são atualizados em paralelo.

Esta definição não afeta o plano de controlo nem os conjuntos de nós de equilíbrio de carga. Estes node pools são sempre atualizados sequencialmente, um de cada vez. Os node pools do nó do plano de controlo e os node pools do equilibrador 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 uma atualização paralela

Esta secção descreve como configurar um cluster e um conjunto de nós de trabalho para atualizações paralelas.

Para fazer uma atualização paralela de pools de nós trabalhadores e nós num pool de nós trabalhadores, faça o seguinte:

  1. Adicione uma secção upgradeStrategy à especificação NodePool.

    Pode aplicar este manifesto separadamente ou como parte do ficheiro de configuração do cluster quando faz uma atualização do cluster.

    Segue-se 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 5 nós são atualizados em paralelo. O campo minimumAvailableNodes está definido como 10, o que significa que têm de permanecer, pelo menos, 10 nós disponíveis para cargas de trabalho durante toda a atualização.

  2. Adicione uma secção nodePoolUpgradeStrategy à especificação do cluster no ficheiro 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.33.0-gke.799
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

    Neste exemplo, o campo concurrentNodePools está definido como 0, o que significa que todos os conjuntos de nós de trabalho são atualizados em simultâneo durante a atualização do cluster. A estratégia de atualização para os nós nos node pools é definida nas especificações do node pool.

  3. Atualize o cluster conforme descrito na secção Atualize clusters de administrador, autónomos, híbridos ou de utilizadores anterior.

Valores predefinidos de atualização paralela

As atualizações paralelas estão desativadas por predefinição e os campos relacionados com atualizações paralelas são mutáveis. Em qualquer altura, pode remover os campos ou defini-los para os respetivos valores predefinidos para desativar a funcionalidade antes de uma atualização subsequente.

A tabela seguinte apresenta os campos de atualização paralela e os respetivos valores predefinidos:

Campo Valor predefinido Significado
nodePoolUpgradeStrategy.concurrentNodePools (especificação do cluster) 1 Atualize os node pools de worker sequencialmente, um após o outro.
upgradeStrategy.parallelUpgrade.concurrentNodes (especificação NodePool) 1 Atualize os nós sequencialmente, um após o outro.
upgradeStrategy.parallelUpgrade.minimumAvailableNodes (especificação NodePool) O valor minimumAvailableNodes predefinido depende do valor de concurrentNodes.
  • Se não especificar concurrentNodes, o valor predefinido de minimumAvailableNodes é 2/3 do tamanho do conjunto de nós.
  • Se especificar concurrentNodes, minimumAvailableNodes é, por predefinição, o tamanho do conjunto de nós menos concurrentNodes.
 A atualização é interrompida quando é atingido o valor minimumAvailableNodes e só continua quando o número de nós disponíveis for superior a minimumAvailableNodes.

Inicie a atualização do cluster

Esta secção contém instruções para atualizar clusters.

bmctl

Quando transfere e instala uma nova versão do bmctl, pode atualizar os clusters de administrador, híbridos, autónomos e de utilizador criados com uma versão anterior. Para uma determinada versão do bmctl, um cluster só pode ser atualizado para a mesma versão.

  1. Defina as suas credenciais de utilizador como credenciais padrão da aplicação (ADC):

    gcloud auth application-default login

    Siga as instruções para selecionar a sua Conta Google para o ADC. Para mais informações, consulte o artigo Configure as Credenciais padrão da aplicação.

  2. Transfira a versão mais recente do bmctl, conforme descrito em Transferências do Google Distributed Cloud.

  3. Atualize anthosBareMetalVersion no ficheiro de configuração do cluster para a versão de destino da atualização.

    A versão de destino da atualização tem de corresponder à versão do ficheiro bmctl transferido. O seguinte fragmento do ficheiro de configuração do cluster 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.33.0-gke.799

  4. Use o comando bmctl upgrade cluster para concluir a atualização:

    bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster a atualizar.
    • ADMIN_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de administrador.

    A operação de atualização do cluster executa verificações prévias para validar o estado do cluster e o estado de funcionamento do nó. A atualização do cluster não prossegue se as verificações prévias falharem. Para informações de resolução de problemas, consulte o artigo Resolva problemas de instalação ou atualização de clusters.

    Quando todos os componentes do cluster tiverem sido atualizados com êxito, a operação de atualização do cluster executa verificações de funcionamento do cluster. Este último passo verifica se o cluster está em boas condições de funcionamento. Se o cluster não passar em todas as verificações de funcionamento, continua a ser executado até passar. Quando todas as verificações de funcionamento são aprovadas, a atualização é concluída com êxito.

    Para mais informações sobre a sequência de eventos para atualizações de clusters, consulte o artigo Ciclo de vida e fases das atualizações de clusters.

kubectl

Para atualizar um cluster com o kubectl, efetue os seguintes passos:

  1. Edite o ficheiro de configuração do cluster para definir anthosBareMetalVersion para a versão de destino da atualização.

  2. Para iniciar a atualização, execute o seguinte comando:

    kubectl apply -f CLUSTER_CONFIG_PATH

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

    Tal como no processo de atualização com o bmctl, as verificações prévias são executadas como parte da atualização do cluster para validar o estado do cluster e o funcionamento dos nós. Se as verificações preliminares falharem, a atualização do cluster é interrompida. Para resolver problemas de falhas, examine o cluster e os registos relacionados, uma vez que não é criado nenhum cluster de arranque. Para mais informações, consulte o artigo Resolva problemas de instalação ou atualização de clusters.

Embora não precise da versão mais recente do bmctl para atualizar clusters com o kubectl, recomendamos que transfira a versão mais recente do bmctl. Tem de bmctlrealizar outras tarefas, como verificações de funcionamento e cópias de segurança, para garantir que o cluster se mantém em bom estado de funcionamento.

Pause e retome atualizações

A funcionalidade de pausa e retoma da atualização permite-lhe pausar uma atualização do cluster antes de terminar. Quando uma atualização do cluster é pausada, não são acionadas novas atualizações de nós de trabalho até que a atualização seja retomada.

Esta funcionalidade está disponível em (pré-visualização) para clusters com todos os nós do plano de controlo na versão secundária 1.28 ou superior. A funcionalidade está em GA para clusters com todos os nós do plano de controlo na versão secundária 1.29 ou superior.

Pode querer pausar uma atualização pelos seguintes motivos:

  • Detetou um problema com as cargas de trabalho do cluster durante a atualização e quer pausar a atualização para investigar o problema

  • Tem períodos de manutenção curtos e quer pausar a atualização entre os períodos

Enquanto uma atualização do cluster estiver pausada, as seguintes operações são suportadas:

Quando um novo nó é adicionado enquanto uma atualização está pausada, as tarefas de verificação da máquina não são executadas no mesmo até que a atualização seja retomada e concluída.

Enquanto a atualização do cluster estiver pausada, as seguintes operações do cluster não são suportadas:

Não pode iniciar uma nova atualização do cluster enquanto uma atualização do cluster ativa estiver em pausa.

Ative a pausa e o reinício da atualização

Google Distributed Cloud 1.33

A funcionalidade de pausa e retoma da atualização está ativada por predefinição para clusters com todos os nós do plano de controlo na versão secundária 1.29 ou superior.

Google Distributed Cloud 1.32

Embora a capacidade de pausar e retomar a atualização esteja em pré-visualização, pode ativá-la com uma anotação no recurso Cluster.

Para ativar a pausa e o reinício da atualização, siga estes passos:

  1. Adicione a anotação preview.baremetal.cluster.gke.io/upgrade-pause-and-resume ao ficheiro 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: enable
spec:
...

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

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster que quer atualizar.
    • ADMIN_KUBECONFIG: para clusters de administrador, híbridos ou autónomos, introduza o caminho para o ficheiro kubeconfig do cluster. Para um cluster de utilizadores, introduza o caminho para o ficheiro kubeconfig do cluster admin.

    O campo nodePoolUpgradeStrategy.pause é mutável. Pode adicioná-lo e atualizá-lo em qualquer altura.

Pause uma atualização

Pausa uma atualização de cluster definindo nodePoolUpgradeStrategy.pause como true na especificação do cluster.

Para pausar uma atualização de cluster ativa, siga estes passos:

  1. Adicione nodePoolUpgradeStrategy.pause ao ficheiro 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 usou bmctl para iniciar a atualização, precisa de uma nova janela do terminal para realizar o passo seguinte.

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

    bmctl update CLUSTER_NAME

    A operação de atualização está pausada. Não são acionadas novas atualizações de nós.

  3. Se usou o bmctl para iniciar a atualização e planeia uma pausa duradoura, prima Control+C para sair do bmctl. Caso contrário, mantenha o bmctl em execução.

    A CLI bmctl não deteta alterações no estado de pausa da atualização e, por isso, não termina automaticamente. No entanto, quando sai do bmctl, o registo do progresso da atualização é interrompido no ficheiro de registo cluster-upgrade-TIMESTAMP na pasta do cluster na sua estação de trabalho de administrador e no Cloud Logging. Por conseguinte, para pausas curtas, é recomendável manter o bmctl em execução. Se deixar o bmctl em execução durante um período prolongado enquanto a atualização está pausada, o tempo limite acaba por expirar.

Retome uma atualização pausada

Retoma uma atualização de cluster pausada definindo nodePoolUpgradeStrategy.pause como false na especificação do cluster ou removendo nodePoolUpgradeStrategy.pause da especificação.

Para retomar uma atualização de cluster que foi pausada, siga estes passos:

  1. Defina nodePoolUpgradeStrategy.pause para o ficheiro de configuração do cluster e defina-o como false:

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

    Em alternativa, pode remover o campo pause, uma vez que a predefinição é false.

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

    bmctl update CLUSTER_NAME

    A operação de atualização é retomada a partir do ponto em que foi interrompida.

  3. Para verificar o estado da atualização, comece por obter uma lista dos recursos que têm anthosBareMetalVersion no respetivo status:

    kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces

    Substitua o seguinte:

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

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

    O exemplo seguinte mostra o formato da resposta para BareMetalMachine recursos personalizados. Cada BareMetalMachine corresponde a um nó de 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 o status.anthosBareMetalVersion (versão atual do recurso), obtenha detalhes de recursos individuais:

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

    O exemplo seguinte 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.