Como fazer o upgrade manual de um cluster ou pool de nós


Por padrão, os upgrades automáticos estão ativados nos clusters e nos pools de nós do Google Kubernetes Engine (GKE).

Esta página explica como solicitar manualmente um upgrade ou downgrade para um cluster do GKE ou seus nós. Saiba mais sobre como os upgrades de cluster automáticos e manuais funcionam. Você também pode controlar quando os upgrades automáticos podem ou não ocorrer com a configuração de janelas e exclusões de manutenção.

Novas versões do GKE são anunciadas regularmente. Para saber mais sobre as versões disponíveis, consulte Controle de versões. Para ver informações sobre clusters, consulte Arquitetura de cluster. Para conferir orientações sobre como fazer upgrade dos clusters, consulte Práticas recomendadas para fazer upgrade de clusters.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Defina as configurações padrão da gcloud usando um dos métodos a seguir:

  • Use gcloud init se quiser orientações para definir os padrões.
  • Use gcloud config para definir individualmente a região, a zona e o ID do projeto.

Como usar o gcloud init

Se você receber o erro One of [--zone, --region] must be supplied: Please specify location, conclua esta seção.

  1. Execute gcloud init e siga as instruções:

    gcloud init

    Se você estiver usando SSH em um servidor remoto, utilize a sinalização --console-only para impedir que o comando inicie um navegador:

    gcloud init --console-only
  2. Siga as instruções para autorizar a gcloud a usar sua conta do Google Cloud.
  3. Crie uma nova configuração ou selecione uma atual.
  4. Escolha um projeto do Google Cloud.
  5. Escolha uma zona padrão do Compute Engine para clusters zonais ou uma região para clusters regionais ou de Autopilot.

Como usar o gcloud config

  • Defina o ID do projeto padrão:
    gcloud config set project PROJECT_ID
  • Se você estiver trabalhando com clusters zonais, defina a zona do Compute padrão:
    gcloud config set compute/zone COMPUTE_ZONE
  • Se você estiver trabalhando com clusters de Autopilot ou regionais, defina a região do Compute padrão:
    gcloud config set compute/region COMPUTE_REGION
  • Atualize gcloud para a versão mais recente:
    gcloud components update

Salve seus dados em discos permanentes

Antes de fazer upgrade de um pool de nós, garanta que todos os dados que você quer manter estejam armazenados em um pod com volumes permanentes que usem discos permanentes. Em vez de apagados, os discos permanentes são desconectados durante os upgrades, e os dados deles são "distribuídos" entre os pods.

As seguintes restrições são relacionadas aos discos permanentes:

  • Os pods estão em execução nos nós que precisam ser VMs do Compute Engine.
  • Essas VMs precisam estar no mesmo projeto e zona do Compute Engine que o disco permanente.

Para saber como adicionar um disco permanente a uma instância de nó atual, consulte Como adicionar ou redimensionar discos permanentes zonais na documentação do Compute Engine.

Sobre o upgrade de clusters

Os upgrades do plano de controle e dos nós de um cluster são feitos separadamente.

Os planos de controle de cluster sempre são atualizados regularmente, independentemente de o cluster estar inscrito em um canal de lançamento ou não.

Limitações

Clusters Alpha não podem receber upgrade.

Versões compatíveis

As Notas de lançamento anunciam quando novas versões estão disponíveis e quando versões mais antigas não estão mais disponíveis. A qualquer momento, é possível listar todas as versões compatíveis de cluster e nó usando este comando:

gcloud container get-server-config

Problemas conhecidos

Se você tiver o Anthos Service Mesh ou o OSS Istio instalado no cluster, dependendo das suas configurações do PodDisruptionBudget para os componentes do Istio, os nós do usuário não conseguirão fazer upgrade para a versão do plano de controle após várias tentativas. Para evitar essa falha, recomendamos que você aumente a configuração minReplicas de escalonamento horizontal e automático do pod para os componentes no namespace istio-system antes de fazer upgrade. Isso garantirá que você sempre tenha uma instância do plano de controle ASM em execução.

Se você tiver o Anthos Service Mesh 1.5+ ou o OSS Istio 1.5+:

kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istiod -p '{"spec":{"minReplicas": 2}}' --type=merge

Se você tiver o Anthos Service Mesh 1.4.x ou o OSS Istio 1.4.x:

