Problemas conhecidos do GKE

Esta página apresenta uma lista de problemas conhecidos do GKE. Esta página destina-se a administradores e arquitetos que gerem o ciclo de vida da infraestrutura tecnológica subjacente e respondem a alertas e páginas quando os objetivos de nível de serviço (SLOs) não são cumpridos ou as aplicações falham.

Esta página apresenta uma lista de problemas conhecidos para todas as versões suportadas e para as duas versões secundárias que precedem imediatamente a versão mais antiga no suporte alargado. Quando uma versão atinge o fim do apoio técnico alargado, todos os problemas N-2 são removidos. Por exemplo, quando a versão 1.30 atinge o fim do apoio técnico alargado, os problemas conhecidos específicos das versões 1.28 e anteriores são removidos.

Se fizer parte do Google Developer Program, guarde esta página para receber notificações quando for publicada uma nota de lançamento relacionada com esta página. Para saber mais, consulte Páginas guardadas.

Para filtrar os problemas conhecidos por uma versão ou categoria do produto, selecione os filtros nos seguintes menus pendentes.

Selecione a sua versão do GKE:

Selecione a categoria do problema:

Em alternativa, pesquise o seu problema:

Categoria Versões identificadas Versões corrigidas Problema e solução alternativa
Operação 1.33 versões anteriores à 1.33.4-gke.1036000 1.33.4-gke.1036000 e posteriores

Nível de desempenho incorreto para instâncias Lustre aprovisionadas dinamicamente

Quando aprovisiona dinamicamente uma instância do Lustre, a criação da instância falha com um erro InvalidArgument para PerUnitStorageThroughput, independentemente do valor perUnitStorageThroughput especificado no pedido da API.

Solução alternativa:

Atualize o cluster do GKE para a versão 1.33.4-gke.1036000 ou posterior. Se estiver a usar o canal estável, pode ainda não estar disponível uma versão mais recente. Neste caso, pode selecionar manualmente uma versão dos canais Regular ou Rápido que inclua a correção.
Operação
  • 1.32.3-gke.1099000 e posteriores
  • 1,33
 1.33.3-gke.1266000 e posteriores

Erro de entrada/saída ao mudar o nome ou mover ficheiros com o controlador CSI do FUSE do Cloud Storage

Quando usar uma versão afetada do controlador CSI do FUSE do Cloud Storage, a mudança do nome ou a movimentação de ficheiros em contentores do Cloud Storage pode falhar com um erro de E/S.

Solução alternativa:

Adicione temporariamente uma definição de imagem sidecar específica ao manifesto do pod. Na secção spec.containers do manifesto do pod, adicione a seguinte definição do contentor com a imagem: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2.

    # Add the following block to use the fixed sidecar image
    - name: gke-gcsfuse-sidecar
      image: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2

Para mais informações, consulte o manifesto do pod em Configure uma imagem privada para o contentor sidecar.

Depois de atualizar o cluster para uma versão fixa do GKE ou posterior, tem de remover todo o bloco gke-gcsfuse-sidecar do manifesto. Após remover este bloqueio, o GKE retoma a injeção e a gestão automáticas da imagem do sidecar correta para a versão atualizada do cluster.
Registo e monitorização Todas as versões A determinar

Condição de corrida em DaemonSets do gke-metrics-agent

Quando adiciona a etiqueta cloud.google.com/gke-metrics-agent-scaling-level a um conjunto de nós para aumentar manualmente a atribuição de memória do gke-metrics-agent DaemonSet, ocorre uma condição de corrida no DaemonSet durante a criação de um novo nó. Esta condição de concorrência resulta em reinícios intermitentes e pode resultar na perda de métricas.

Este problema ocorre porque existe um atraso antes de a etiqueta ser adicionada a um novo nó no conjunto de nós. Durante este atraso, o DaemonSet cria um pod com a alocação de memória original nesse nó. Depois de a etiqueta ser aplicada, o DaemonSet cria um pod com a nova atribuição de memória. O agrupamento existente não é completamente eliminado quando o agrupamento atualizado é iniciado. Ambos os pods tentam associar-se ao mesmo número de porta.

