Resolver problemas de upgrades de cluster

Se o upgrade do plano de controle ou do pool de nós do Google Kubernetes Engine (GKE) falhar, ficar preso ou causar um comportamento inesperado da carga de trabalho, talvez seja necessário resolver o problema do processo. Manter o plano de controle e os pools de nós atualizados é essencial para a segurança e o desempenho, e resolver problemas ajuda a garantir que seu ambiente permaneça estável.

Para resolver problemas comuns de upgrade, uma boa primeira etapa é monitorar o processo de upgrade do cluster. Em seguida, encontre dicas sobre como resolver o problema:

Essas informações são importantes para administradores e operadores de plataforma que querem diagnosticar as causas principais de upgrades travados ou com falha, gerenciar políticas de manutenção e resolver incompatibilidades de versão. Os desenvolvedores de aplicativos podem encontrar orientações sobre como resolver problemas de carga de trabalho pós-upgrade e entender como configurações de carga de trabalho, como PodDisruptionBudgets, podem afetar a duração do upgrade. Para mais informações sobre as funções comuns e as tarefas de exemplo referenciadas no conteúdo do Google Cloud , consulte Funções e tarefas de usuário comuns do GKE.

Monitorar o processo de upgrade do cluster

Para resolver problemas de upgrade com mais eficiência, comece entendendo o que aconteceu durante o processo. O GKE oferece várias ferramentas que dão visibilidade a esse processo.

No console Google Cloud , o painel de upgrade oferece uma visão geral de todos os upgrades de cluster em andamento, uma linha do tempo de eventos recentes e avisos sobre possíveis bloqueadores, como exclusões de manutenção ativas ou descontinuações de versões futuras. Para verificações automatizadas ou de linha de comando, use o comando gcloud container operations list para conferir o status de operações de upgrade específicas. Para mais informações, consulte Ter visibilidade dos upgrades de cluster.

Para uma investigação mais detalhada, o Cloud Logging é sua principal fonte de informações. O GKE registra informações detalhadas sobre os processos de upgrade do plano de controle e do pool de nós no Cloud Logging. Isso inclui registros de auditoria de alto nível que rastreiam as principais operações de upgrade, bem como registros mais detalhados, como eventos do Kubernetes e registros de componentes de nós, que podem mostrar mais informações sobre erros específicos.

As seções a seguir explicam como consultar esses registros usando o Explorador de registros ou a CLI gcloud. Para mais informações, consulte Verificar registros de upgrade.

Identificar a operação de upgrade com registros de auditoria

Se você não souber qual operação de upgrade falhou, use os registros de auditoria do GKE. Os registros de auditoria rastreiam ações administrativas e fornecem um registro confiável de quando um upgrade foi iniciado e qual é o status final dele. Use as seguintes consultas no Explorador de registros para encontrar a operação relevante.

Tipo de evento Consulta do registro
Atualização automática do plano de controle 
resource.type="gke_cluster"
protoPayload.methodName="google.container.internal.ClusterManagerInternal.UpdateClusterInternal"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.metadata.operationType="UPGRADE_MASTER"
resource.labels.cluster_name="CLUSTER_NAME"

Substitua CLUSTER_NAME pelo nome do cluster que você quer investigar.

Essa consulta mostra a versão de destino e a versão anterior do plano de controle.
Atualização manual do plano de controle 
resource.type="gke_cluster"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.response.operationType="UPGRADE_MASTER"
resource.labels.cluster_name="CLUSTER_NAME"

 
Upgrade automático do pool de nós (somente versão de destino) 
resource.type="gke_nodepool"
protoPayload.methodName="google.container.internal.ClusterManagerInternal.UpdateClusterInternal"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.nodepool_name="NODEPOOL_NAME"

Substitua NODEPOOL_NAME pelo nome do pool de nós que pertence ao cluster.
Upgrade manual do pool de nós 
resource.type="gke_nodepool"
protoPayload.methodName="google.container.v1.ClusterManager.UpdateNodePool"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.response.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.nodepool_name="NODEPOOL_NAME"

Para encontrar a versão anterior do pool de nós, verifique os registros da API Kubernetes:

resource.type="k8s_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.methodName="nodes.patch"

Encontrar mensagens de erro detalhadas nos registros do GKE

