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
.
Para saber mais sobre o processo de upgrade, consulte Ciclo de vida e etapas dos upgrades de 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 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 de Clusters do Anthos em bare metal e selecione a categoria 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 diminuição de cada nó e na reinicialização/reagendamento 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.
Para ver as regras de controle de versão para fazer upgrade seletiva de pools de nós de trabalho, consulte Regras de controle de versão do pool de nós no ciclo de vida e nos estágios de upgrades do 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:
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.
- Defina
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: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.15.0 e
tenha dois pools de nós de trabalho: wpool01
e wpool02
. Além disso, suponha que você queira
fazer upgrade do plano de controle e da wpool01
para a versão 1.16.8, mas queira que
wpool02
permaneça na versão 1.15.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.16.8
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool01
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: 1.16.8
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.15.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
excluídos de um upgrade de cluster têm o campo anthosBareMetalVersion
na especificação NodePool definido para a versão anterior do cluster (pré-upgrade).
Para atualizar os pools de nós de trabalho para a versão atual com upgrade feito do cluster:
Edite as especificações do 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.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.16.8, mas o pool de nós wpool02
ainda está na antiga versão
1.15.0 do cluster antes do 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.16.8
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool01
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: 1.16.8
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
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.
.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.
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
comminimumAvailableNodes
, 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 eminimumAvailableNodes
está definido com 18,concurrentNodes
não pode exceder 2. Da mesma forma, seconcurrentNodes
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:
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 campominimumAvailableNodes
está definido como10
, o que significa que pelo menos 10 nós precisam permanecer disponíveis para cargas de trabalho durante o upgrade.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.16.8 ... nodePoolUpgradeStrategy: concurrentNodePools: 0 ...
Neste exemplo, o campo
concurrentNodePools
está definido como0
, 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.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 .
|
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.
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.
Faça o download do
bmctl
mais recente, conforme descrito em Downloads do GKE em bare metal.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 campoanthosBareMetalVersion
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.16.8
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:
Edite o arquivo de configuração do cluster para definir
anthosBareMetalVersion
como a versão de destino do upgrade.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.