Solução alternativa:

Depois de adicionar a etiqueta cloud.google.com/gke-metrics-agent-scaling-level a um conjunto de nós, reinicie o DaemonSet gke-metrics-agent:

kubectl -n kube-system rollout restart daemonset gke-metrics-agent
Atualizações 1,33 1.33.2-gke.1043000

Limite de ficheiros abertos reduzido com o containerd 2.0

Para os conjuntos de nós que executam a versão 1.33 do GKE, que usa o containerd 2.0, o limite flexível predefinido para ficheiros abertos (ulimit -n) para contentores é reduzido para 1024.

Esta é uma alteração no próprio containerd (consulte o containerd PR #8924), em que LimitNOFILE foi removido de containerd.service como prática recomendada, o que faz com que o limite flexível do sistema predefinido seja aplicado.

As cargas de trabalho que esperam um limite flexível predefinido mais elevado (por exemplo, as que dependem implicitamente do predefinido mais elevado anterior) podem sofrer falhas, como erros Too many open files.

Solução:

Atualize de uma versão de patch 1.33 anterior para a versão 1.33.2-gke.1043000 ou posterior.

Solução alternativa:

Aumente o limite de ficheiros abertos para as suas cargas de trabalho através de um dos seguintes métodos:

  • Ajuste ao nível da aplicação: modifique o código ou a configuração da aplicação para definir explicitamente o ulimit -n ou o prlimit --nofile=524288.
  • Plugin Containerd NRI Ulimit Adjuster Use o plugin containerd/nri ulimit-adjusterpara ajustar o ulimit.
  • Reduza a versão do conjunto de nós (apenas para o Standard): para clusters do GKE Standard, pode reduzir temporariamente a versão do conjunto de nós para a versão 1.32 para evitar este problema até que esteja disponível uma resolução permanente.
Para mais informações sobre a migração para o containerd 2, consulte o artigo Migre nós para o containerd 2.
Atualizações 1.31.5-gke.1169000, 1.32.1-gke.1376000 1.31.7-gke.1164000, 1.32.3-gke.1512000

Invalid CRD status.storedVersions for managed CRDs

Alguns CRDs geridos pelo GKE podem ter um campo status.storedVersions inválido, o que cria um risco de quebra do acesso a objetos CRD após uma atualização.

Este problema afeta clusters que se enquadram nas seguintes situações:

  • Clusters que usaram uma versão do GKE afetada em algum momento.
  • Clusters que tinham versões não suportadas (served=false) de objetos CRD armazenados no etcd.

Solução alternativa:

A solução alternativa recomendada é atrasar as atualizações do cluster até o problema ser resolvido.

Em alternativa, se souber que o cluster contém versões não suportadas de objetos CRD, pode adicionar estas versões ao campo status.storedVersions através do comando kubectl patch.
Funcionamento, registo e monitorização 1.32.2-gke.1652000, 1.31.6-gke.1221000, 1.30.10-gke.1227000
  • 1.32.2-gke.1652003 ou posterior
  • 1.31.6-gke.1221001 ou posterior
  • 1.30.10-gke.1227001 ou posterior

Métricas em falta ou o redimensionador automático de cargas de trabalho não está a ajustar a escala

Pode observar lacunas nos dados de métricas nas versões afetadas depois de o tamanho do cluster aumentar mais de cinco nós. Este problema também pode afetar as operações de dimensionamento automático.

Este problema afeta apenas os clusters atualizados para as versões afetadas. Os clusters criados recentemente devem funcionar conforme esperado.

Solução alternativa:

Se for afetado, pode reverter uma versão de patch ou atualizar para as versões corrigidas mais recentes.
Operação

Limites de tamanho e anexos do Google Cloud Hyperdisk

Normalmente, um pod que não pode ser agendado com êxito devido aos limites de associação de volume de um nó aciona o aprovisionamento automático de um novo nó. Quando as cargas de trabalho que usam um produto Hyperdisk são agendadas para um nó que executa uma VM C3, o aprovisionamento automático de nós não ocorre e o pod é agendado para o nó já cheio.

A carga de trabalho está agendada no nó, apesar da falta de uma ligação de disco disponível. A carga de trabalho também não é iniciada devido a um erro semelhante ao seguinte:

 AttachVolume.Attach failed for volume "[VOLUME NAME]" : rpc error: code = InvalidArgument desc = Failed to Attach: failed when waiting for zonal op: rpc error: code = InvalidArgument desc = operation operation-[OPERATION NUMBERS] failed (UNSUPPORTED_OPERATION): Maximum hyperdisk-balanced disks count should be less than or equal to [16], Requested : [17]

O problema está presente em todos os produtos Hyperdisk em máquinas C3.

Os limites de associação do Hyperdisk variam consoante o número de vCPUs da VM e o produto Hyperdisk. Para mais informações, consulte os limites de desempenho do Hyperdisk.

Solução alternativa:

Os produtos Hyperdisk acionam o aprovisionamento automático noutros formatos de VMs. Recomendamos um formato que suporte apenas o Hyperdisk.
Operação 1.32.3-gke.1927000, 1.32.3-gke.1785000, 1.32.3-gke.1717000, 1.32.3-gke.1440000, 1.32.3-gke.1170000, 1.32.3-gke.1250000, 1.32.3-gke.1671000, 1.32.3-gke.1596000, 1.32.3-gke.1298000

O gke-metadata-server é OOMKilled em nós de TPU/GPU

Nos nós de TPU do GKE (por exemplo, ct4p-hightpu-4t) e nos nós de GPU (por exemplo, a3-highgpu-8g), o kernel pode terminar o gke-metadata-server com um OOMKilled quando a utilização de memória do servidor excede 100 MB.

Solução alternativa:

Se observar eventos OOMKilled para gke-metadata-server em nós de TPU ou GPU, contacte a equipa de disponibilidade de identidade do GKE (ID do componente: 395450) para conhecer as opções de mitigação.

Operação
  • 1.32.0-gke.1358000 a 1.32.4-gke.1106006, 1.32.4-gke.1236007, 1.32.4-gke.1353001, 1.32.4-gke.1415001, 1.32.4-gke.1533000
  • 1.33.0-gke.0 a 1.33.0-gke.1552000
  • 1.32.4-gke.1353003 e posteriores
  • 1.33.0-gke.1552000 e posteriores

Os redimensionamentos de volumes podem ficar bloqueados devido ao estado NodePendingResize pendente em PVCs.

Os clusters na versão 1.32 que tenham nós nas versões 1.31 ou anteriores não conseguem atualizar o estado PersistentVolumeClaim durante a alteração do tamanho. Este estado incorreto impede o início de operações de redimensionamento subsequentes, o que impede efetivamente mais redimensionamentos.

Um PVC neste estado tem um campo status.allocatedResourceStatuses que contém NodePendingResize ou o campo status.allocatedResources e status.conditions.type: FileSystemResizePending.

Se um PVC foi criado enquanto o cluster estava numa versão afetada, pode ver este problema persistir depois de o cluster ser atualizado para uma versão corrigida conhecida. Neste cenário, o seu PVC tem de ser corrigido para remover o campo status.allocatedResources com uma solução alternativa única.

Solução alternativa:

Os PVCs bloqueados devido ao estado pendente podem ser corrigidos para remover esse estado. Pode usar um comando de patch como o seguinte para remover o estado pendente:

kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResourceStatuses":null}}'
 
kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResources":null}}'
Operação
  • 1.32.4-gke.1236007, 1.32.4-gke.1353001
  • 1.32.4-gke.1353003 e posteriores

O controlador PDCSI pode registar dados em excesso

Os clusters do GKE em versões específicas do 1.32 podem emitir mensagens de registo excessivas do controlador PDCSI. Este registo excessivo consumiria a quota da API Cloud Logging Write.

Solução alternativa:

Pode reduzir este registo excessivo adicionando um filtro de exclusão. Para excluir as mensagens de registo da ingestão no Cloud Logging, use a seguinte consulta: 

      resource.type="k8s_container"
      resource.labels.container_name="gce-pd-driver"
      (sourceLocation.file="cache.go" OR "Cannot process volume group")
Operações
  • 1.27.16-gke.2440000 e posterior
  • 1.28.15-gke.1673000 e posteriores
  • 1.29.13-gke.1038000 e posteriores
  • 1.30.9 e posteriores
  • 1.31.7 e posterior
  • 1.32.1-gke.1357001 e posterior
  • 1.27.16-gke.2691000 e posterior
  • 1.28.15-gke.2152000 e posterior
  • 1.29.15-gke.1218000 e posteriores
  • 1.30.11-gke.1190000 e posteriores
  • 1.31.7-gke.1363000 e posteriores
  • 1.32.4-gke.1106000 e posteriores
  • 1.33.0-gke.1552000 e posteriores

Os pods que tentam montar volumes persistentes NFS em nós do COS que tinham anteriormente uma montagem de leitura (RO) só são montados no modo RO

Para a versão 1.27 e posteriores do GKE, os volumes NFS que usam o controlador CSI interno do Kubernetes só podem montar volumes persistentes no modo RO após uma montagem RO anterior no mesmo nó.

Solução alternativa:

Reverter os conjuntos de nós para uma versão anterior às versões afetadas
Operações
  • Versões 1.32 de 1.32.1-gke.1357001 até, mas não incluindo, 1.32.4-gke.1106000
  • Todas as versões 1.33 anteriores a 1.33.0-gke.1552000
  • Versão 1.32: 1.32.4-gke.1106000 e posterior
  • Versão 1.33: 1.33.0-gke.1552000 e posteriores

Os pods que tentam montar volumes persistentes NFS em nós do Ubuntu não podem ser executados.

Para a versão 1.32 e posteriores do GKE, os volumes NFS que usam o controlador CSI integrado do Kubernetes não vão conseguir montar volumes persistentes em nós do Ubuntu. Quando isto acontece, pode ver as seguintes mensagens de erro: 

"MountVolume.SetUp failed for volume 'nfs-storage' : mount failed: exit status 1"
 
Output: Mount failed: mount failed: exit status 127
 
"Output: chroot: failed to run command 'mount': No such file or directory failed to run command mount on Ubuntu nodes"
 Além de ver estas mensagens de erro, os pods que usam estes volumes não vão poder ser iniciados.

Solução alternativa:

Altere os node pools para a versão 1.31.
Operação >= 1.28.15-gke.1436000, < 1.28.15-gke.1668000, >= 1.29.12-gke.1040000, < 1.29.13-gke.1028000, >= 1.30.8-gke.1053000, < 1.30.8-gke.1287000, >= 1.31.4-gke.1057000, < 1.31.6-gke.1020000, >= 1.32.0-gke.1281000, < 1.32.1-gke.1302000
  • 1.28.15-gke.1668000 ou posterior
  • 1.29.13-gke.1028000 ou posterior
  • 1.30.8-gke.1287000 ou posterior
  • 1.31.6-gke.1020000 ou posterior
  • 1.32.1-gke.1302000 ou posterior

Os pods que usam chamadas de sistema relacionadas com io_uring podem entrar no estado D (suspensão do disco), também denominado TASK_UNINTERRUPTIBLE, devido a um erro no kernel do Linux. Os processos no estado D não podem ser ativados por sinais, incluindo SIGKILL.

Quando um Pod é afetado por este problema conhecido, os respetivos contentores podem não terminar normalmente. Nos registos do containerd, pode observar mensagens repetidas semelhantes às seguintes: Kill container [container-id], o que indica que o sistema está a tentar repetidamente parar um contentor.
Em simultâneo, os registos do kubelet apresentam mensagens de erro, como as seguintes:

"Kill container failed" err="rpc error: code = DeadlineExceeded desc = context deadline exceeded"

ou

"Error syncing pod, skipping" err="[failed to \"KillContainer\" for \"container-name\" with KillContainerError: \"rpc error: code = DeadlineExceeded desc = an error occurs during waiting for container \\\"container-id\\\" to be killed: wait container \\\"container-id\\\": context deadline exceeded\", failed to \"KillPodSandbox\" for \"pod-uuid\" with KillPodSandboxError: \"rpc error: code = DeadlineExceeded desc = context deadline exceeded\"]" pod="pod-name" podUID="pod-uuid"

Estes sintomas indicam processos no contentor que estão bloqueados num estado de suspensão ininterrupto (D-state), o que impede a terminação adequada do pod.

As cargas de trabalho que usam o io_uring diretamente ou que o usam indiretamente através de um tempo de execução de linguagem, como o NodeJS, podem ser afetadas por este problema conhecido. As cargas de trabalho afetadas têm um processo no estado D (suspensão do disco) no ficheiro /proc/<pid>/state e mostram a string io_uring como parte do conteúdo de /proc/<pid>/stack. As cargas de trabalho do NodeJS podem desativar a utilização de io_uring através de UV_USE_IO_URING=0.

Solução alternativa:

Atualize os nós do cluster para uma versão corrigida ou posterior.
Operação 1,28, 1,29, 1,30, 1,31
  • 1.30.8-gke.1261000 e posteriores
  • 1.31.4-gke.1183000 e posterior
  • 1.32.0-gke.1448000 e posteriores

As cargas de trabalho que usam o streaming de imagens falham com erros de autenticação

Um erro na funcionalidade de streaming de imagens pode fazer com que as cargas de trabalho falhem quando um conjunto de condições específicas é cumprido enquanto o contentor lê ficheiros. As mensagens de erro relacionadas com falhas de autenticação podem ser visíveis no registo do gcfsd.

Para verificar se é afetado, pesquise nos registos com esta consulta de pesquisa: resource.type="k8s_node" resource.labels.project_id="[project_id]" resource.labels.cluster_name="[cluster_name]" logName="projects/[project_id]/logs/gcfsd" "backend.FileContent failed" "Request is missing required authentication credential."

A presença destes erros indica que os nós são afetados.

Se for afetado por este problema, pode atualizar os seus conjuntos de nós para uma versão corrigida do GKE.

Operação
  • 1.30.0 a 1.30.5-gke.1443001
  • 1.31.0 a 1.31.1-gke.1678000
  • 1.30.5-gke.1628000 e posteriores
  • 1.31.1-gke.1846000 e posterior

Aumento das taxas de despejo de pods nas versões 1.30 e 1.31 do GKE

Algumas versões do GKE 1.30 e GKE 1.31 que usam o COS 113 e o COS 117, respetivamente, têm kernels criados com a opção CONFIG_LRU_GEN_ENABLED=y. Esta opção ativa a funcionalidade do kernel Multi-Gen LRU, o que faz com que o kubelet calcule incorretamente a utilização de memória e pode levar o kubelet a despejar pods.

A opção de configuração CONFIG_LRU_GEN_ENABLED está desativada no cos-113-18244-151-96 e no cos-117-18613-0-76.

Pode nem sempre ver uma taxa de remoção de pods invulgar porque este problema depende do padrão de utilização de memória da carga de trabalho. Existe um risco maior de o kubelet desalojar pods para cargas de trabalho que não tenham definido um limite de memória no campo resources. Isto deve-se ao facto de as cargas de trabalho poderem pedir mais memória do que a que o kubelet comunica como disponível.

Se vir uma utilização de memória mais elevada de uma aplicação após a atualização para as versões do GKE mencionadas sem outras alterações, pode ser afetado pela opção do kernel.

Para verificar se existem taxas de despejo de pods invulgares, analise as seguintes métricas com o Explorador de métricas: kubernetes.io/container_memory_used_bytes e kubernetes.io/container_memory_request_bytes

Pode usar as seguintes consultas PromQL. Substitua os valores de cluster_name, namespace_name, metadata_system_top_level_controller_type e metadata_system_top_level_controller_name pelo nome e tipo de carga de trabalho que quer analisar:

max by (pod_name)(max_over_time(kubernetes_io:container_memory_used_bytes{monitored_resource="k8s_container",memory_type="non-evictable",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}]))