Depois que o registro de auditoria mostrar qual operação falhou e quando, você poderá pesquisar mensagens de erro mais detalhadas dos componentes do GKE no mesmo período. Esses registros podem conter os motivos específicos de uma falha de upgrade, como um objeto PodDisruptionBudget mal configurado.

Por exemplo, depois de encontrar uma operação UPGRADE_NODES com falha nos registros de auditoria, use o carimbo de data/hora dela para restringir a pesquisa. No Explorador de registros, insira a consulta a seguir e use o seletor de período para se concentrar no momento em que a falha ocorreu:

resource.type="k8s_node"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.node_name="NODE_NAME"
severity=ERROR

Substitua:

  • CLUSTER_NAME: o nome do cluster.
  • NODE_NAME: o nome do nó no cluster que você quer verificar se há erros.

Usar a CLI gcloud para conferir eventos de upgrade

Além do Explorador de registros, é possível usar comandos da CLI gcloud para analisar eventos de upgrade.

Para procurar upgrades do plano de controle, execute o seguinte comando:

gcloud container operations list --filter="TYPE=UPGRADE_MASTER"

O resultado será assim:

NAME: operation-1748588803271-cfd407a2-bfe7-4b9d-8686-9f1ff33a2a96
TYPE: UPGRADE_MASTER
LOCATION: LOCATION
TARGET: CLUSTER_NAME
STATUS_MESSAGE:
STATUS: DONE
START_TIME: 2025-05-30T07:06:43.271089972Z
END_TIME: 2025-05-30T07:18:02.639579287Z

Esta saída inclui os seguintes valores:

  • LOCATION: a região ou zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) do cluster.
  • CLUSTER_NAME: o nome do cluster.

Para procurar upgrades do pool de nós, execute o seguinte comando:

gcloud container operations list --filter="TYPE=UPGRADE_NODES"

O resultado será assim:

NAME: operation-1748588803271-cfd407a2-bfe7-4b9d-8686-9f1ff33a2a96
TYPE: UPGRADE_NODES
LOCATION: LOCATION
TARGET: CLUSTER_NAME
STATUS_MESSAGE:
STATUS: DONE
START_TIME: 2025-05-30T07:06:43.271089972Z
END_TIME: 2025-05-30T07:18:02.639579287Z

Exemplo: usar registros para resolver problemas de upgrades do plano de controle

O exemplo a seguir mostra como usar os registros para resolver um upgrade do plano de controle sem sucesso:

  1. No console do Google Cloud , acesse a página Análise de registros.

    Acessar o Explorador de registros

  2. No painel de consulta, filtre os registros de upgrade do plano de controle inserindo a seguinte consulta:

    resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"

    Substitua CLUSTER_NAME pelo nome do cluster que você quer investigar.

  3. Clique em Executar consulta.

  4. Revise a saída do registro para conferir as seguintes informações:

  5. Confirme se o upgrade foi iniciado: procure eventos UPGRADE_MASTER recentes por volta do horário em que você iniciou o upgrade. A presença desses eventos confirma que você ou o GKE acionaram o processo de upgrade.

    • Verifique as versões: confira os seguintes campos para confirmar as versões anterior e de destino:

      • protoPayload.metadata.previousMasterVersion: mostra a versão do plano de controle antes do upgrade.

      • protoPayload.metadata.currentMasterVersion: mostra a versão para que o GKE tentou fazer upgrade do plano de controle.

        Por exemplo, se você pretendia fazer upgrade para a versão 1.30.1-gke.1234, mas especificou acidentalmente 1.30.2-gke.4321 (uma versão mais recente e potencialmente incompatível para suas cargas de trabalho), a revisão desses dois campos destacaria essa discrepância. Como alternativa, se o campo currentMasterVersion ainda mostrar a versão anterior após um período prolongado, isso indica que o upgrade não aplicou a nova versão.

    • Procure erros: verifique se há eventos UPGRADE_MASTER repetidos ou outras mensagens de erro. Se o registro de operação parar sem indicar conclusão ou falha, essa descoberta indica um problema.

Depois de identificar um erro ou comportamento específico nos registros, use essas informações para encontrar a solução adequada neste guia.

Resolver problemas de upgrades de pool de nós que estão demorando mais do que o normal

