Resolva problemas de atualizações de clusters

Se a atualização do plano de controlo ou do conjunto de nós do Google Kubernetes Engine (GKE) falhar, ficar bloqueada ou causar um comportamento inesperado da carga de trabalho, pode ter de resolver problemas do processo. Manter o plano de controlo e os conjuntos de nós atualizados é essencial para a segurança e o desempenho, e a resolução de quaisquer problemas ajuda a garantir que o seu ambiente permanece estável.

Para resolver problemas comuns de atualização, um bom primeiro passo é monitorizar o processo de atualização do cluster. Em seguida, pode encontrar sugestões sobre como resolver o problema:

Estas informações são importantes para os administradores e os operadores da plataforma que querem diagnosticar as causas principais das atualizações bloqueadas ou falhadas, gerir as políticas de manutenção e resolver incompatibilidades de versões. Os programadores de aplicações podem encontrar orientações sobre a resolução de problemas de carga de trabalho pós-atualização e compreender como as configurações de carga de trabalho, como PodDisruptionBudgets, podem afetar a duração da atualização. Para mais informações sobre as funções comuns e as tarefas de exemplo a que fazemos referência no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Trusted Cloud by S3NS

Monitorize o processo de atualização do cluster

Para resolver problemas de atualização de forma mais eficaz, comece por compreender o que aconteceu durante o processo de atualização. O GKE oferece várias ferramentas que lhe dão visibilidade neste processo.

Na Trusted Cloud consola, o painel de controlo de atualizações oferece uma vista ao nível do projeto de todas as atualizações de clusters em curso, uma cronologia de eventos recentes e avisos sobre potenciais bloqueios, como exclusões de manutenção ativas ou descontinuações de versões futuras. Para verificações automatizadas ou de linha de comandos, pode usar o comando gcloud container operations list para obter o estado de operações de atualização específicas. Para mais informações, consulte o artigo Obtenha visibilidade das atualizações do cluster.

Para uma investigação mais detalhada, o Cloud Logging é a sua principal fonte de informações. O GKE regista informações detalhadas sobre os processos de atualização do plano de controlo e do conjunto de nós no Cloud Logging. Isto inclui registos de auditoria de nível elevado que monitorizam as principais operações de atualização, bem como registos mais detalhados, como eventos do Kubernetes e registos de componentes de nós, que podem mostrar-lhe mais informações sobre erros específicos.

As secções seguintes explicam como consultar estes registos através do Explorador de registos ou da CLI gcloud. Para mais informações, consulte o artigo Verifique os registos de atualização.

Identifique a operação de atualização com os registos de auditoria

Se não souber que operação de atualização falhou, pode usar os registos de auditoria do GKE. Os registos de auditoria monitorizam as ações administrativas e fornecem um registo autorizado de quando foi iniciada uma atualização e o respetivo estado final. Use as seguintes consultas no Explorador de registos para encontrar a operação relevante.

Tipo de evento Consulta do registo
Atualização automática do plano de controlo 
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 quer investigar.

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

 
Atualização automática de node pool (apenas 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 conjunto de nós que pertence ao cluster.
Atualização manual do node pool 
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 node pool, verifique os registos da API Kubernetes:

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

Encontre mensagens de erro detalhadas nos registos do GKE

Depois de o registo de auditoria lhe mostrar que operação falhou e quando, pode pesquisar mensagens de erro mais detalhadas dos componentes do GKE por volta da mesma hora. Estes registos podem conter os motivos específicos de uma falha na atualização, como um objeto PodDisruptionBudget mal configurado.

Por exemplo, depois de encontrar uma operação UPGRADE_NODES falhada nos registos de auditoria, pode usar a respetiva data/hora para restringir a pesquisa. No Explorador de registos, introduza a consulta seguinte e, em seguida, use o seletor do intervalo de tempo para se concentrar no momento em que ocorreu a falha:

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

Substitua o seguinte:

  • CLUSTER_NAME: o nome do cluster.
  • NODE_NAME: o nome do nó no cluster que quer verificar quanto a erros.

Use a CLI gcloud para ver eventos de atualização

Além do Explorador de registos, pode usar comandos da CLI gcloud para rever eventos de atualização.

Para procurar atualizações do plano de controlo, execute o seguinte comando:

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

O resultado é semelhante ao seguinte:

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 a zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) para o cluster.
  • CLUSTER_NAME: o nome do cluster.