sum by (pod_name)(avg_over_time(kubernetes_io:container_memory_request_bytes{monitored_resource="k8s_container",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}]))

Se vir picos invulgares na utilização de memória que ultrapassam a memória pedida, a carga de trabalho pode estar a ser removida com mais frequência.

Alternativa

Se não conseguir atualizar para as versões corrigidas e estiver a executar num ambiente do GKE onde pode implementar pods privilegiados, pode desativar a opção LRU de várias gerações através de um DaemonSet.

  1. Atualize os pools de nós do GKE a partir dos quais quer executar o DaemonSet com uma anotação para desativar a opção LRU de várias gerações. Por exemplo, disable-mglru: "true".
  2. Atualize o parâmetro nodeSelector no manifesto do DaemonSet com a mesma anotação que usou no passo anterior. Por exemplo, consulte o ficheiro disable-mglru.yaml no repositório GoogleCloudPlatform/k8s-node-tools.
  3. Implemente o DaemonSet no seu cluster.

Depois de o DaemonSet estar em execução em todos os conjuntos de nós selecionados, a alteração entra em vigor imediatamente e o cálculo da utilização de memória do kubelet volta ao normal.

Operação 1,28, 1,29, 1,30, 1,31
  • 1.28.14-gke.1175000 e posteriores
  • 1.29.9-gke.1341000 e posteriores
  • 1.30.5-gke.1355000 e posteriores
  • 1.31.1-gke.1621000 e posteriores