Se o upgrade do pool de nós estiver demorando mais do que o esperado, tente as seguintes soluções:

  1. Verifique o valor de terminationGracePeriodSeconds no manifesto dos seus Pods. Esse valor define o tempo máximo que o Kubernetes aguarda para que um pod seja encerrado normalmente. Um valor alto (por exemplo, alguns minutos) pode aumentar significativamente a duração dos upgrades porque o Kubernetes aguarda o período completo para cada pod. Se esse atraso estiver causando problemas, considere reduzir o valor.

  2. Verifique seus objetos PodDisruptionBudget. Quando um nó está sendo drenado, o GKE aguarda no máximo uma hora por nó para desalojar normalmente as cargas de trabalho. Se o objeto PodDisruptionBudget for muito restritivo, ele poderá impedir que uma remoção normal seja concluída. Nesse cenário, o GKE usa todo o período de carência de uma hora para tentar drenar o nó antes que ele atinja o tempo limite e force a continuação do upgrade. Esse atraso, quando repetido em vários nós, é uma causa comum de um upgrade lento do cluster. Para confirmar se um objeto PodDisruptionBudget restritivo é a causa da lentidão nos upgrades, use o Explorador de registros:

    1. No console do Google Cloud , acesse a página Análise de registros.

      Acessar o Explorador de registros

    2. No painel de consulta, digite a seguinte consulta:

      resource.type=("gke_cluster" OR "k8s_cluster")
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.response.message="Cannot evict pod as it would violate the pod's disruption budget."
log_id("cloudaudit.googleapis.com/activity")

    3. Clique em Executar consulta.

    4. Revise a saída do registro. Se o objeto PodDisruptionBudget for a causa do problema, a saída será semelhante a esta:

      resourceName: "core/v1/namespaces/istio-system/pods/POD_NAME/eviction"

response: {
  @type: "core.k8s.io/v1.Status"
  apiVersion: "v1"
  code: 429
  details: {
  causes: [
    0: {
    message: "The disruption budget istio-egressgateway needs 1 healthy pods and has 1 currently"
    reason: "DisruptionBudget"
    }
  ]
  }
  kind: "Status"
  message: "Cannot evict pod as it would violate the pod's disruption budget."
  metadata: {
  }
  reason: "TooManyRequests"
  status: "Failure"
}

    5. Depois de confirmar que um objeto PodDisruptionBudget é a causa, liste todos os objetos PodDisruptionBudget e verifique se as configurações são adequadas:

      kubectl get pdb --all-namespaces

      O resultado será assim:

      NAMESPACE        NAME          MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
example-app-one  one_pdb       3               0                 1                     12d

      Neste exemplo, o PodDisruptionBudget chamado one_pdb requer um mínimo de três pods disponíveis. Como a remoção de um pod durante o upgrade deixaria apenas dois pods disponíveis, a ação viola o orçamento e causa a paralisação do upgrade.

      Se o objeto PodDisruptionBudget estiver funcionando conforme esperado, não será necessário fazer nada. Se não for, considere reduzir as configurações de PodDisruptionBudget durante a janela de upgrade.

  3. Verifique as afinidades de nós. Regras restritivas podem diminuir a velocidade dos upgrades impedindo que os pods sejam reprogramados em nós disponíveis se esses nós não corresponderem aos rótulos necessários. Esse problema é especialmente problemático durante atualizações de picos, porque as afinidades de nós podem limitar quantos nós podem ser atualizados simultaneamente se os nós com os rótulos corretos não tiverem capacidade de cluster suficiente para hospedar os novos pods.

  4. Verifique se você usa a estratégia de upgrade de curta duração. O GKE usa a estratégia de upgrade de curta duração para nós de início flexível e para nós que usam apenas provisionamento em fila em clusters que executam a versão 1.32.2-gke.1652000 ou mais recente do GKE. Se você usar essa estratégia, a operação de upgrade poderá levar até sete dias.

  5. Verifique se você usa pods de duração estendida (disponíveis para clusters do Autopilot). Durante um upgrade, o GKE precisa drenar todos os pods de um nó antes que o processo seja concluído. No entanto, durante um upgrade iniciado pelo GKE, o GKE não remove pods de longa duração por até sete dias. Essa proteção impede que o nó seja esgotado. O GKE encerra o pod à força somente após o término desse período, e esse atraso significativo de vários dias para um único nó pode atrasar mais upgrades de nós no cluster do Autopilot.

  6. Volumes permanentes anexados podem fazer com que um processo de upgrade leve mais tempo do que o normal devido ao tempo necessário para gerenciar o ciclo de vida desses volumes.

  7. Verifique o status do upgrade automático do cluster. Se o motivo for SYSTEM_CONFIG, os upgrades automáticos serão pausados temporariamente por motivos técnicos ou comerciais. Se esse for o motivo, recomendamos que você não faça um upgrade manual, a menos que seja necessário.