Para procurar atualizações do conjunto de nós, execute o seguinte comando:

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

O resultado é semelhante ao seguinte:

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: use registos para resolver problemas de atualizações do plano de controlo

O exemplo seguinte mostra como usar os registos para resolver problemas de uma atualização do plano de controlo sem êxito:

  1. Na Trusted Cloud consola, aceda à página Explorador de registos.

    Aceda ao Explorador de registos

  2. No painel de consultas, filtre os registos de atualização do plano de controlo introduzindo 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 quer investigar.

  3. Clique em Executar consulta.

  4. Reveja a saída do registo para ver as seguintes informações:

  5. Confirme se a atualização foi iniciada: procure eventos UPGRADE_MASTER recentes na altura em que iniciou a atualização. A presença destes eventos confirma que o processo de atualização foi acionado por si ou pelo GKE.

    • Valide as versões: verifique os seguintes campos para confirmar as versões anteriores e de destino:

      • protoPayload.metadata.previousMasterVersion: mostra a versão do plano de controlo antes da atualização.

      • protoPayload.metadata.currentMasterVersion: mostra a versão para a qual o GKE tentou atualizar o plano de controlo.

        Por exemplo, se pretendia atualizar 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 as suas cargas de trabalho), a revisão destes dois campos realçaria esta discrepância. Em alternativa, se o campo currentMasterVersion continuar a apresentar a versão anterior após um período prolongado, esta descoberta indica que a atualização não aplicou a nova versão.

    • Procure erros: verifique se existem eventos UPGRADE_MASTER repetidos ou outras mensagens de erro. Se o registo de operações parar sem indicar a conclusão ou a falha, esta descoberta indica um problema.

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

Resolva problemas de atualizações de node pools que demoram mais do que o habitual

Se a atualização do conjunto de nós estiver a demorar mais tempo do que o esperado, experimente as seguintes soluções:

  1. Verifique o valor de terminationGracePeriodSeconds no manifesto dos seus pods. Este valor define o tempo máximo que o Kubernetes aguarda que um pod seja encerrado corretamente. Um valor elevado (por exemplo, alguns minutos) pode prolongar significativamente as durações das atualizações, porque o Kubernetes aguarda o período completo para cada pod. Se este atraso estiver a causar problemas, considere reduzir o valor.

  2. Verifique os seus objetos PodDisruptionBudget. Quando um nó está a ser esvaziado, o GKE aguarda, no máximo, uma hora por nó para expulsar as respetivas cargas de trabalho de forma graciosa. Se o seu objeto PodDisruptionBudget for demasiado restritivo, pode impedir que uma remoção elegante seja bem-sucedida. Neste cenário, o GKE usa todo o período de tolerância de uma hora para tentar esgotar o nó antes de expirar o tempo limite e forçar a atualização a prosseguir. Este atraso, quando repetido em vários nós, é uma causa comum de uma atualização geral do cluster lenta. Para confirmar se um objeto restritivo PodDisruptionBudget é a causa das atualizações lentas, use o Explorador de registos:

    1. Na Trusted Cloud consola, aceda à página Explorador de registos.

      Aceda ao Explorador de registos

    2. No painel de consultas, introduza 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. Reveja o resultado do registo. Se o objeto PodDisruptionBudget for a causa do problema, o resultado é semelhante ao seguinte:

      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 certifique-se de que as definições são adequadas:

      kubectl get pdb --all-namespaces

      O resultado é semelhante ao seguinte:

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

      Neste exemplo, o PodDisruptionBudget denominado one_pdb requer um mínimo de três agrupamentos disponíveis. Uma vez que a remoção de um Pod durante a atualização deixaria apenas dois Pods disponíveis, a ação viola o orçamento e faz com que a atualização fique bloqueada.

      Se o objeto PodDisruptionBudget estiver a funcionar da forma pretendida, não tem de fazer nada. Se não for o caso, considere flexibilizar as definições PodDisruptionBudget durante o período de atualização.

  3. Verifique as afinidades dos nós. As regras restritivas podem atrasar as atualizações, impedindo que os pods sejam reagendados para nós disponíveis se esses nós não corresponderem às etiquetas necessárias. Este problema é particularmente problemático durante as atualizações rápidas, porque as afinidades de nós podem limitar o número de nós que podem ser atualizados em simultâneo se os nós com as etiquetas corretas não tiverem capacidade do cluster suficiente para alojar os novos pods.

  4. Verifique se usa a estratégia de atualização de curta duração. O GKE usa a estratégia de atualização de curta duração para nós de início flexível e para nós que usam apenas aprovisionamento em fila em clusters que executam a versão 1.32.2-gke.1652000 ou posterior do GKE. Se usar esta estratégia de atualização, a operação de atualização pode demorar até sete dias.

  5. Verifique se usa pods de duração prolongada (disponíveis para clusters do Autopilot). Durante uma atualização, o GKE tem de esvaziar todos os pods de um nó antes de o processo poder ser concluído. No entanto, durante uma atualização iniciada pelo GKE, o GKE não remove os pods de duração prolongada durante um período máximo de sete dias. Esta proteção impede a drenagem do nó. O GKE termina o pod à força apenas após este período terminar, e este atraso significativo de vários dias para um único nó pode atrasar mais atualizações de nós no cluster do Autopilot.

  6. Os volumes persistentes anexados podem fazer com que um processo de atualização demore mais tempo do que o habitual devido ao tempo necessário para gerir o ciclo de vida destes volumes.

  7. Verifique o estado da atualização automática do cluster. Se o motivo for SYSTEM_CONFIG, as atualizações automáticas são pausadas temporariamente por motivos técnicos ou empresariais. Se vir este motivo, recomendamos que não faça uma atualização manual, a menos que seja necessário.