Pods bloqueados no estado de encerramento

Um erro no tempo de execução do contentor (containerd) pode fazer com que os pods e os contentores fiquem bloqueados no estado de encerramento com erros semelhantes aos seguintes:

OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown

Se for afetado por este problema, pode atualizar os seus nós para uma versão do GKE com uma versão corrigida do containerd.

Operação 1.28 e 1.29
  • 1.28.9-gke.1103000 e posteriores
  • 1.29.4-gke.1202000 e posteriores
  • 1.30: todas as versões

Um erro na funcionalidade de streaming de imagens pode fazer com que os contentores não sejam iniciados.

Os contentores executados num nó com o streaming de imagens ativado em versões específicas do GKE podem não ser criados com o seguinte erro:

"CreateContainer in sandbox from runtime service failed" err="rpc error: code = Unknown desc = failed to create containerd container: failed to mount [PATH]: too many levels of symbolic links"

Se for afetado por este problema, pode verificar se existem camadas vazias ou duplicadas. Se não conseguir remover camadas vazias ou duplicadas, desative o streaming de imagens.

Operação 1.27,1.28,1.29
  • 1.28.9-gke.1103000 e posteriores
  • 1.29.4-gke.1202000 e posteriores
  • 1.30: todas as versões

O streaming de imagens falha devido a ficheiros em falta