Resolver problemas de upgrades incompletos do pool de nós

Às vezes, o GKE não consegue concluir um upgrade do pool de nós, deixando o pool parcialmente atualizado. Há vários motivos para isso acontecer:

  • O upgrade foi cancelado manualmente.
  • O upgrade falhou devido a um problema, como falha no registro de novos nós, esgotamento de endereços IP ou cotas de recursos insuficientes.
  • O GKE pausou o upgrade. Essa pausa pode ocorrer, por exemplo, para evitar um upgrade para uma versão com problemas conhecidos ou durante determinados períodos de manutenção iniciados pelo Google.
  • Se você usa upgrades automáticos, uma janela de manutenção terminou antes da conclusão do upgrade. Outra opção é que um período de exclusão de manutenção tenha começado antes da conclusão do upgrade. Para mais informações, consulte Janela de manutenção que impede a conclusão da atualização do nó.

Quando um pool de nós é parcialmente atualizado, os nós são executados em versões diferentes. Para resolver esse problema e verificar se todos os nós no pool de nós estão executando a mesma versão, retome o upgrade ou reverta o upgrade.

No entanto, as estratégias de upgrades súbitos e upgrades azul-verde interagem de maneira diferente com as janelas de manutenção:

  • Upgrades súbitos: a operação de upgrade é pausada se for executada fora da janela de manutenção. O upgrade é retomado automaticamente durante a próxima janela de manutenção programada.
  • Upgrades azul-verde: a operação de upgrade continua até a conclusão, mesmo que exceda a janela de manutenção. Os upgrades azul-verde oferecem controle granular sobre o ritmo do upgrade com recursos como tempos de espera de lote e pool de nós. Além disso, o pool de nós adicional ajuda a garantir que as cargas de trabalho permaneçam operacionais.

Resolver problemas de comportamento inesperado de upgrade automático

Às vezes, os upgrades automáticos do cluster não acontecem da maneira esperada. As seções a seguir ajudam você a resolver os problemas:

Os clusters não são atualizados quando o upgrade automático de nós está ativado

Se você não desativou o upgrade automático de nós, mas um upgrade não ocorreu, tente as seguintes soluções:

  1. Se você usa um canal de lançamento, verifique se os upgrades automáticos de nós não estão bloqueados. Para clusters inscritos em um canal de lançamento, o maintenancePolicy é a principal maneira de controlar upgrades automáticos. Isso pode impedir que um upgrade comece ou interromper um que já esteja em andamento. Uma exclusão de manutenção ativa pode bloquear um upgrade completamente, e o tempo de uma janela de manutenção pode causar uma interrupção. Revise suas maintenancePolicy para determinar se uma destas configurações é a causa:

    gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID  \
    --location LOCATION

    Substitua:

    • CLUSTER_NAME: o nome do cluster do pool de nós a ser descrito.
    • PROJECT_ID: o ID do projeto do cluster.
    • LOCATION: a região ou zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) do cluster.

    O resultado será assim:

    …
maintenancePolicy:
  maintenanceExclusions:
  - exclusionName: critical-event-q4-2025
    startTime: '2025-12-20T00:00:00Z'
    endTime: '2026-01-05T00:00:00Z'
    scope:
      noUpgrades: true # This exclusion blocks all upgrades
  window:
    dailyMaintenanceWindow:
      startTime: 03:00 # Daily window at 03:00 UTC