Resolva problemas de atualizações incompletas de node pools

Ocasionalmente, o GKE não consegue concluir uma atualização do node pool, deixando o node pool parcialmente atualizado. Existem vários motivos que causam atualizações incompletas:

  • A atualização foi cancelada manualmente.
  • A atualização falhou devido a um problema, como a falha no registo de novos nós, o esgotamento do endereço IP ou quotas de recursos insuficientes.
  • O GKE pausou a atualização. Esta pausa pode ocorrer, por exemplo, para evitar uma atualização para uma versão com problemas conhecidos ou durante determinados períodos de manutenção iniciados pela Google.
  • Se usar atualizações automáticas, um período de manutenção terminou antes de a atualização poder ser concluída. Em alternativa, um período de exclusão de manutenção foi iniciado antes de a atualização poder ser concluída. Para mais informações, consulte o artigo Janela de manutenção que impede a conclusão da atualização do nó.

Quando um conjunto de nós é atualizado parcialmente, os nós são executados em versões diferentes. Para resolver este problema e verificar se todos os nós no conjunto de nós são executados na mesma versão, pode retomar a atualização ou reverter a atualização.

No entanto, a estratégia de atualizações de picos e a estratégia de atualizações azul-verde interagem com as janelas de manutenção de forma diferente:

  • Atualizações rápidas: a operação de atualização é pausada se for executada fora do período de manutenção. A atualização é retomada automaticamente durante o período de manutenção agendado seguinte.
  • Atualizações azul-verde: a operação de atualização continua até à conclusão, mesmo que exceda o período de manutenção. As atualizações azul-verde oferecem um controlo detalhado sobre o ritmo de atualização com funcionalidades como os tempos de saturação dos lotes e dos conjuntos de nós, e o conjunto de nós adicional ajuda a garantir que as cargas de trabalho permanecem operacionais.

Resolva problemas de comportamento de atualização automática inesperado

Por vezes, as atualizações automáticas dos clusters não ocorrem da forma esperada. As secções seguintes ajudam a resolver os seguintes problemas:

A atualização dos clusters falha quando a atualização automática de nós está ativada