Um erro na funcionalidade de streaming de imagens pode fazer com que os contentores falhem devido à falta de um ou mais ficheiros.

Os contentores executados num nó com o streaming de imagens ativado nas seguintes versões podem não ser iniciados ou ser executados com erros a informar que determinados ficheiros não existem. Seguem-se exemplos de tais erros:

  • No such file or directory
  • Executable file not found in $PATH

Se for afetado por este problema, pode desativar o streaming de imagens.

Redes,atualizações 1,28

Erro de configuração de TLS do gateway

Identificámos um problema com a configuração do TLS para gateways em clusters com a versão 1.28.4-gke.1083000 do GKE. Isto afeta as configurações TLS que usam um SSLCertificate ou um CertificateMap. Se estiver a atualizar um cluster com gateways existentes, as atualizações feitas ao gateway vão falhar. Para novos gateways, os balanceadores de carga não são aprovisionados. Este problema vai ser corrigido numa versão de patch do GKE 1.28 futura.

Atualizações 1.27 1.27.8 ou posterior

Problema do plug-in do dispositivo GPU

Os clusters que estão a executar GPUs e que são atualizados da versão 1.26 para uma versão de patch 1.27 anterior à 1.27.8 podem ter problemas com os plug-ins de dispositivos GPU dos respetivos nós (nvidia-gpu-device-plugin). Execute os seguintes passos consoante o estado do seu cluster:

  • Se o seu cluster estiver a executar a versão 1.26 e tiver GPUs, não atualize manualmente o cluster até que a versão 1.27.8 esteja disponível no canal de lançamento do cluster.
  • Se o cluster estiver a executar uma versão de patch anterior à 1.27 e os nós forem afetados, reinicie os nós ou elimine manualmente o pod nos nós (o gestor de suplementos cria um novo plug-in funcional).nvidia-gpu-device-plugin
  • Se o seu cluster estiver a usar atualizações automáticas, isto não afeta o seu cluster, uma vez que as atualizações automáticas só movem os clusters para versões de patches com a correção.