…

    Na saída, revise a seção maintenancePolicy para as duas condições a seguir:

    • Para saber se um upgrade está bloqueado: procure um maintenanceExclusion ativo com um escopo NO_MINOR_OR_NODE_UPGRADES. Essa configuração geralmente impede que o GKE inicie um novo upgrade.
    • Para verificar se um upgrade foi interrompido: confira a programação do seu dailyMaintenanceWindow ou maintenanceExclusions. Se um upgrade for executado além da janela programada, o GKE vai pausar o upgrade, resultando em um upgrade parcial. Para mais informações sobre upgrades parciais, consulte a seção Resolver problemas de upgrades incompletos.

    Para resolver esses problemas, aguarde o fim de uma exclusão, remova-a ou ajuste as janelas de manutenção para permitir mais tempo para a conclusão das atualizações.

  2. Se você não usa um canal de lançamento, verifique se o upgrade automático ainda está ativado para o pool de nós:

    gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location LOCATION

    Substitua NODE_POOL_NAME pelo nome do pool de nós a ser descrito.

    Se os upgrades automáticos de pool de nós estiverem ativados para esse pool, a saída no campo autoUpgrade será a seguinte:

    management:
  autoUpgrade: true

    Se autoUpgrade estiver definido como false ou o campo não estiver presente, ative os upgrades automáticos.

  3. O upgrade talvez não tenha sido lançado na região ou zona em que seu cluster está localizado, mesmo que tenha sido mencionado nas notas da versão. Os upgrades do GKE são lançados progressivamente ao longo de vários dias (normalmente quatro ou mais). Depois que o upgrade chegar à sua região ou zona, ele só vai começar durante as janelas de manutenção aprovadas. Por exemplo, um lançamento pode chegar à zona do cluster no primeiro dia, mas a próxima janela de manutenção do cluster só será no sétimo dia. Nesse cenário, o GKE não vai fazer upgrade do cluster até o sétimo dia. Para mais informações, consulte Programação de lançamento do GKE.

Os clusters são atualizados automaticamente quando o upgrade automático não está ativado

Para ajudar a manter a confiabilidade, a disponibilidade, a segurança e o desempenho do seu ambiente do GKE, o GKE pode fazer upgrade automático dos seus clusters, mesmo que você não use upgrades automáticos.

O GKE pode ignorar suas janelas de manutenção, exclusões ou upgrades automáticos desativados do pool de nós para realizar os upgrades necessários por vários motivos críticos, como os seguintes:

  • Clusters cujos planos de controle estão executando uma versão do GKE que atingiu a data de fim do suporte. Para confirmar se o cluster está se aproximando da data de fim do suporte, consulte Programação estimada para canais de lançamento.
  • Nós em um cluster que estão executando uma versão do GKE que atingiu a data de fim do suporte.
  • Clusters que estão em um estado de execução, mas não mostram atividade por um longo período. Por exemplo, o GKE pode considerar um cluster sem chamadas de API, sem tráfego de rede e sem uso ativo de sub-redes como abandonado.
  • Clusters que apresentam instabilidade persistente e passam repetidamente por estados operacionais. Por exemplo, estados que fazem um loop de execução para degradado, em reparação ou suspenso e de volta à execução sem uma resolução.

Se você notar um upgrade automático inesperado e tiver dúvidas sobre o efeito que ele pode ter no seu cluster, entre em contato com o Cloud Customer Care para receber ajuda.

Resolver problemas de upgrades com falha

Quando o upgrade falha, o GKE gera mensagens de erro. As seções a seguir explicam as causas e as soluções para os seguintes erros:

Erro: kube-apiserver não está íntegro

Às vezes, a seguinte mensagem de erro aparece quando você inicia um upgrade manual do plano de controle da versão do GKE do cluster:

FAILED: All cluster resources were brought up, but: component
"KubeApiserverReady" from endpoint "readyz of kube apiserver is not successful"
is unhealthy.

Essa mensagem aparece na CLI gcloud e nas entradas de registro do tipo de recurso gke_cluster e gke_nodepool.

Esse problema ocorre quando alguns webhooks de admissão implantados pelo usuário impedem que os componentes do sistema criem os papéis permissivos do RBAC necessários para funcionar corretamente.

Durante um upgrade do plano de controle, o GKE recria o componente do servidor da API Kubernetes (kube-apiserver). Se um webhook bloquear a função RBAC do componente do servidor da API, o servidor da API não será iniciado e o upgrade do cluster não será concluído. Mesmo que um webhook esteja funcionando corretamente, ele pode causar falha no upgrade do cluster porque o plano de controle recém-criado pode não conseguir alcançar o webhook.