Se não desativou a atualização automática de nós, mas não ocorre uma atualização, experimente as seguintes soluções:

  1. Se usar um canal de lançamento, verifique se as atualizações automáticas de nós não estão bloqueadas. Para clusters inscritos num canal de lançamento, o maintenancePolicy é a principal forma de controlar as atualizações automáticas. Pode impedir o início de uma atualização ou interromper uma que já esteja em curso. Uma exclusão de manutenção ativa pode bloquear completamente uma atualização, e o momento de uma janela de manutenção pode causar uma interrupção. Reveja as suas maintenancePolicy para determinar se alguma destas definições é a causa:

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

    Substitua o seguinte:

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

    O resultado é semelhante ao seguinte:

    …
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
…

    No resultado, reveja a secção maintenancePolicy para as duas condições seguintes:

    • Para ver se uma atualização está bloqueada: procure um maintenanceExclusion ativo com um âmbito NO_MINOR_OR_NODE_UPGRADES. Geralmente, esta definição impede que o GKE inicie uma nova atualização.
    • Para ver se uma atualização foi interrompida: verifique a agenda do seu dailyMaintenanceWindow ou maintenanceExclusions. Se uma atualização for executada para além do período agendado, o GKE pausa a atualização, resultando numa atualização parcial. Para mais informações sobre atualizações parciais, consulte a secção Resolva problemas de atualizações incompletas.

    Para resolver estes problemas, pode aguardar que uma exclusão termine, removê-la ou ajustar os períodos de manutenção para permitir mais tempo para a conclusão das atualizações.

  2. Se não usar um canal de lançamento, verifique se a atualização automática ainda está ativada para o conjunto de nós:

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

    Substitua NODE_POOL_NAME pelo nome do grupo de nós a descrever.

    Se as atualizações automáticas do conjunto de nós estiverem ativadas para este conjunto de nós, o resultado no campo autoUpgrade é o seguinte:

    management:
  autoUpgrade: true

    Se autoUpgrade estiver definido como false ou o campo não estiver presente, ative as atualizações automáticas.

  3. A atualização pode não ter sido implementada na região ou na zona onde o seu cluster está localizado, mesmo que a atualização tenha sido mencionada nas notas de lançamento. As atualizações do GKE são implementadas progressivamente ao longo de vários dias (normalmente, quatro ou mais). Depois de a atualização chegar à sua região ou zona, a atualização só começa durante os períodos de manutenção aprovados. Por exemplo, uma implementação pode alcançar a zona do cluster no primeiro dia da implementação, mas o próximo período de manutenção do cluster só ocorre no sétimo dia. Neste cenário, o GKE não atualiza o cluster até ao sétimo dia. Para mais informações, consulte a agenda de lançamentos do GKE.

Os clusters são atualizados automaticamente quando a atualização automática não está ativada

Para ajudar a manter a fiabilidade, a disponibilidade, a segurança e o desempenho do seu ambiente do GKE, o GKE pode atualizar automaticamente os seus clusters, mesmo que não use atualizações automáticas.

O GKE pode ignorar os seus períodos de manutenção, exclusões ou atualizações automáticas do conjunto de nós desativadas para realizar as atualizações necessárias por vários motivos críticos, como os seguintes:

  • Clusters cujos planos de controlo estão a executar uma versão do GKE que atingiu a data de fim do suporte técnico. Para confirmar que o seu cluster está a aproximar-se da data de fim do apoio técnico, consulte o cronograma estimado para os canais de lançamento.
  • Nós num cluster que estão a executar uma versão do GKE que atingiu a data de fim do suporte.
  • Clusters que estão em estado de execução, mas não mostram atividade durante um período prolongado. Por exemplo, o GKE pode considerar um cluster com sem chamadas API, sem tráfego de rede e sem utilização ativa de sub-redes como abandonado.
  • Clusters que apresentam instabilidade persistente que passa repetidamente por estados operacionais. Por exemplo, estados que entram em ciclo desde o estado de funcionamento até ao estado degradado, de reparação ou suspenso e voltam ao estado de funcionamento sem uma resolução.

Se observar uma atualização automática inesperada e tiver dúvidas sobre o efeito que esta atualização possa ter no seu cluster, contacte o apoio ao cliente do Google Cloud para receber assistência.

Resolva problemas de atualizações com falhas

Quando a atualização falha, o GKE produz mensagens de erro. As secções seguintes explicam as causas e as resoluções dos seguintes erros:

Erro: kube-apiserver não está em bom estado