kubectl patch hpa -n istio-system istio-galley -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-nodeagent -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-pilot -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-sidecar-injector -p '{"spec":{"minReplicas": 2}}' --type=merge

Embora os upgrades automáticos possam encontrar o problema, o processo de upgrade automático força os nós a fazer upgrade. No entanto, o upgrade leva uma hora extra para cada nó no namespace istio-system que viola o PodDisruptionBudget.

Limitações de downgrade

Não é recomendável fazer downgrade de um cluster. É possível fazer o downgrade dos nós para uma versão de patch mais antiga que a versão do cluster. No entanto, não é possível fazer downgrade de um cluster de uma versão secundária para outra. Por exemplo, se um cluster estiver executando o GKE 1.11.5, será possível fazer o downgrade para a versão 1.11.4 (se ainda estiver disponível), mas não para a versão 1.10.9. Em vez disso, um erro como o abaixo será gerado:

ERROR: (gcloud.container.clusters.upgrade) ResponseError: code=400,
message=Master cannot be upgraded to "1.10.9-gke.9": specified version is not
newer than the current version.

Como fazer upgrade do cluster

O Google faz upgrade de clusters e nós automaticamente. Para ter mais controle sobre quais upgrades automáticos seu cluster e seus nós recebem, é possível inscrevê-lo em um canal de lançamento.

Para saber mais sobre como gerenciar a versão do GKE do seu cluster, consulte Upgrades.

Depois que uma nova versão estiver disponível, inicie um upgrade manual quando quiser.

Como fazer upgrade manual do plano de controle

Ao iniciar um upgrade de cluster, não modifique a configuração do cluster por vários minutos, até que o plano de controle possa ser acessado novamente. Se você precisar evitar a inatividade durante upgrades do plano de controle, use um cluster regional.

É possível fazer upgrade do cluster manualmente usando o Console do Cloud ou a ferramenta de linha de comando gcloud. Após o upgrade do cluster, é possível atualizar os nós. Por padrão, os nós criados com o Console do Google Cloud têm o upgrade automático ativado. Isso acontece automaticamente.

gcloud

Para fazer upgrade da versão do plano de controle de cluster, primeiro execute o comando a seguir para ver as versões disponíveis:

gcloud container get-server-config

Para fazer upgrade para a versão padrão do cluster, execute o seguinte comando:

gcloud container clusters upgrade CLUSTER_NAME --master

Para fazer upgrade para uma versão específica que não seja a padrão, execute o comando a seguir:

gcloud container clusters upgrade CLUSTER_NAME \
  --master --cluster-version VERSION

Consulte a documentação gcloud container clusters upgrade.

Console

Para atualizar manualmente o plano de controle do cluster, siga estas etapas:

  1. Acesse o menu do Google Kubernetes Engine no Console do Google Cloud.

    Acesse o menu do Google Kubernetes Engine

  2. Clique no nome do cluster que você quer.

  3. Em Princípios básicos do cluster, clique em Upgrade disponível ao lado de Versão.

  4. Selecione a versão pretendida e clique em Salvar alterações.

Como fazer downgrade de clusters

Para fazer downgrade de um cluster para uma versão de patch anterior, altere a versão do plano de controle do cluster com o seguinte comando:

gcloud container clusters upgrade CLUSTER_NAME \
  --master --cluster-version VERSION
.

Como desativar os upgrades automáticos do cluster

A segurança da infraestrutura é alta prioridade para o GKE e, como tal, planos de controle são atualizados regularmente e não pode ser desativada. No entanto, é possível aplicar janelas de manutenção e exclusões para suspender temporariamente os upgrades de planos de controle e nós.

Embora não seja recomendado, é possível desativar o upgrade automático do nó.

Como fazer upgrade de pools de nós

Por padrão, os nós de um cluster têm o upgrade automático ativado e é recomendável que ele não seja desativado.

Quando um pool de nós é atualizado, é possível definir configurações de upgrade de sobretensão para controlar quantos nós do GKE são atualizados ao mesmo tempo e o grau de interrupção do upgrade para as cargas de trabalho. Por padrão, o GKE atualiza um nó por vez.

Enquanto um nó está sendo atualizado, o GKE interrompe a programação de novos pods nele e tenta programar seus pods em execução em outros nós. Isso é semelhante a outros eventos que recriam o nó, como ativar ou desativar um recurso no pool de nós.