O Kubernetes reconhece automaticamente os papéis do RBAC do sistema padrão com as políticas padrão na versão secundária mais recente. As políticas padrão para papéis do sistema às vezes são alteradas em novas versões do Kubernetes.

Para realizar essa reconciliação, o GKE cria ou atualiza os ClusterRoles e ClusterRoleBindings no cluster. Se você tiver um webhook que intercepte e rejeite as solicitações de criação ou atualização em função do escopo das permissões usadas pelas políticas do RBAC padrão, o servidor de API não poderá funcionar na nova versão secundária.

Para identificar o webhook com falha, verifique os registros de auditoria do GKE em busca de chamadas de RBAC com as seguintes informações:

protoPayload.resourceName="RBAC_RULE"
protoPayload.authenticationInfo.principalEmail="system:apiserver"

Nessa saída, RBAC_RULE é o nome completo da função do RBAC, como rbac.authorization.k8s.io/v1/clusterroles/system:controller:horizontal-pod-autoscaler.

O nome do webhook com falha é exibido no registro com o seguinte formato:

admission webhook WEBHOOK_NAME denied the request

Para resolver esse problema, tente o seguinte:

  1. Revise seus ClusterRoles para garantir que eles não sejam muito restritivos. Suas políticas não podem bloquear as solicitações do GKE para criar ou atualizar os ClusterRoles com o prefixo system: padrão.
  2. Ajuste o webhook para não interceptar solicitações de criação e atualização de papéis do RBAC do sistema.
  3. Desative o webhook.

Erro: falha no DeployPatch

Às vezes, a operação de upgrade do cluster falha com o seguinte erro:

DeployPatch failed

Esse erro pode ocorrer se o plano de controle do Kubernetes permanecer em estado não íntegro por mais de 20 minutos.

Esse erro geralmente é temporário porque o plano de controle tenta novamente a operação até que ela seja concluída. Se o upgrade continuar falhando com esse erro, entre em contato com o Cloud Customer Care.

Resolver problemas após um upgrade concluído

Se você encontrar um comportamento inesperado após a conclusão do upgrade, as seções a seguir oferecem orientações para solucionar os seguintes problemas comuns:

Comportamento inesperado devido a mudanças interruptivas

Se o upgrade for concluído com êxito, mas você notar um comportamento inesperado depois de um upgrade, consulte as notas da versão do GKE para informações sobre bugs e mudanças interruptivas relacionadas à versão para a qual o cluster foi atualizado.

Cargas de trabalho removidas após o upgrade do cluster padrão

As cargas de trabalho correrão o risco de serem removidas após um upgrade de cluster se todas as condições a seguir forem verdadeiras:

  • As cargas de trabalho do sistema exigem mais espaço quando o plano de controle do cluster está executando a nova versão do GKE.
  • Seus nós atuais não têm recursos suficientes para executar as novas cargas de trabalho do sistema e as cargas de trabalho atuais.
  • O autoescalador está desativado para o cluster.

Para resolver esse problema, tente o seguinte:

  1. Ative o escalonamento automático para pools de nós atuais.
  2. Ative o provisionamento automático de nós.
  3. Crie um pool de nós.
  4. Escalone um pool de nós atual.

Pods travados no estado Pending após a configuração do nó alocável

Se você tiver configurado o Node Alocável, um upgrade de versão do nó pode fazer com que os pods que estavam no estado Running fiquem travados no estado Pending. Essa mudança geralmente ocorre porque o nó atualizado consome recursos do sistema ligeiramente diferentes ou porque os pods que foram reprogramados agora precisam se encaixar nos limites alocáveis do nó nos nós novos ou modificados, possivelmente em condições mais restritas.

Se os pods tiverem o status Pending após um upgrade, tente as seguintes soluções:

  1. Verifique se as solicitações de CPU e memória para seus pods não excedem o pico de uso. Com o GKE reservando CPU e memória para sobrecarga, os pods não podem solicitar esses recursos. Os pods que solicitam mais CPU ou memória do que usam impedem que outros pods solicitem esses recursos e podem deixar o cluster subutilizado. Para mais informações, consulte Como programar pods com solicitações de recursos na documentação do Kubernetes.
  2. Considere aumentar o tamanho do cluster.
  3. Para verificar se o upgrade é a causa desse problema, reverta o upgrade fazendo downgrade dos pools de nós.
  4. Configure o cluster para enviar métricas do programador do Kubernetes para o Cloud Monitoring e ver métricas do programador. Ao monitorar essas métricas, você pode determinar se há recursos suficientes para a execução dos pods.