Por vezes, pode ver a seguinte mensagem de erro quando inicia uma atualização manual do plano de controlo 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.

Esta mensagem aparece na CLI gcloud e nas entradas de registo do tipo de recurso gke_cluster e gke_nodepool.

Este problema ocorre quando alguns webhooks de admissão implementados pelo utilizador impedem que os componentes do sistema criem as funções RBAC permissivas necessárias para funcionar corretamente.

Durante uma atualização do plano de controlo, o GKE recria o componente do servidor da API Kubernetes (kube-apiserver). Se um webhook bloquear a função RBAC para o componente do servidor da API, o servidor da API não é iniciado e a atualização do cluster não é concluída. Mesmo que um webhook esteja a funcionar corretamente, pode fazer com que a atualização do cluster falhe porque o plano de controlo recém-criado pode não conseguir alcançar o webhook.

O Kubernetes reconcilia automaticamente as funções RBAC do sistema predefinidas com as políticas predefinidas na versão secundária mais recente. As políticas predefinidas para funções do sistema mudam por vezes em novas versões do Kubernetes.

Para realizar esta conciliação, o GKE cria ou atualiza os ClusterRoles e os ClusterRoleBindings no cluster. Se tiver um webhook que interceta e rejeita os pedidos de criação ou atualização devido ao âmbito das autorizações que as políticas RBAC predefinidas usam, o servidor da API não pode funcionar na nova versão secundária.

Para identificar o webhook com falhas, verifique os registos de auditoria do GKE para chamadas RBAC com as seguintes informações:

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

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

O nome do webhook com falhas é apresentado no registo no seguinte formato:

admission webhook WEBHOOK_NAME denied the request

Para resolver este problema, experimente as seguintes soluções:

  1. Reveja os ClusterRoles para garantir que não são demasiado restritivos. As suas políticas não devem bloquear os pedidos do GKE para criar ou atualizar os ClusterRoles com o prefixo system: predefinido.
  2. Ajuste o webhook para não intercetar pedidos de criação e atualização de funções RBAC do sistema.
  3. Desative o webhook.

Erro: DeployPatch falhou

Por vezes, a operação de atualização do cluster falha com o seguinte erro:

DeployPatch failed

Este erro pode ocorrer se o plano de controlo do Kubernetes permanecer em mau estado durante mais de 20 minutos.

Este erro é frequentemente temporário porque o plano de controlo tenta novamente a operação até ter êxito. Se a atualização continuar a falhar com este erro, contacte o apoio ao cliente da nuvem.

Resolva problemas após uma atualização concluída

Se encontrar um comportamento inesperado após a conclusão da atualização, as secções seguintes oferecem orientações de resolução de problemas para os seguintes problemas comuns:

Comportamento inesperado devido a alterações significativas

Se a atualização for concluída com êxito, mas notar um comportamento inesperado após a atualização, consulte as notas de lançamento do GKE para ver informações sobre erros e alterações significativas relacionadas com a versão para a qual o cluster foi atualizado.

Cargas de trabalho desalojadas após a atualização do cluster padrão

As suas cargas de trabalho podem estar em risco de despejo após uma atualização do cluster se todas as seguintes condições forem verdadeiras:

  • As cargas de trabalho do sistema requerem mais espaço quando o plano de controlo do cluster está a executar a nova versão do GKE.
  • Os seus nós existentes não têm recursos suficientes para executar as novas cargas de trabalho do sistema e as cargas de trabalho existentes.
  • O redimensionador automático de clusters está desativado para o cluster.

Para resolver este problema, experimente as seguintes soluções:

  1. Ative a escala automática para node pools existentes.
  2. Ative o aprovisionamento automático de nós.
  3. Crie um novo node pool.
  4. Aumente a escala de um conjunto de nós existente.

Pods bloqueados no estado Pending após a configuração de Node Allocatable

Se tiver configurado o Node Allocatable, por vezes, uma atualização da versão do nó pode fazer com que os pods que tinham um estado Running fiquem bloqueados num estado Pending. Normalmente, esta alteração ocorre porque o nó atualizado consome recursos do sistema ligeiramente diferentes ou porque os pods que foram reagendados têm agora de se enquadrar nos limites de recursos atribuíveis do nó nos nós novos ou modificados, potencialmente em condições mais rigorosas.