O upgrade será concluído apenas quando todos os nós forem recriados, e o cluster assumir o estado desejado. Quando um nó recém-atualizado é registrado no plano de controle, o GKE o marca como programável.

As instâncias do novo nó executam a versão do Kubernetes desejada e também:

Como fazer upgrade manual de um pool de nós

É possível fazer upgrade manual de uma versão do pool de nós para igualá-la à versão do plano de controle ou a uma versão anterior que ainda esteja disponível e seja compatível com o plano de controle. A versão do Kubernetes e a política de suporte de diferença de versão (em inglês) garantem que os planos de controle sejam compatíveis com nós de até duas versões secundárias mais antigas que o plano de controle. Por exemplo, os planos de controle do Kubernetes 1.13 são compatíveis com os nós do Kubernetes 1.11.

É possível fazer upgrade manual dos pools de nós para uma versão compatível com o plano de controle usando o Console do Google Cloud ou a ferramenta de linha de comando gcloud.

gcloud

O comando a seguir faz upgrade dos nós para a versão que o plano de controle está executando:

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME

Substitua CLUSTER_NAME pelo nome do cluster a ser atualizado.

Para especificar uma versão diferente do GKE nos nós, use a sinalização opcional --cluster-version:

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --cluster-version VERSION

Substitua VERSION pela versão do Kubernetes para que os nós serão atualizados. Por exemplo, --cluster-version=1.7.2 ou cluster-version=latest.

Para mais informações sobre como especificar versões, consulte Controle de versões.

Para mais informações, consulte a documentação gcloud container clusters upgrade.

Console

Para fazer upgrade de um pool de nós com o Console do Cloud, siga as etapas a seguir:

  1. Acesse o menu do Google Kubernetes Engine no Console do Cloud.

    Acesse o menu do Google Kubernetes Engine

  2. Ao lado do cluster que você quer editar, clique em Ações e, depois, em Editar.

  3. Na página Detalhes do cluster, clique na guia Nós.

  4. Na seção Pools de nós, clique no nome do pool de nós que você quer atualizar.

  5. Clique em Editar.

  6. Em Versão do nó, clique em Alterar.

  7. Selecione a versão pretendida na lista suspensa Versão do nó e clique em Alterar.

Como fazer downgrade de pools de nós

É possível fazer downgrade de pool de nós para uma versão de patch mais antiga que a versão do cluster.

Como verificar o status do upgrade de pool de nós

É possível verificar o status de um upgrade usando gcloud beta container operations.

Para ver uma lista de todas as operações executadas e concluídas no cluster, execute o comando a seguir:

gcloud beta container operations list

Cada operação recebe um código e um tipo, além de horários de início e término, cluster de destino e status. A lista é semelhante ao exemplo a seguir:

NAME                              TYPE                ZONE           TARGET              STATUS_MESSAGE  STATUS  START_TIME                      END_TIME
operation-1505407677851-8039e369  CREATE_CLUSTER      us-west1-a     my-cluster                          DONE    20xx-xx-xxT16:47:57.851933021Z  20xx-xx-xxT16:50:52.898305883Z
operation-1505500805136-e7c64af4  UPGRADE_CLUSTER     us-west1-a     my-cluster                          DONE    20xx-xx-xxT18:40:05.136739989Z  20xx-xx-xxT18:41:09.321483832Z
operation-1505500913918-5802c989  DELETE_CLUSTER      us-west1-a     my-cluster                          DONE    20xx-xx-xxT18:41:53.918825764Z  20xx-xx-xxT18:43:48.639506814Z

Para ver mais informações sobre uma determinada operação, especifique o código dela no seguinte comando:

gcloud beta container operations describe OPERATION_ID

Exemplo:

gcloud beta container operations describe operation-1507325726639-981f0ed6
endTime: '20xx-xx-xxT21:40:05.324124385Z'
name: operation-1507325726639-981f0ed6
operationType: UPGRADE_CLUSTER
selfLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/operations/operation-1507325726639-981f0ed6
startTime: '20xx-xx-xxT21:35:26.639453776Z'
status: DONE
targetLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/clusters/...
zone: us-central1-a

Como cancelar um upgrade de pool de nós