Operação 1.27,1.28
  • 1.27.5-gke.1300 e posteriores
  • 1.28.1-gke.1400 e posteriores

A escala automática para todas as cargas de trabalho é interrompida

O HorizontalPodAutoscaler (HPA) e o VerticalPodAutoscaler (VPA) podem parar o dimensionamento automático de todas as cargas de trabalho num cluster se este contiver objetos HPA autoscaling/v2configurados incorretamente. O problema afeta clusters que executam versões de patches anteriores da versão 1.27 e 1.28 do GKE (por exemplo, 1.27.3-gke.100).

Solução alternativa:

Corrija objetos HPA autoscaling/v2 configurados incorretamente certificando-se de que os campos em spec.metrics.resource.target correspondem, por exemplo:

  • Quando spec.metrics.resource.target.type é Utilization, o alvo deve ser averageUtilization
  • Quando spec.metrics.resource.target.type é AverageValue, o alvo deve ser averageValue

Para mais detalhes sobre como configurar objetos autoscaling/v2HPA, consulte a documentação do Kubernetes HorizontalPodAutoscaler.

Operação 1.28 e 1.29
  • 1.28.7-gke.1026000
  • 1.29.2-gke.1060000

A Deteção de ameaças de contentores não é implementada

A Deteção de ameaças de contentores pode falhar na implementação em clusters do Autopilot que executam as seguintes versões do GKE:

  • 1.28.6-gke.1095000 para 1.28.7-gke.1025000
  • 1.29.1-gke.1016000 a 1.29.1-gke.1781000