Se os seus Pods tiverem o estado Pending após uma atualização, experimente as seguintes soluções:

  1. Verifique se os pedidos de CPU e memória dos seus pods não excedem a respetiva utilização máxima. Com o GKE a reservar a CPU e a memória para a sobrecarga, os pods não podem pedir estes recursos. Os pods que pedem mais CPU ou memória do que usam impedem que outros pods peçam estes recursos e podem deixar o cluster subutilizado. Para mais informações, consulte o artigo Como são agendados os pods com pedidos de recursos na documentação do Kubernetes.
  2. Considere aumentar o tamanho do cluster.
  3. Para verificar se a atualização é a causa deste problema, reverta a atualização reduzindo os seus conjuntos 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 monitorizar estas métricas, pode determinar se existem recursos suficientes para a execução dos pods.

Resolva problemas de versão e compatibilidade

A manutenção de versões suportadas e compatíveis para todos os componentes do cluster é essencial para a estabilidade e o desempenho. As secções seguintes fornecem orientações sobre como identificar e resolver problemas de controlo de versões e compatibilidade que podem afetar o processo de atualização.

Verifique a incompatibilidade entre a versão do plano de controlo e do nó

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

Se os seus nós estiverem fora desta janela suportada, corre o risco de ter problemas de compatibilidade críticos. Estes problemas estão frequentemente relacionados com a API. Por exemplo, uma carga de trabalho num nó mais antigo pode usar uma versão da API que foi descontinuada ou removida no plano de controlo mais recente. Esta incompatibilidade também pode levar a falhas mais graves, como um caminho de rede danificado que impede o registo dos nós no cluster se uma carga de trabalho incompatível interromper a comunicação.

Periodicamente, a equipa do GKE realiza atualizações do painel de controlo do cluster em seu nome. Os planos de controlo são atualizados para versões estáveis mais recentes do Kubernetes. Para garantir que os seus nós permanecem compatíveis com o plano de controlo atualizado, também têm de ser mantidos atualizados. Por predefinição, o GKE processa esta atualização porque os nós de um cluster têm a atualização automática ativada, e recomendamos que não a desative. Se a atualização automática estiver desativada para os nós de um cluster e não os atualizar manualmente, o painel de controlo torna-se incompatível com os nós.

Para confirmar se as versões do plano de controlo e dos nós são incompatíveis, verifique a versão do Kubernetes que o plano de controlo e os conjuntos de nós do cluster estão a executar:

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

Substitua o seguinte:

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

O resultado é semelhante ao seguinte:

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

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

Para resolver este problema, atualize manualmente a versão do conjunto de nós para uma versão compatível com o plano de controlo.

Se tiver preocupações sobre o processo de atualização causar interrupções nas cargas de trabalho em execução nos nós afetados, conclua os seguintes passos para migrar as suas cargas de trabalho para um novo conjunto de nós:

  1. Crie um novo conjunto de nós com uma versão compatível.
  2. Isolar os nós do node pool existente.
  3. Opcional: atualize as cargas de trabalho em execução no node pool existente para adicionar um nodeSelector para a etiqueta cloud.google.com/gke-nodepool:NEW_NODE_POOL_NAME. Substitua NEW_NODE_POOL_NAME pelo nome do novo conjunto de nós. Esta ação garante que o GKE coloca essas cargas de trabalho em nós no novo conjunto de nós.
  4. Esvazie o node pool existente.
  5. Verifique se as cargas de trabalho estão a ser executadas com êxito no novo conjunto de nós. Se for o caso, pode eliminar o conjunto de nós antigo. Se notar interrupções na carga de trabalho, reagende as cargas de trabalho nos nós existentes desativando a restrição dos nós no conjunto de nós existente e esvaziando os novos nós.

A utilização da CPU do nó é superior ao esperado

Pode encontrar um problema em que alguns nós estão a usar mais CPU do que o esperado dos pods em execução.

Este problema pode ocorrer se usar atualizações manuais e os seus clusters ou nós não tiverem sido atualizados para executar uma versão suportada. Reveja as notas de lançamento para garantir que as versões que usa estão disponíveis e são suportadas.

O que se segue?