Você pode cancelar um upgrade a qualquer momento. Quando você cancela um upgrade:

  • os nós que iniciaram o upgrade o concluem;
  • os nós que não iniciaram o upgrade não prosseguem com a operação;
  • os upgrades dos nós que já tiverem sido concluídos não serão afetados nem revertidos.
  1. Receba o ID da operação do upgrade usando o seguinte comando:

    gcloud container operations list
    
  2. Execute o seguinte comando para cancelar o upgrade:

    gcloud beta container operations cancel OPERATION_ID
    

Consulte a documentação gcloud container operations cancel.

Como reverter um upgrade de pool de nós

Quando o upgrade falha ou é cancelado, é possível reverter os pools de nós para a versão anterior do Kubernetes. Não é possível revertê-los depois da atualização. Os nodes que não iniciaram um upgrade não são afetados.

Para reverter um upgrade, execute o seguinte comando:

gcloud container node-pools rollback NODE_POOL_NAME \
  --cluster CLUSTER_NAME

Substitua:

  • NODE_POOL_NAME: o nome do pool de nós a ser revertido.
  • CLUSTER_NAME: o nome do cluster em que o pool de nós será revertido.

Consulte a documentação gcloud container node-pools rollback.

Como mudar os parâmetros de upgrade imediato

Upgrades súbitos permitem alterar o número de upgrades de nós do GKE de uma só vez e a quantidade de interrupções que um upgrade faz nas suas cargas de trabalho.

As sinalizações max-surge-upgrade e max-unavailable-upgrade são definidas para cada pool de nós. Para mais informações sobre como escolher os parâmetros certos, acesse Como determinar sua configuração de sobretensão ideal.

É possível alterar essas configurações ao criar ou atualizar um cluster ou pool de nós.

As seguintes variáveis são usadas nos comandos mencionados abaixo:

  • CLUSTER_NAME: o nome do cluster do pool de nós.
  • COMPUTE_ZONE: a zona do cluster.
  • NODE_POOL_NAME: o nome do pool de nós.
  • NUMBER_NODES: o número de nós no pool em cada uma das zonas do cluster.
  • SURGE_NODES: o número de nós extras (de sobrecarga) a serem criados em cada upgrade do pool de nós.
  • UNAVAILABLE_NODES: o número de nós que podem estar indisponíveis ao mesmo tempo, em cada upgrade do pool de nós.

Como criar um cluster com parâmetros súbitos específicos

Para criar um cluster com configurações específicas para upgrades súbitos, use as sinalizações max-surge-upgrade e max-unavailable-upgrade.

gcloud container clusters create CLUSTER_NAME \
  --max-surge-upgrade=SURGE_NODES --max-unavailable-upgrade=UNAVAILABLE_NODES

Como criar um cluster com upgrade súbito desativado

Para criar um cluster sem upgrades súbitos, defina o valor da sinalização max-surge-upgrade como 0.

gcloud container clusters create CLUSTER_NAME \
  --max-surge-upgrade=0 --max-unavailable-upgrade=1

Como criar um pool de nós com parâmetros súbitos específicos

Para criar um pool de nós em um cluster atual com configurações específicas para upgrades súbitos, use as sinalizações max-surge-upgrade e max-unavailable-upgrade.

gcloud container node-pools create NODE_POOL_NAME \
  --num-nodes=NUMBER_NODES --cluster=CLUSTER_NAME \
  --max-surge-upgrade=SURGE_NODES --max-unavailable-upgrade=UNAVAILABLE_NODES

Ativar ou desativar o upgrade súbito para um pool de nós atual

Para atualizar as configurações de upgrade de um pool de nós atual, use as sinalizações max-surge-upgrade e max-unavailable-upgrade. Se você definir max-surge-upgrade como maior que 0, o GKE criará nós de sobretensão. Se você definir max-surge-upgrade como 0, o GKE não criará nós de sobretensão.

gcloud beta container node-pools update NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --max-surge-upgrade=SURGE_NODES --max-unavailable-upgrade=UNAVAILABLE_NODES

Como verificar se os upgrades súbitos são ativados em um pool de nós

Para ver se os upgrades súbitos estão ativados em um pool de nós, use o gcloud para descrever os parâmetros do cluster:

gcloud container node-pools describe NODE_POOL_NAME \
--cluster=CLUSTER_NAME

A seguir