Redes, atualizações 1.27, 1.28, 1.29, 1.30
  • 1.30.4-gke.1282000 ou posterior
  • 1.29.8-gke.1157000 ou posterior
  • 1.28.13-gke.1078000 ou posterior
  • 1.27.16-gke.1342000 ou posterior

Problemas de conetividade para hostPort pods após a atualização do plano de controlo

Os clusters com a política de rede ativada podem ter problemas de conetividade com os pods hostPort. Além disso, os Pods criados recentemente podem demorar mais 30 a 60 segundos a ficar prontos.

O problema é acionado quando o painel de controlo do GKE de um cluster é atualizado para uma das seguintes versões do GKE

  • 1.30 a 1.30.4-gke.1281999
  • 1.29.1-gke.1545000 a 1.29.8-gke.1156999
  • 1.28.7-gke.1042000 a 1.28.13-gke.1077999
  • 1.27.12-gke.1107000 a 1.27.16-gke.1341999

Solução alternativa:

Atualize ou recrie os nós imediatamente após a atualização do plano de controlo do GKE.
Redes 1.31, 1.32
  • 1.32.1-gke.1729000 ou posterior
  • 1.31.6-gke.1020000 ou posterior

Tráfego UDP danificado entre pods executados no mesmo nó

Os clusters com a visibilidade intranó ativada podem ter problemas com o tráfego UDP entre pods executados no mesmo nó.