Resolver problemas de versão e compatibilidade

Manter versões compatíveis e com suporte para todos os componentes do cluster é essencial para a estabilidade e o desempenho. As seções a seguir fornecem orientações sobre como identificar e resolver problemas de controle de versão e compatibilidade que podem afetar o processo de upgrade.

Verificar a incompatibilidade entre a versão do plano de controle e do nó

A distorção de versão entre o plano de controle e os nós pode causar instabilidade no cluster. A política de distorção de versão do GKE afirma que um plano de controle só é compatível com nós de até duas versões secundárias anteriores. Por exemplo, um plano de controle 1.19 funciona com nós 1.19, 1.18 e 1.17.

Se os nós estiverem fora dessa janela de suporte, você corre o risco de ter problemas críticos de compatibilidade. Esses problemas geralmente estão relacionados à API. Por exemplo, uma carga de trabalho em um nó mais antigo pode usar uma versão da API que foi descontinuada ou removida no plano de controle mais recente. Essa incompatibilidade também pode levar a falhas mais graves, como um caminho de rede corrompido que impede que os nós se registrem no cluster se uma carga de trabalho incompatível interromper a comunicação.

Periodicamente, a equipe do GKE realiza upgrades do plano de controle do cluster em seu nome. Os planos de controle são atualizados para versões estáveis mais recentes do Kubernetes. Para garantir que os nós permaneçam compatíveis com o plano de controle atualizado, eles também precisam ser mantidos atualizados. Por padrão, o GKE processa esse upgrade porque os nós de um cluster têm o upgrade automático ativado, e recomendamos que ele não seja desativado. Se o upgrade automático estiver desativado para os nós de um cluster e você não fizer o upgrade manual deles, o plano de controle vai se tornar incompatível com os nós.

Para confirmar se as versões do plano de controle e do nó são incompatíveis, verifique qual versão do Kubernetes o plano de controle e os pools de nós do cluster estão executando:

gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID  \
    --location LOCATION

Substitua:

  • CLUSTER_NAME: o nome do cluster do pool de nós a ser descrito.
  • PROJECT_ID: o ID do projeto do cluster.
  • LOCATION: a região ou zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) do cluster.

O resultado será assim:

…
currentMasterVersion: 1.32.3-gke.1785003
…
currentNodeVersion: 1.26.15-gke.1090000
…

Neste exemplo, a versão do plano de controle e a versão do pool de nós são incompatíveis.

Para resolver esse problema, faça upgrade manual da versão do pool de nós para uma versão compatível com o plano de controle.

Se você acha que o processo de upgrade está causando a interrupção das cargas de trabalho em execução nos nós afetados, siga as etapas abaixo para migrar as cargas de trabalho para um novo pool de nós:

  1. Crie um novo pool de nós com uma versão compatível.
  2. Demarque os nós do pool de nós existente.
  3. Opcional: atualize as cargas de trabalho em execução no pool de nós atual para adicionar um nodeSelector para o rótulo cloud.google.com/gke-nodepool:NEW_NODE_POOL_NAME. Substitua NEW_NODE_POOL_NAME pelo nome do novo pool de nós. Essa ação garante que o GKE coloque essas cargas de trabalho em nós no novo pool de nós.
  4. Esvazie o pool de nós atual.
  5. Verifique se as cargas de trabalho estão sendo executadas corretamente no novo pool de nós. Se estiverem, exclua o antigo pool de nós. Se você notar interrupções de carga de trabalho, reprograme as cargas de trabalho nos nós atuais removendo a restrição dos nós no pool de nós atual e drenando os novos nós.

O uso da CPU do nó está acima do esperado

Talvez você encontre um problema em que alguns nós estão usando mais CPU do que o esperado dos pods em execução.

Esse problema pode ocorrer se você usar upgrades manuais e os clusters ou nós não tiverem sido atualizados para executar uma versão compatível. Revise as notas de lançamento para garantir que as versões usadas estejam disponíveis e sejam compatíveis.

A seguir

  • Se você não encontrar uma solução para seu problema na documentação, consulte Receber suporte para mais ajuda, incluindo conselhos sobre os seguintes tópicos: