Problemas conhecidos do GKE

Autopilot Standard

Nesta página, listamos os problemas conhecidos do GKE. Esta página é destinada a administradores e arquitetos que gerenciam o ciclo de vida da infraestrutura de tecnologia subjacente e respondem a alertas e páginas quando os objetivos de nível de serviço (SLOs) não são atendidos ou os aplicativos falham.

Nesta página, listamos os problemas conhecidos de todas as versões compatíveis e das duas versões secundárias que precedem imediatamente a versão mais antiga em suporte estendido. Depois que uma versão chega ao fim do suporte estendido, todos os problemas N-2 são removidos. Por exemplo, quando a versão 1.30 chega ao fim do suporte estendido, os problemas conhecidos específicos das versões 1.28 e anteriores são removidos.

Se você faz parte do Google Developer Program, salve esta página para receber notificações quando uma nota da versão relacionada a ela for publicada. Para saber mais, consulte Páginas salvas.

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

Selecione sua versão do GKE:

1,35 1,34 1,33 1.32 1.31 1,30 1,29 1.28 1,27

Selecione a categoria do seu problema:

Configuração Instalação Upgrades e atualizações Operação Geração de registros e monitoramento Segurança Redefinir/excluir Desempenho

Ou pesquise seu problema:

Categoria	Versões identificadas	Versões corrigidas	Problema e solução alternativa
Operação	1,35 1,36 1,37	1.35.6-gke.1250001 e mais recente 1.36.4-gke.1391002 e mais recente 1.37.1-gke.1187000 e mais recente	As solicitações HTTP POST de tokens do servidor de metadados falham com um erro 400 Bad Request As cargas de trabalho que usam a Federação de Identidade da Carga de Trabalho para GKE para autenticar APIs do Google Cloud solicitando tokens de acesso da conta de serviço ou tokens de identidade do servidor de metadados do GKE (como /computeMetadata/v1/instance/service-accounts/default/token ou /computeMetadata/v1/instance/service-accounts/default/identity) podem falhar com um erro HTTP 400 Bad Request (INVALID_ARGUMENT). Esse problema ocorre quando um aplicativo, uma biblioteca de cliente ou um gateway de API envia uma solicitação HTTP POST sem uma cadeia de certificados válida no corpo da solicitação. Nas versões afetadas do GKE, as solicitações POST para esses endpoints de token são estritamente reservadas para tokens de acesso e tokens de ID vinculados. Como resultado, as solicitações que têm payloads vazios, codificados por formulário ou JSON inválidos são rejeitadas. Para corrigir o problema, faça upgrade para a versão de patch mais recente na versão secundária de qualquer canal de lançamento. Alternativa: Para resolver esse problema, configure o aplicativo, a biblioteca de cliente ou o gateway de API para usar o método GET em vez de POST ao solicitar tokens de acesso ou tokens de ID do servidor de metadados, como no exemplo a seguir: curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" Se a carga de trabalho usar um SDK ou gateway de terceiros (como o MuleSoft Flex Gateway, o IBM App Connect ou scripts HTTP personalizados) que, por padrão, envia solicitações POST para endpoints do servidor de metadados, atualize a configuração ou a biblioteca de cliente para enviar solicitações GET.
Upgrades e atualizações	1.33 e mais recentes	A definir	Pods não programados e cota esgotada durante upgrades secundários em duas etapas para o plano de controle. Durante os upgrades de versão secundária em duas etapas para planos de controle em clusters do Autopilot que usam pods de duração estendida, novos pools de nós podem ser provisionados usando a versão anterior do nó. O escalonador automático de cluster avalia os nós recém-provisionados em relação à versão atualizada do plano de controle, detecta uma incompatibilidade de versão e aplica a restrição cloud.google.com/not-target-gke-version:true. O escalonador automático de cluster também bloqueia o escalonamento vertical de pools de nós de pods de duração estendida atuais ou recém-criados que usam a versão anterior do nó. Esse comportamento impede a programação de pods e aciona um loop de escalonamento infinito. Em vez de escalonar verticalmente um pool de nós atual, o provisionamento automático de nós cria um novo pool de nó único em cada iteração de escalonamento vertical para acomodar as cargas de trabalho pendentes. Esse loop gera centenas de pools de nós vazios separados que podem esgotar as cotas regionais de grupos gerenciados de instâncias. Alternativa: Para resolver o loop de escalonamento, conclua manualmente o upgrade do plano de controle executando o seguinte comando: gcloud container clusters complete-control-plane-upgrade [CLUSTER_NAME] --location=[LOCATION] Como alternativa, aplique a seguinte tolerância às cargas de trabalho afetadas para que elas possam ser programadas nos nós de versão anterior: tolerations: - key: "cloud.google.com/not-target-gke-version" operator: "Equal" value: "true" effect: "NoSchedule"
Operação	1.37.0-gke.2941000 e mais recente	1.37.1-gke.1131000	Os nós que montam volumes NFS acumulam entradas de montagem e param de criar contêineres Em nós que executam versões afetadas, a montagem de um volume NFS deixa entradas extras na tabela de montagem do nó. Além disso, quando um pod que usa um volume NFS é encerrado, as tentativas de desmontagem falham, fazendo com que o kubelet tente repetidamente desmontar. Cada nova tentativa adiciona mais entradas à tabela de montagem, o que faz com que ela cresça continuamente, mesmo quando nenhuma nova carga de trabalho é programada. Quando a tabela de montagem atinge o limite do kernel, o ambiente de execução do contêiner não pode mais criar contêineres nesse nó. O nó para de executar novos pods, pode informar um status NotReady e pode reiniciar repetidamente. Os pods que usam volumes NFS podem permanecer no estado Terminating porque os volumes não podem ser desmontados. Nos eventos do pod e nos registros kubelet, os nós nesse estado informam erros semelhantes a estes: MountVolume.SetUp failed for volume "VOLUME_NAME" : mount failed: exit status 1 mount: /etc: mount(2) system call failed: No space left on device Esse problema afeta os pools de nós que montam volumes NFS com o driver NFS integrado do Kubernetes. Os nós que não usam o driver NFS em árvore para montar volumes NFS não são afetados. Alternativa: Para recuperar um nó afetado, reinicie ou recrie-o. As entradas de montagem extras existem apenas no estado de execução do nó, então são apagadas quando o nó é reiniciado. Os pods que ficarem presos no estado Terminating após a reinicialização podem ser removidos com o seguinte comando: kubectl delete pod POD_NAME --namespace NAMESPACE --force --grace-period=0 Para evitar que o problema se repita em clusters Standard, faça downgrade dos pools de nós que montam volumes NFS para uma versão 1.36. Defina uma exclusão de manutenção para que o GKE não faça o upgrade automático dos pools de nós para uma versão afetada. Se um cluster do Autopilot executar uma versão afetada, use uma das seguintes opções: Se os volumes NFS forem compatíveis com o Filestore, monte-os com o driver CSI do Filestore em vez do driver NFS no kernel. O driver CSI monta volumes do próprio contêiner e não usa o componente de nó afetado. Se você precisar continuar usando o driver NFS no kernel, deixe o reparo automático de nós recuperar os nós afetados. Os clusters do Autopilot reparam os nós automaticamente, e um nó que informa um status NotReady por cerca de 10 minutos é drenado e recriado, o que limpa a tabela de montagem.
Upgrades	1.34.9-gke.1065000 e mais recentes, 1.35.6-gke.1049000 e mais recentes e todas as versões de patch 1.36	1.34.10-gke.1328000 e mais recentes, 1.35.8-gke.1026000 e mais recentes, 1.36.4-gke.1058000 e mais recentes (ainda não há correção disponível para 1.37)	Falhas na carga de trabalho da GPU A4X Max (GB300) A criação ou o upgrade de pools de nós A4X Max (a4x-maxgpu-4g-metal) do GKE em ou para versões de patch específicas (consulte a coluna Versões identificadas) causa falhas na carga de trabalho da GPU com os superchips NVIDIA GB300 Grace Blackwell Ultra anexados. Devido aos tempos de inicialização estendidos da memória de alta largura de banda (HBM) no hardware GB300 com esse tipo de máquina bare metal, o serviço de inicialização nvidia-persistenced expira. Esse tempo limite deixa as GPUs não inicializadas e resulta na mensagem de erro cudaErrorDeviceUnavailable(46) quando os pods tentam reivindicar recursos CUDA. Solução: Faça upgrade de cada cluster e pool de nós afetado para uma versão corrigida. O GKE impede a criação de pools de nós A4X Max com versões afetadas e não faz upgrade automático dos pools de nós para as versões afetadas. O GKE não impede upgrades manuais para as versões afetadas. No entanto, para evitar as falhas, recomendamos não fazer upgrade para as versões afetadas. Alternativa: Se não for possível fazer upgrade, exclua todos os pools de nós do A4X Max que estão executando versões afetadas e recrie os pools de nós usando uma versão anterior não afetada. Como a capacidade máxima do A4X precisa ser obtida por uma reserva, você não vai perder capacidade ao excluir os pools de nós.
Operação	Versões 1.33 anteriores à 1.33.5-gke.2469000 e versões 1.34 anteriores à 1.34.1-gke.2037001	1.33.5-gke.2469000 e mais recente, 1.34.1-gke.2037001 e mais recente, 1.35 e mais recente	Nós de GPU ou TPU travados com taints de encerramento de nó iminente após a manutenção do host Em clusters do GKE com nós de acelerador (GPU ou TPU) que executam versões afetadas, os nós podem ficar presos com as restrições cloud.google.com/impending-node-termination ou cloud.google.com/maintenance-window-started depois que a manutenção ou os reparos do host do Compute Engine forem concluídos. Quando a instância de VM é iniciada novamente, o controlador de manutenção do GKE pode reaplicar esses taints prematuramente se houver outro evento de manutenção futuro programado para o nó, impedindo que novas cargas de trabalho sejam programadas em nós íntegros. Alternativa: Para resolver o estado de bloqueio, remova manualmente os rótulos de manutenção ativa gerenciada do GKE e as restrições dos nós afetados. Se você remover apenas as restrições, o controlador de manutenção do GKE as reaplicará automaticamente. Para limpar os rótulos e as restrições, execute os seguintes comandos: kubectl label nodes NODE_NAME cloud.google.com/active-node-maintenance- kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time- kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time-latest- kubectl taint nodes NODE_NAME cloud.google.com/impending-node-termination- kubectl taint nodes NODE_NAME cloud.google.com/maintenance-window-started- Substitua NODE_NAME pelo nome do nó afetado.
Operação	1,33 1,34	1.34.1-gke.1829001 e mais recentes	Falhas de admissão de pods para cargas de trabalho da TPU v7 devido à geração de relatórios com uma contagem incorreta de chips. O GKE anuncia incorretamente oito chips de TPU alocáveis para aceleradores de TPU v7 (tpu7x) com uma topologia 2x2x1, que fisicamente contém apenas quatro chips. Essa incompatibilidade de relatórios impede a programação de pods para cargas de trabalho da TPU v7. A arquitetura de chiplet duplo da TPU v7 não é processada corretamente em versões anteriores, o que resulta em falhas de admissão de pods. Dependendo dos recursos de TPU solicitados, os seguintes erros ocorrem: Ao solicitar quatro TPUs (google.com/tpu: 4), o kubelet retorna um UnexpectedAdmissionError: "invalid TPU chip count request, you must request all 4 chips on this node together". Ao solicitar oito TPUs (google.com/tpu: 8), o webhook de admissão tpu-accelerator-topology-constraints nega a solicitação com o seguinte erro: "Solicitações de recurso inválidas para google.com/tpu. Ele precisa ser igual a um de [4] para acelerador tpu7x e topologia 2x2x1". Alternativa: Para resolver esse problema, faça upgrade do cluster do GKE para a versão 1.34.1-gke.1829001 ou mais recente.
Operação	1.35.3-gke.1234000 e mais recente	A definir	O cliente do Lustre não usa NICs secundárias em nós com várias NICs Em nós do GKE com várias placas de rede (NICs), o driver CSI do Managed Lustre é ativado por padrão para usar todas as NICs disponíveis para agregar largura de banda, distribuindo o tráfego de armazenamento TCP entre as interfaces de rede. No entanto, devido a um problema conhecido, os clientes do Lustre a partir da versão 2.14.0_p249 podem não usar NICs secundárias. Em vez disso, todo o tráfego de armazenamento TCP para a instância do Managed Lustre é roteado exclusivamente pela NIC principal, impedindo a agregação de largura de banda e limitando a capacidade de armazenamento. Alternativa: Se as cargas de trabalho exigirem agregação de largura de banda de várias NICs para o Managed Lustre, faça downgrade dos pools de nós para uma versão do GKE anterior à 1.35.3-gke.1234000, como 1.35.2-gke.1842000.
Operação	1.35 e mais recentes	A definir	Tempo limite de conexão ou conexão recusada para fluxos redirecionados ao servidor de metadados do GKE No GKE versão 1.35 e mais recentes, as cargas de trabalho que usam a Identidade da carga de trabalho para autenticação nas APIs do Google Cloud podem apresentar tempos limite de conectividade temporários ou conexões recusadas com o servidor de metadados do GKE imediatamente após a inicialização do nó. Alternativa: Para recomendações e soluções alternativas, consulte Resolver erros de tempo limite na inicialização do pod.
Operação	1.33.8-gke.1026000 e mais recente	1.35.1 e mais recentes	O shim do gVisor não faz a limpeza e registra o erro "runsc: executable file not found in $PATH" Sempre que um pod do gVisor é encerrado ou eliminado por falta de memória, o containerd tenta desativar o sandbox. No entanto, às vezes, o processo de limpeza falha, registrando o erro exec: "runsc": executable file not found in $PATH. Esse erro pode causar problemas como esgotamento de recursos, degradação da rede, pânico do NodeLocalDNS, tempos limite de DNS ou alta latência ao criar pods. Solução: Faça upgrade dos nós do GKE para a versão 1.35.1 ou mais recente. Para clusters padrão, faça upgrade do pool de nós com os nós afetados. Para clusters do Autopilot, faça upgrade manual para a versão 1.35.1 ou mais recente. O GKE vai atualizar automaticamente os nós para corresponder à versão do plano de controle o mais rápido possível. Alternativa: Se não for possível fazer upgrade do cluster, siga um destes procedimentos: Revise e aumente as solicitações e os limites de memória dos pods do gVisor. Implante o seguinte DaemonSet privilegiado para copiar o binário runsc de /home/containerd/usr/local/sbin para /home/kubernetes/bin: apiVersion: apps/v1 kind: DaemonSet metadata: name: runsc-path namespace: kube-system spec: selector: matchLabels: app: runsc-path updateStrategy: type: RollingUpdate template: metadata: labels: app: runsc-path spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: sandbox.gke.io/runtime operator: In values: - gvisor tolerations: - effect: NoSchedule key: sandbox.gke.io/runtime operator: Equal value: gvisor volumes: - name: host hostPath: path: / initContainers: - name: copy-runsc image: bash command: - /usr/local/bin/bash - -c - | set -euo pipefail cp /host/home/containerd/usr/local/sbin/runsc /host/home/kubernetes/bin chmod a+rx /host/home/kubernetes/bin/runsc volumeMounts: - name: host mountPath: /host resources: requests: memory: 5Mi cpu: 5m securityContext: privileged: true containers: - image: gcr.io/google-containers/pause:3.2 name: pause
Operação	1.35.0-gke.2232000 e mais recente	1.35.3-gke.1.35.3-gke.1290000 e mais recentes	Os volumes dinâmicos usam o tipo de disco padrão como substituto As cargas de trabalho que usam volumes dinâmicos no GKE versão 1.35.0-gke.2232000 ou mais recente podem não ser programadas ou anexadas. Esse problema também pode fazer com que os volumes sejam provisionados usando o hd-type de substituição (como hyperdisk-balanced) em vez do pd-type, mesmo em nós que não oferecem suporte ao Hyperdisk. Isso ocorre porque o servidor de nós do PDCSI não consegue preencher o objeto CSINode com as topologias de tipo de disco compatíveis. Como resultado, o controlador não tem as informações de topologia necessárias para corresponder os volumes com nós compatíveis. Alternativa: Faça upgrade para a versão 1.35.3-gke.1290000 ou mais recente.
Upgrades e atualizações	Todas as versões de patch anteriores à 1.34.3-gke.1208000 para o GKE 1.34 Todas as versões de patch anteriores a 1.35.0-gke.2232000 para o GKE 1.35	1.34.3-gke.1208000 para o GKE 1.34 1.35.0-gke.2232000 para o GKE 1.35	Problemas de inicialização de pods durante upgrades para o GKE 1.35 em clusters do GKE Dataplane V2 Clusters que fazem upgrade do plano de controle para a versão 1.35.0-gke.2232000 e posteriores do GKE de versões Anterior a 1.34.3-gke.1208000 para o GKE 1.34 anterior a 1.35.0-gke.2232000 para o GKE 1.35 pode ter problemas de inicialização de pods para novas cargas de trabalho criadas durante o lançamento do DaemonSet anetd. As novas cargas de trabalho não serão iniciadas durante o lançamento do anetd se forem programadas em um nó com anetd desatualizado. Durante o lançamento, talvez você veja a seguinte mensagem de erro: Failed to create pod sandbox: rpc error [...] plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded Isso ocorre porque o GKE usa o operador identity-management-mode, que exige que todos os agentes e o operador tenham uma visualização sincronizada de rótulos relevantes para a identidade. A partir do GKE 1.35.0-gke.2232000, os rótulos topology.kubernetes.io são excluídos do conjunto relevante para identidade para evitar a duplicação de identidade. Essa mudança causa uma incompatibilidade temporária de configuração entre o plano de controle atualizado e os agentes anetd desatualizados durante o lançamento. Para mais informações, consulte o Cilium PR. Alternativa: Para o GKE 1.34 anterior a 1.34.3-gke.1208000: primeiro faça upgrade para 1.34.3-gke.1208000 ou mais recente e depois para 1.35.0-gke.2232000 ou mais recente. Para o GKE 1.35 anterior a 1.35.0-gke.2232000: após o upgrade, aguarde a conclusão do lançamento anetd. Para acelerar o lançamento manualmente, exclua os pods anetd desatualizados. Isso garante que o operador e os agentes de nó anetd tenham uma visualização sincronizada dos rótulos relevantes para a identidade.
Upgrades e atualizações	1.32 1,33 1,34 1,35	1.32.11-gke.1153001 e mais recente 1.33.5-gke.2326000 e mais recente 1.34.3-gke.1214000 e mais recente 1.35.0-gke.2180000 e mais recente	Atrasos no agendamento de pods em novos nós com a política de rede do Calico ativada Em clusters do GKE com a política de rede do Calico ativada, uma regressão nas versões afetadas pode causar atrasos significativos na programação de pods em nós novos ou recriados. Esses atrasos podem fazer com que os nós permaneçam no estado NotReady por longos períodos. O problema é causado pelo script de inicialização do Calico CNI, que formata incorretamente o URL do servidor da API Kubernetes para endereços IPv4, colocando-os entre colchetes ([]). Essa abordagem causa um erro de análise de URL ao criar novas sandbox de pods, visível nos registros do kubelet: Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox ""sandbox-id"": plugin type="calico" failed (add): error creating calico client: host must be a URL or a host:port pair: "https://[IPv4-address]:443" Alternativa: A versão do componente do Calico é determinada pela versão do plano de controle do cluster. Para mitigar esse problema, faça upgrade do plano de controle do cluster para uma das versões corrigidas. Depois de fazer upgrade do plano de controle, recrie os nós nos pools de nós para garantir que eles usem o formato correto de URL do servidor de API Kubernetes. Para isso, faça um upgrade no local do pool de nós para a mesma versão ou uma mais recente ou recrie manualmente os pools de nós.
Desempenho	1.32.8-gke.1134000 e mais recente para o GKE 1.32 1.33.3-gke.1392000 e mais recente para o GKE 1.33 Todas as versões de patch do GKE 1.34 e 1.35	1.32.11-gke.1075000 e mais recentes para o GKE 1.32 1.33.5-gke.2392000 e mais recentes para o GKE 1.33 1.34.3-gke.1318000 e mais recentes para o GKE 1.34 1.35.0-gke.2398000 e mais recentes para o GKE 1.35	O desempenho da rede de uso geral cai nos tipos de máquina de GPU das séries A e G4 Os clusters do GKE com nós de GPU da série A e G4 mostram desempenho degradado para redes de uso geral no GKE 1.32.8-gke.1134000 e versões mais recentes do GKE 1.32, e no GKE 1.33.3-gke.1392000 e versões mais recentes. A degradação de desempenho em redes de uso geral afeta os tipos de máquina GPU, incluindo as séries de máquinas A3, A4, A4X e G4. O GPUDirect-TCPXO no A3 Mega e o GPUDirect-RDMA no A3 Ultra, A4 e A4X não são afetados. Isso ocorre porque o script no nível do nó (/usr/bin/google_set_multiqueue) que define a afinidade de interrupção está configurado incorretamente. Alternativa: Faça upgrade de cada pool de nós afetado para uma versão corrigida.
Desempenho	1.32.8-gke.1134000 e mais recentes para o GKE 1.32 1.33.3-gke.1392000 e mais recentes para o GKE 1.33 e mais recentes	1.32.11-gke.1075000 e mais recente para o GKE 1.32 1.33.5-gke.2392000 e mais recentes para o GKE 1.33	O desempenho do GPUDirect-TCPX cai no A3 High Os clusters do GKE com nós A3 High (a3-highgpu-8g) apresentam desempenho degradado ao usar o GPUDirect-TCPX no GKE 1.32.8-gke.1134000 e versões mais recentes para o GKE 1.32, e no GKE 1.33.3-gke.1392000 e versões mais recentes. Isso ocorre porque o script no nível do nó (/usr/bin/google_set_multiqueue) que define a afinidade de interrupção está configurado incorretamente. Alternativa: Para pools de nós do GKE 1.32, faça upgrade das versões do pool de nós do GKE para 1.32.11-gke.1075000 ou mais recente. Para pools de nós do GKE 1.33 e mais recentes, faça upgrade das versões para 1.33.5-gke.2392000 ou mais recente.1392000. Para pools de nós do GKE 1.34, consulte O GPUDirect-TCPX não está disponível com A3 High para o GKE versão 1.34 e mais recente.
Upgrades	1,35	1.35.0-gke.2232000 e mais recente.	Duplicação de identidade do Cilium em clusters do GKE Dataplane V2 Os clusters do GKE que executam a versão 1.35 com o GKE Dataplane V2 ativado podem ter um aumento no número de recursos personalizados ciliumidentities.cilium.io. Esse problema é causado pela adição de rótulos topology.kubernetes.io aos pods no Kubernetes 1.35, o que produz identidades adicionais do Cilium para cada zona em que um pod de uma carga de trabalho é programado. Em clusters regionais e zonais, a programação de uma nova carga de trabalho pode causar duplicação temporária da identidade do Cilium. Essa duplicação ocorre porque os pods recebem uma identidade no momento da criação com base nos rótulos iniciais e outra identidade depois que os rótulos de topologia são adicionados quando o pod é programado para um nó. Em clusters regionais, o número de identidades também pode aumentar em um fator proporcional ao número de zonas abrangidas pelo cluster. Impacto: Se o número total de identidades exceder 65.535, talvez não seja possível programar novas cargas de trabalho. Alternativa: Para limitar o número total de identidades, evite adicionar rótulos com um grande número de valores exclusivos aos pods. Para mais informações, consulte a seguinte documentação do Cilium: Segurança baseada em identidade Identidades de segurança Os upgrades manuais precisam ser feitos a partir das versões 1.34.3-gke.1208000 e posteriores. Se você iniciar o upgrade de uma versão anterior à 1.34.3-gke.1208000, poderá ter problemas temporários com a programação de pods durante o processo de upgrade.
Upgrades	Versões de patch 1.34 anteriores a 1.34.5-gke.1153000 Versões de patch 1.35 anteriores a 1.35.2-gke.1485000	1.34.5-gke.1153000 e mais recente 1.35.2-gke.1485000 e mais recente 1.36 e mais recentes Você também precisa usar o instalador do GPUDirect-TCPX versão 3.1.9 ou mais recente e o sidecar versão 2.0.12 ou mais recente. As versões do instalador e do arquivo secundário têm um mapeamento de um para um e precisam corresponder. Por exemplo, a versão 3.1.12 do instalador do GPUDirect-TCPX corresponde à versão 2.0.15 do arquivo secundário. Para mais informações sobre as versões do instalador e do arquivo secundário, consulte as Notas da versão do GPUDirect-TCPX.	O GPUDirect-TCPX não está disponível com A3 High para versões específicas do GKE Os clusters do GKE com nós A3 High (a3-highgpu-8g) usam o GPUDirect-TCPX para maximizar a largura de banda da rede da GPU. Para nós que usam TCPX e A3 High, fazer upgrade para as versões afetadas do GKE pode resultar em problemas funcionais ou de desempenho com o TCPX. Isso ocorre porque o TCPX é incompatível com o kernel do Linux 6.12 atualizado usado pelo Container-Optimized OS Milestone 125 ou mais recente. O marco 125 é usado pela versão 1.34 do GKE. Outros tipos de máquina de GPU A3 High (a3-highgpu-1g, a3-highgpu-2g, a3-highgpu-4g) e outras séries de máquinas de GPU não são afetados porque não são compatíveis com o GPUDirect-TCPX. Solução: Faça upgrade para patches de versão fixa do GKE para resolver esse problema. Para detalhes sobre como configurar e fazer upgrade de pools de nós com o GPUDirect-TCPX, consulte Maximizar a largura de banda da rede de GPU em clusters Standard ou Maximizar a largura de banda da rede de GPU em clusters do Autopilot. Ao executar testes do NCCL em versões fixas, você pode encontrar os seguintes avisos, que não afetam o desempenho nem a funcionalidade: Registros NCCL WARN para Rx Ctrl Timeouts: essa mensagem pode aparecer se a carga de trabalho postar uma operação de comunicação Recv no destino muito antes de postar uma operação de comunicação Send no iniciador. Não há impacto esperado na performance. Registros de aviso do NCCL para No free space for recv task: essa mensagem avisa sobre um número total baixo de tarefas de rede para processar operações, o que resulta na ocupação temporária de todas as tarefas. Não há impacto esperado na performance.
Operação	Todas as versões anteriores a 1.34.0-gke.2285000	1.34.0-gke.2285000 e mais recente	Capacidade mínima de instâncias atualizada A capacidade mínima das instâncias do Managed Lustre foi atualizada para 9.000 GiB. Clusters que executam versões anteriores a 1.34.0-gke.2285000 não podem criar instâncias com essa capacidade mínima usando o driver CSI do Managed Lustre. Alternativa: Faça upgrade da versão do cluster para 1.34.0-gke.2285000 ou mais recente para ativar a criação de instâncias do Managed Lustre com a capacidade mínima de 9.000 GiB.
Operação	Todas as versões	A definir	UIGoogle Cloud fica não editável durante o reparo automático de nós Quando um nó do GKE está passando por um reparo automático, o pool de nós não pode ser editado pelo console do Google Cloud devido a uma operação em andamento. Alternativa: Ainda é possível editar a configuração do pool de nós usando os comandos da CLI gcloud.
Operação	Versões 1.33 anteriores à 1.33.4-gke.1036000	1.33.4-gke.1036000 e mais recente	Nível de desempenho incorreto para instâncias do Lustre provisionadas dinamicamente Ao provisionar dinamicamente uma instância do Lustre, a criação da instância falha com um erro InvalidArgument para PerUnitStorageThroughput, independente do valor perUnitStorageThroughput especificado na solicitação de API. Alternativa: Faça upgrade do cluster do GKE para a versão 1.33.4-gke.1036000 ou mais recente. Se você estiver usando o canal estável, talvez uma versão mais recente ainda não esteja disponível. Nesse caso, é possível selecionar manualmente uma versão dos canais Regular ou Canal rápido que inclua a correção.
Operação	1.32.3-gke.1099000 e mais recente 1,33	1.33.3-gke.1266000 e mais recentes	Erro de entrada/saída ao renomear ou mover arquivos usando o driver CSI do Cloud Storage FUSE Ao usar uma versão afetada do driver CSI do Cloud Storage FUSE, renomear ou mover arquivos em buckets do Cloud Storage pode falhar com um erro de E/S. Alternativa: Adicione temporariamente uma definição de imagem sidecar específica ao manifesto do pod. Na seção spec.containers do manifesto do pod, adicione a seguinte definição de contêiner 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 Configurar uma imagem particular para o contêiner secundário. Depois de fazer upgrade do cluster para uma versão corrigida do GKE ou posterior, remova todo o bloco gke-gcsfuse-sidecar do manifesto. Depois de remover esse bloqueio, o GKE vai voltar a injetar e gerenciar automaticamente a imagem sidecar correta para a versão do cluster atualizada.
Geração de registros e monitoramento	Todas as versões	A definir	Condição de disputa em DaemonSets gke-metrics-agent Quando você adiciona o rótulo cloud.google.com/gke-metrics-agent-scaling-level a um pool de nós para aumentar manualmente a alocação de memória do DaemonSet gke-metrics-agent, ocorre uma condição de disputa no DaemonSet durante a criação de um novo nó. Essa condição de disputa resulta em reinicializações intermitentes e pode causar perda de métricas. Esse problema ocorre porque há um atraso antes que o rótulo seja adicionado a um novo nó no pool de nós. Durante esse atraso, o DaemonSet cria um pod com a alocação de memória original nesse nó. Depois que o rótulo é aplicado, o DaemonSet cria um pod com a nova alocação de memória. O pod atual não é completamente excluído quando o pod atualizado é iniciado. Ambos os pods tentam se vincular ao mesmo número de porta. Alternativa: Depois de adicionar o rótulo cloud.google.com/gke-metrics-agent-scaling-level a um pool de nós, reinicie o DaemonSet gke-metrics-agent: kubectl -n kube-system rollout restart daemonset gke-metrics-agent
Upgrades	1,33	1.33.2-gke.1043000	Limite de arquivos abertos reduzido com o containerd 2.0 Para pools de nós que executam a versão 1.33 do GKE, que usa o containerd 2.0, o limite flexível padrão para arquivos abertos (ulimit -n) para contêineres é reduzido para 1024. Essa é uma mudança no próprio containerd (consulte containerd PR #8924, em inglês), em que LimitNOFILE foi removido de containerd.service como prática recomendada, fazendo com que o limite flexível padrão do sistema seja aplicado. As cargas de trabalho que esperam um limite flexível padrão mais alto (por exemplo, aquelas que dependem implicitamente do padrão mais alto anterior) podem apresentar falhas, como erros Too many open files. Solução: Faça upgrade de uma versão de patch anterior da 1.33 para a 1.33.2-gke.1043000 ou posterior. Alternativa: Aumente o limite de arquivos abertos para suas cargas de trabalho usando um dos seguintes métodos: Ajuste no nível do aplicativo:modifique o código do aplicativo ou a configuração do aplicativo para definir explicitamente ulimit -n ou prlimit --nofile=524288. Plug-in de ajuste de ulimit do NRI do containerd : use o plug-in containerd/nri ulimit-adjuster para ajustar o ulimit. Fazer downgrade do pool de nós (somente Standard): para clusters do GKE Standard, é possível fazer downgrade temporário do pool de nós para a versão 1.32 para evitar esse problema até que uma resolução permanente esteja disponível. Para mais informações sobre a migração para o containerd 2, consulte Migrar nós para o containerd 2.
Upgrades	1.31.5-gke.1169000, 1.32.1-gke.1376000	1.31.7-gke.1164000, 1.32.3-gke.1512000	Status inválido "storedVersions" da CRD para CRDs gerenciados Algumas CRDs gerenciadas pelo GKE podem ter um campo status.storedVersions inválido, o que cria um risco de interrupção do acesso a objetos de CRD após um upgrade. Esse problema afeta clusters que são: Clusters que usaram uma versão afetada do GKE em algum momento. Clusters que tinham versões não compatíveis (served=false) de objetos CRD armazenados no etcd. Alternativa: A solução recomendada é adiar os upgrades do cluster até que o problema seja resolvido. Como alternativa, se você souber que o cluster contém versões não compatíveis de objetos CRD, adicione essas versões ao campo status.storedVersions usando o comando kubectl patch.
Operação, geração de registros e monitoramento	1.32.2-gke.1652000, 1.31.6-gke.1221000, 1.30.10-gke.1227000	1.32.2-gke.1652003 ou mais recente 1.31.6-gke.1221001 ou mais recente 1.30.10-gke.1227001 ou mais recente	Métricas ausentes ou escalonador automático de cargas de trabalho não escalonando Talvez você observe lacunas nos dados de métricas nas versões afetadas depois que o tamanho do cluster aumentar em mais de cinco nós. Esse problema também pode afetar as operações de escalonamento automático. Esse problema afeta apenas os clusters atualizados para as versões afetadas. Os clusters recém-criados devem funcionar conforme o esperado. Alternativa: Se você for afetado, faça downgrade de uma versão de patch ou upgrade 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 programado devido aos limites de anexação de volume de um nó aciona o provisionamento automático de um novo nó. Quando as cargas de trabalho que usam um produto do Hyperdisk são programadas para um nó que executa uma VM C3, o provisionamento automático de nós não ocorre, e o pod é programado no nó que já está cheio. A carga de trabalho é programada no nó, apesar da falta de uma conexão de disco disponível. A carga de trabalho também não é iniciada devido a um erro como este: 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 do Hyperdisk em máquinas C3. Os limites de anexação do Hyperdisk variam de acordo com o número de vCPUs da VM e o produto do Hyperdisk. Para mais informações, consulte Limites de desempenho do Hyperdisk. Alternativa: Os produtos do Google Cloud Hyperdisk acionam o provisionamento automático em outros formatos de VM. Recomendamos um formato que seja compatível apenas com o Google Cloud 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		gke-metadata-server é OOMKilled em nós de TPU/GPU Em nós de TPU (por exemplo, ct4p-hightpu-4t) e GPU (por exemplo, a3-highgpu-8g) do GKE, o kernel pode encerrar o gke-metadata-server com um OOMKilled quando o uso da memória do servidor exceder 100 MB. Alternativa: Se você observar eventos OOMKilled para gke-metadata-server em nós de TPU ou GPU, entre em contato com a equipe de plantão do GKE Identity (ID do componente: 395450) para saber as opções de mitigação.
Operação	1.32.0-gke.1358000 para 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 mais recente 1.33.0-gke.1552000 e mais recente	Os redimensionamentos de volume podem ficar travados devido ao status NodePendingResize pendente em PVCs. Os clusters na versão 1.32 que têm nós nas versões 1.31 ou anteriores não vão atualizar o status do PersistentVolumeClaim durante o redimensionamento. Esse status incorreto impede que as operações de redimensionamento subsequentes comecem, impedindo efetivamente novos redimensionamentos. Um PVC nesse estado tem um campo status.allocatedResourceStatuses que contém NodePendingResize ou os campos status.allocatedResources e status.conditions.type: FileSystemResizePending. Se um PVC foi criado enquanto o cluster estava em uma versão afetada, esse problema pode persistir após o upgrade do cluster para uma versão fixa conhecida. Nesse cenário, o PVC precisa ser corrigido para remover o campo status.allocatedResources com uma solução alternativa única. Alternativa: PVCs presos devido a um status pendente podem ser corrigidos para remover esse status. Use um comando de patch como o seguinte para remover o status de 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 mais recente	O driver PDCSI pode registrar em excesso Os clusters do GKE em versões específicas do 1.32 podem emitir mensagens de registro excessivas do driver PDCSI. Esse excesso de registros consumiria a cota da API Cloud Logging Write. Alternativa: Para reduzir esse registro excessivo, adicione um filtro de exclusão. Para impedir que as mensagens de registro sejam ingeridas 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 mais recente 1.28.15-gke.1673000 e mais recente 1.29.13-gke.1038000 e mais recente 1.30.9 e versões mais recentes 1.31.7 e mais recentes 1.32.1-gke.1357001 e mais recente	1.27.16-gke.2691000 e mais recente 1.28.15-gke.2152000 e mais recente 1.29.15-gke.1218000 e mais recente 1.30.11-gke.1190000 e mais recente 1.31.7-gke.1363000 e mais recente 1.32.4-gke.1106000 e mais recente 1.33.0-gke.1552000 e mais recente	Os pods que tentarem montar volumes permanentes NFS em nós do COS que antes tinham uma montagem somente leitura (RO, na sigla em inglês) só serão montados no modo RO. Para o GKE versão 1.27 e mais recentes, os volumes NFS que usam o driver CSI em árvore do Kubernetes só podem montar volumes permanentes no modo RO após uma montagem RO anterior no mesmo nó. Alternativa: Fazer downgrade dos pools de nós para uma versão anterior às afetadas.
Operações	Versões 1.32 de 1.32.1-gke.1357001 até 1.32.4-gke.1106000, mas sem incluir esta última Todas as versões 1.33 anteriores a 1.33.0-gke.1552000 Versão 1.32: 1.32.4-gke.1106000 e mais recentes Versão 1.33: 1.33.0-gke.1552000 e mais recentes	Os pods que tentarem montar volumes permanentes do NFS em nós do Ubuntu não poderão ser executados. Para o GKE versão 1.32 e posterior, os volumes NFS que usam o driver CSI em árvore do Kubernetes não poderão montar volumes permanentes em nós do Ubuntu. Quando isso acontece, as seguintes mensagens de erro podem aparecer: "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 essas mensagens de erro, os pods que usam esses volumes não poderão ser criados. Alternativa: Faça downgrade dos pools de nós 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.1369000	1.28.15-gke.1668000 ou mais recente 1.29.13-gke.1028000 ou mais recente 1.30.8-gke.1287000 ou mais recente 1.31.6-gke.1020000 ou mais recente 1.32.1-gke.1369000 ou mais recente	Os pods que usam syscalls relacionadas a io_uring podem ficar presos no estado "Terminating" Os pods que usam syscalls relacionados a io_uring podem entrar no estado D (suspensão do disco), também chamado de TASK_UNINTERRUPTIBLE, devido a um bug no kernel do Linux. Os processos no estado D não podem ser ativados por indicadores, incluindo SIGKILL. Quando um pod é afetado por esse problema conhecido, os contêineres dele podem não ser encerrados normalmente. Nos registros do containerd, talvez você veja mensagens repetidas como esta: Kill container [container-id], indicando que o sistema está tentando interromper um contêiner repetidamente. Ao mesmo tempo, os registros do kubelet mostram 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" Esses sintomas indicam processos dentro do contêiner que estão travados em uma suspensão ininterrupta (estado D), o que impede o encerramento adequado do pod. As cargas de trabalho que usam io_uring direta ou indiretamente por meio de um ambiente de execução de linguagem, como o NodeJS, podem ser afetadas por esse problema conhecido. As cargas de trabalho afetadas têm um processo no estado D (suspensão do disco) no arquivo /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 o uso de io_uring por meio de UV_USE_IO_URING=0. Alternativa: Faça upgrade dos nós do cluster para uma versão corrigida ou mais recente.
Operação	1.28, 1.29, 1.30, 1.31	1.30.8-gke.1261000 e mais recente 1.31.4-gke.1183000 e mais recente 1.32.0-gke.1448000 e mais recente	As cargas de trabalho que usam o streaming de imagens falham com erros de autenticação Um bug no recurso de streaming de imagens pode causar falhas nas cargas de trabalho quando um conjunto de condições específicas é atendido enquanto o contêiner lê arquivos. As mensagens de erro relacionadas a falhas de autenticação podem estar visíveis no registro do gcfsd. Para verificar se você foi afetado, pesquise os registros 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 desses erros indica que os nós foram afetados. Se você for afetado por esse problema, faça upgrade dos pools de nós para uma versão do GKE com patch.
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 mais recente 1.31.1-gke.1846000 e mais recente	Aumento das taxas de remoção de pods nas versões 1.30 e 1.31 do GKE Algumas versões do GKE 1.30 e do GKE 1.31 que usam o COS 113 e o COS 117, respectivamente, têm kernels criados com a opção CONFIG_LRU_GEN_ENABLED=y. Essa opção ativa o recurso de kernel LRU de várias gerações, que faz com que o kubelet calcule incorretamente o uso da memória e pode levar à remoção de pods. A opção de configuração CONFIG_LRU_GEN_ENABLED está desativada em cos-113-18244-151-96 e cos-117-18613-0-76. Nem sempre é possível ver uma taxa de remoção de pods incomum porque esse problema depende do padrão de uso da memória da carga de trabalho. Há um risco maior de o kubelet desalojar pods para cargas de trabalho que não definiram um limite de memória no campo de recursos. Isso ocorre porque as cargas de trabalho podem solicitar mais memória do que o kubelet informa como disponível. Se você notar um uso da memória maior de um aplicativo após o upgrade para as versões do GKE mencionadas sem outras mudanças, talvez você seja afetado pela opção do kernel. Para verificar se há taxas incomuns de remoção de pods, analise as seguintes métricas com o Metrics Explorer: kubernetes.io/container_memory_used_bytes e kubernetes.io/container_memory_request_bytes Use as seguintes consultas do 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 da carga de trabalho que você 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 você notar picos incomuns no uso da memória que ultrapassam a memória solicitada, a carga de trabalho pode estar sendo removida com mais frequência. Alternativa Se não for possível fazer upgrade para as versões corrigidas e se você estiver executando em um ambiente do GKE em que é possível implantar pods privilegiados, desative a opção de LRU de várias gerações usando um DaemonSet. Atualize os pools de nós do GKE em que você quer executar o DaemonSet com uma anotação para desativar a opção de LRU de várias gerações. Por exemplo, disable-mglru: "true" Atualize o parâmetro nodeSelector no manifesto do DaemonSet com a mesma anotação usada na etapa anterior. Por exemplo, consulte o arquivo disable-mglru.yaml no repositório GoogleCloudPlatform/k8s-node-tools. Implante o DaemonSet no cluster. Depois que o DaemonSet estiver em execução em todos os pools de nós selecionados, a mudança entrará em vigor imediatamente, e o cálculo do uso da memória do kubelet voltará ao normal.
Operação	1.28, 1.29, 1.30, 1.31	1.28.14-gke.1175000 e mais recente 1.29.9-gke.1341000 e mais recente 1.30.5-gke.1355000 e mais recente 1.31.1-gke.1621000 e mais recente	Pods travados no status de encerramento Um bug no ambiente de execução do contêiner (containerd) pode fazer com que os pods e contêineres fiquem travados no status de encerramento com erros semelhantes aos seguintes: OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown Se você for afetado por esse problema, faça upgrade dos nós para uma versão do GKE com uma versão corrigida do containerd.
Operação	1.34 e anteriores Versões 1.35 anteriores à 1.35.6-gke.1005000 Versões 1.36 anteriores à 1.36.0-gke.2459000	1.35.6-gke.1005000 e mais recente 1.36.0-gke.2459000 e mais recente	O streaming de imagens falha devido a links simbólicos Um bug no recurso de streaming de imagens pode impedir que os contêineres sejam iniciados. Os contêineres executados em um 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" Alternativa: Para resolver esse problema, faça upgrade dos pools de nós para uma versão corrigida (1.35.6-gke.1005000 ou posterior, ou 1.36.0-gke.2459000 ou posterior). Se não for possível fazer upgrade, verifique se há camadas vazias ou duplicadas. Se não for possível remover camadas vazias ou duplicadas, desative o streaming de imagens.
Operação	1.27,1.28,1.29	1.28.9-gke.1103000 e mais recente 1.29.4-gke.1202000 e mais recente 1.30: todas as versões	Falha no streaming de imagens devido à falta de arquivos Um bug no recurso de streaming de imagens pode causar falhas nos contêineres devido à ausência de um ou mais arquivos. Os contêineres executados em um nó com o streaming de imagens ativado nas seguintes versões podem não iniciar ou apresentar erros informando que determinados arquivos não existem. Veja alguns exemplos desses erros: No such file or directory Executable file not found in $PATH Se você for afetado por esse problema, desative o streaming de imagens.
Rede,upgrades e atualizações	1.28		Erro de configuração de TLS do gateway Identificamos um problema ao configurar o TLS para gateways em clusters que executam a versão 1.28.4-gke.1083000 do GKE. Isso afeta as configurações de TLS que usam um SSLCertificate ou um CertificateMap. Se você estiver fazendo upgrade de um cluster com gateways, as atualizações feitas no gateway vão falhar. Para novos gateways, os balanceadores de carga não serão provisionados. Esse problema será corrigido em uma versão de patch futura do GKE 1.28.
Upgrades e atualizações	1,27	1.27.8 ou mais recente	Problema no plug-in do dispositivo de GPU Os clusters que executam GPUs e 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 dispositivo de GPU dos nós (nvidia-gpu-device-plugin). Siga as etapas abaixo, dependendo do estado do cluster: Se o cluster estiver executando a versão 1.26 e tiver GPUs, não faça upgrade manual do cluster até que a versão 1.27.8 esteja disponível no canal de lançamento do cluster. Se o cluster estiver executando uma versão de patch 1.27 anterior e os nós forem afetados, reinicie os nós ou exclua manualmente o pod nvidia-gpu-device-plugin nos nós (o gerenciador de complementos vai criar um novo plug-in de trabalho). Se o cluster estiver usando upgrades automáticos, isso não vai afetar você, já que os upgrades automáticos só vão mover os clusters para versões de patch com a correção.
Operação	1.27,1.28	1.27.5-gke.1300 e mais recente 1.28.1-gke.1400 e mais recente	O escalonamento automático de todas as cargas de trabalho é interrompido. O HorizontalPodAutoscaler (HPA) e o VerticalPodAutoscaler (VPA) podem interromper o escalonamento automático de todas as cargas de trabalho em um cluster se ele contiver objetos HPA autoscaling/v2 mal configurados. O problema afeta clusters que executam versões de patch anteriores das versões 1.27 e 1.28 do GKE (por exemplo, 1.27.3-gke.100). Alternativa: Corrija os objetos HPA autoscaling/v2 configurados incorretamente verificando se os campos em spec.metrics.resource.target correspondem, por exemplo: Quando spec.metrics.resource.target.type é Utilization, a segmentação precisa ser averageUtilization Quando spec.metrics.resource.target.type for AverageValue, o destino precisa ser averageValue Para mais detalhes sobre como configurar objetos HPA autoscaling/v2, consulte a documentação do Kubernetes sobre HorizontalPodAutoscaler.
Operação	1.28,1.29	1.28.7-gke.1026000 1.29.2-gke.1060000	Falha na implantação da Detecção de Ameaças em Contêiner A implantação da Detecção de Ameaças em Contêiner pode falhar em clusters do Autopilot que executam as seguintes versões do GKE: 1.28.6-gke.1095000 a 1.28.7-gke.1025000 1.29.1-gke.1016000 a 1.29.1-gke.1781000
Rede, upgrades	1.27, 1.28, 1.29, 1.30	1.30.4-gke.1282000 ou mais recente 1.29.8-gke.1157000 ou mais recente 1.28.13-gke.1078000 ou mais recente 1.27.16-gke.1342000 ou mais recente	Problemas de conectividade para pods hostPort após o upgrade do plano de controle Clusters com a política de rede ativada podem ter problemas de conectividade com pods hostPort. Além disso, os pods recém-criados podem levar mais 30 a 60 segundos para ficar prontos. O problema é acionado quando o plano de controle 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 Alternativa: Faça upgrade ou recrie os nós imediatamente após o upgrade do plano de controle do GKE.
Rede	1.31, 1.32	1.32.1-gke.1729000 ou mais recente 1.31.6-gke.1020000 ou mais recente	Tráfego UDP interrompido entre pods executados no mesmo nó Clusters com visibilidade intranós ativada podem ter tráfego UDP corrompido 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 mais recente 1.31.6-gke.1020000 ou mais recente O caminho afetado é o tráfego UDP entre pods no mesmo nó por meio de Hostport ou Serviço. Resolução Faça upgrade do cluster para uma das seguintes versões corrigidas: 1.32.3-gke.1927000 ou mais recente 1.31.7-gke.1390000 ou mais recente
Operação	1.29,1.30,1.31	1.29.10-gke.1071000 ou mais recente 1.30.5-gke.1723000 ou mais recente 1.31.2-gke.1115000 ou mais recente	Operador do Ray e criptografia de banco de dados do Cloud KMS incompatíveis Algumas versões do operador do Ray são incompatíveis com a criptografia de banco de dados do Cloud KMS. Alternativas: Faça upgrade do plano de controle do cluster para uma versão corrigida ou mais recente.
Upgrades e atualizações	1.30, 1.31	1.30.8-gke.1051000 ou mais recente 1.31.1-gke.2008000 e mais recente	Pod do gerenciador de manutenção de GPU travado no estado CrashLoopBackOff Com esse problema, os pods gpu-maintenance-handler ficam presos em um estado "CrashLoopBackOff" nos respectivos nós. Esse estado impede que o rótulo "manutenção futura" seja aplicado aos nós do GKE, o que pode afetar os processos de drenagem de nós e remoção 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 você for afetado por esse problema, faça upgrade do plano de controle para uma versão do GKE que inclua a correção.
Operação	1.33.1-gke.1522000 e mais recente	1.33.4-gke.1142000 e mais recente	Falha ao iniciar pods 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 registros de porta serial de um nó afetado também contêm a seguinte assinatura de erro: task gcfsd ... blocked for more than X seconds A presença dessas duas assinaturas de erro indica um impasse em um dos componentes de streaming de imagens. Esse deadlock impede que os pods sejam iniciados. Mitigação: Reinicie o nó para uma mitigação rápida. O nó reiniciado ainda pode encontrar o impasse novamente. Para uma mitigação mais robusta, desative o streaming de imagens no pool de nós executando o seguinte: gcloud container node-pools update NODE_POOL_NAME --cluster CLUSTER_NAME --no-enable-image-streaming Observação: desativar o streaming de imagens recria todos os nós em um pool de nós.
Operação	1.32.4-gke.1198000 e mais recente Versões 1.33 anteriores à 1.33.5-gke.1862000 Versões 1.34 anteriores à 1.34.1-gke.2541000	1.33.5-gke.1862000 e mais recente 1.34.1-gke.2541000 e mais recente	As ComputeClasses personalizadas com ImageType não usam pools de nós do GKE. Ao usar uma ComputeClass personalizada que define um campo ImageType, o escalonador automático de cluster cria e aumenta repetidamente novos pools de nós em vez de aumentar os pools de nós atuais. O status da ComputeClass não está íntegro. Alternativa: Faça upgrade do cluster para uma das seguintes versões corrigidas: 1.33.5-gke.1862000 ou mais recente 1.34.1-gke.2541000 ou mais recente Como alternativa, é possível reduzir esse problema não definindo determinados campos na ComputeClass personalizada. Se você não usar uma ComputeClass personalizada do Autopilot, não defina o campo ImageType. Nesse caso, o valor usado é a configuração padrão no nível do cluster, que é cos_containerd. Se você usar uma ComputeClass personalizada do Autopilot, não defina o campo nodePoolConfig, que é um nível ImageType.

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:

  • Abrir um caso de suporte entrando em contato com o Cloud Customer Care.
  • Receber suporte da comunidade fazendo perguntas no StackOverflow e usando a tag google-kubernetes-engine para pesquisar problemas semelhantes. Você também pode participar do canal do Slack #kubernetes-engine para receber mais suporte da comunidade.
  • Abrir problemas ou solicitações de recursos usando o Issue Tracker público.