Fazer upgrade de clusters

Version 1.15 

• Mais recente
• Versão 1.16
• Versões anteriores (sem suporte)

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 Clusters do GKE em bare metal disponibiliza recursos e correções no cluster. 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.

A partir dos clusters do GKE em bare metal versão 1.15.0, o comportamento de upgrade padrão para clusters autogerenciados (administrador, híbrido ou autônomo) é um upgrade no local. Os upgrades no local usam controladores de ciclo de vida, em vez de um cluster de inicialização, para gerenciar todo o processo de upgrade. Essa alteração simplifica o processo e reduz os requisitos de recursos, o que torna os upgrades de cluster mais confiáveis e escalonáveis.

Para saber mais sobre o processo de upgrade, consulte Ciclo de vida e etapas dos upgrades de cluster.

Observação: ao fazer upgrade de clusters do GKE em bare metal 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 alta 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 upgrade para uma versão de patch inferior.

Considerações sobre upgrades

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 clusters do Anthos em bare metal.

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 Anthos em bare metal conhecidos e selecione a categoria Upgrades e atualizações.

Como fazer upgrade de clusters de administrador, autônomos, híbridos ou de usuários

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 a versão 1.15.11, verifique se os clusters de usuário associados estão na versão 1.14.0 ou mais recente. bmctl emitirá um erro se encontrar qualquer cluster de usuário abaixo de 1.14.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 em Downloads do GKE em bare metal.

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

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 para o arquivo de configuração do cluster de administrador.

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.

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 um Portworx, para ajudar a gerenciar cargas de trabalho com estado nos clusters, recomendamos não usar paralelo upgrades.

Observação: para clusters do GKE em versões bare metal 1.14.0 a 1.14.4, o campo de especificação NodePool spec.upgradeStrategy.parallelUpgrade.concurrentNodes é imutável. Nessas versões, só é possível adicionar esse campo a um novo pool de nós. Depois de adicionado, esse campo não pode ser atualizado ou removido. Recomendamos que você faça upgrade para uma versão mais recente que a 1.14.4 antes de fazer upgrades paralelos.

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. A capacidade de fazer upgrade de vários pools de nós simultaneamente está disponível para pré-lançamento público. Para mais informações, consulte Estratégia de upgrade do pool de nós.

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 20% do número de nós no pool de nós ou 10, o que for menor. Por exemplo, se o pool de nós tem 40 nós, não é possível especificar um valor maior que 8. Se o pool de nós tem 100 nós, 10 é 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 dois por vez, e pelo menos cinco 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: 2
      minimumAvailableNodes: 5 

Estratégia de upgrade do pool de nós

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.

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

A capacidade de fazer upgrade de todos os pools de nós de trabalho simultaneamente está disponível apenas para visualização. Não use esse recurso nos clusters de produção.

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

Cuidado: no GKE nas versões Bare Metal 1.14.0 a 1.14.4, o campo upgradeStrategy é imutável. Nessas versões, só é possível adicionar esse campo a um novo pool de nós. Depois de adicionado, esse campo não pode ser atualizado ou removido.

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ós para planos 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.

   Cuidado: a capacidade de fazer upgrade de todos os pools de nós de trabalho simultaneamente está disponível apenas para visualização. Não use esse recurso nos clusters de produção.

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

Como desativar upgrades paralelos de nós

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	0	Não é necessário garantir que os nós estejam disponíveis durante o upgrade.