O problema é acionado quando o nó do cluster do GKE é atualizado para uma das seguintes versões do GKE ou criado com uma delas:

  • 1.32.1-gke.1729000 ou posterior
  • 1.31.6-gke.1020000 ou posterior

O caminho afetado é o tráfego UDP de pod para pod no mesmo nó através de Hostport ou Service.

Resolução

Atualize o cluster para uma das seguintes versões corrigidas:

  • 1.32.3-gke.1927000 ou posterior
  • 1.31.7-gke.1390000 ou posterior
Operação 1.29,1.30,1.31
  • 1.29.10-gke.1071000 ou posterior
  • 1.30.5-gke.1723000 ou posterior
  • 1.31.2-gke.1115000 ou posterior

Encriptação da base de dados do Cloud KMS e operador do Ray incompatíveis

Algumas versões do Ray Operator são incompatíveis com a encriptação da base de dados do KMS da Google Cloud.

Soluções alternativas:

Atualize o painel de controlo do cluster para uma versão fixa ou posterior.
Atualizações 1.30, 1.31
  • 1.30.8-gke.1051000 ou posterior
  • 1.31.1-gke.2008000 e posterior

O pod do controlador de manutenção da GPU está bloqueado no estado CrashLoopBackOff

Com este problema, os pods gpu-maintenance-handler ficam presos num estado `CrashLoopBackOff` nos respetivos nós. Este estado impede que a etiqueta "manutenção futura" seja aplicada aos nós do GKE, o que pode afetar os processos de remoção de nós e despejo de pods para cargas de trabalho.

"Node upcoming maintenance label not applied due to error: Node "gke-yyy-yyy" is invalid: metadata.labels: Invalid value: "-62135596800": a valid label must be an empty string or consist of alphanumeric characters, '-','' or '.', and must start and end with an alphanumeric character (e.g.'MyValue', or 'my_value', or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9.]*)?[A-Za-z0-9])?')"

Se este problema lhe afetar, pode resolvê-lo atualizando o plano de controlo para uma versão do GKE que inclua a correção.

Operação 1.33.1-gke.1522000 e posteriores 1.33.4-gke.1142000 e posteriores

Os pods não são iniciados em nós com o streaming de imagens ativado

Em nós com o streaming de imagens ativado, as cargas de trabalho podem não ser iniciadas com a seguinte assinatura de erro: Failed to create pod sandbox ... context deadline exceeded

Os registos da porta série de um nó afetado também contêm a seguinte assinatura de erro: task gcfsd ... blocked for more than X seconds

A presença destas duas assinaturas de erro indica um impasse num dos componentes de streaming de imagens. Este impasse impede o início bem-sucedido dos pods.

Mitigação:

Reinicie o nó para uma mitigação rápida. Tenha em atenção que o nó reiniciado pode voltar a encontrar o impasse. Para uma mitigação mais robusta, desative o streaming de imagens no conjunto de nós executando o seguinte: 

gcloud container node-pools update NODE_POOL_NAME --cluster CLUSTER_NAME --no-enable-image-streaming
 Nota: se desativar o streaming de imagens, volta a criar todos os nós num conjunto de nós.

O que se segue?