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 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.
Esta página lista problemas conhecidos para todas as versões compatíveis e para as duas versões secundárias que precedem imediatamente a versão mais antiga no 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 atinge o fim do suporte estendido, os problemas conhecidos específicos das versões 1.28 e anteriores são removidos.
Se você faz parte do Programa para desenvolvedores do Google, 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:
Selecione a categoria do seu problema:
Ou pesquise seu problema:
| Categoria | Versões identificadas | Versões corrigidas | Problema e solução alternativa |
|---|---|---|---|
| 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 dinamicamenteAo provisionar dinamicamente uma instância do Lustre, a criação da instância falha com um erro 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, selecione manualmente uma versão dos canais Regular ou Rápido que inclua a correção. |
| Operação |
|
1.33.3-gke.1266000 e mais recente |
Erro de entrada/saída ao renomear ou mover arquivos usando o driver CSI do Cloud Storage FUSEAo 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 # 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 sidecar. Depois de fazer upgrade do cluster para uma versão fixa do GKE ou mais recente, remova todo o bloco |
| Geração de registros e monitoramento | Todas as versões | A definir |
Condição de disputa em DaemonSets
|
| Upgrades | 1,33 | 1.33.2-gke.1043000 |
Limite de arquivos abertos reduzido com o containerd 2.0Para 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 ( Essa é uma mudança no próprio containerd (consulte PR do containerd nº 8924), em que 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 Solução: Faça upgrade de uma versão de patch 1.33 anterior para a 1.33.2-gke.1043000 ou mais recente. Alternativa: Aumente o limite de arquivos abertos para suas cargas de trabalho usando um dos seguintes métodos:
|
| 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" do CRD para CRDs gerenciadosAlguns CRDs gerenciados pelo GKE podem ter um campo Esse problema afeta clusters que são:
Alternativa: A solução alternativa recomendada é atrasar os upgrades do cluster até que o problema seja resolvido. Como alternativa, se você souber que o cluster contém versões sem suporte de
objetos CRD, adicione essas versões ao campo |
| Operação, geração de registros e monitoramento | 1.32.2-gke.1652000, 1.31.6-gke.1221000, 1.30.10-gke.1227000 |
|
Métricas ausentes ou escalonador automático de carga de trabalho que não está escalonandoÉ possível observar lacunas nos dados de métricas nas versões afetadas depois que o tamanho do cluster aumenta 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 vão 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 HyperdiskNormalmente, um pod que não pode ser programado devido aos limites de vinculação de volume de um nó aciona o provisionamento automático de um novo nó. Quando cargas de trabalho que usam um produto 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ó já 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 Hyperdisk nas 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 Hyperdisk acionam o provisionamento automático em outros formatos de VM. Recomendamos um formato que ofereça suporte apenas ao 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/GPUEm nós de TPU (por exemplo, Alternativa: Se você observar eventos |
|
| Operação |
|
|
O redimensionamento de volumes pode ficar travado 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 sejam iniciadas, evitando outros redimensionamentos. Um PVC nesse estado tem um campo Se um PVC foi criado enquanto o cluster estava em uma versão afetada, esse problema poderá persistir depois que o cluster for atualizado para uma versão fixa conhecida. Nesse cenário, o PVC precisa ser corrigido para remover o campo Alternativa: As PVCs presas devido a um status pendente podem ser corrigidas para remover esse status. Você pode usar um comando patch como o seguinte para remover o status 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 |
|
|
O driver PDCSI pode registrar em excessoOs clusters do GKE em versões específicas do 1.32 podem emitir mensagens de registro excessivas do driver PDCSI. Esse excesso de geração 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 processadas pelo 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 |
|
|
Os pods que tentarem montar volumes permanentes do NFS em nós do COS que já tinham uma montagem somente leitura (RO) serão montados apenas no modo RO.Para o GKE versão 1.27 e mais recente, 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: Faça downgrade dos pools de nós para uma versão anterior às afetadas. |
| Operações |
|
|
Os pods que tentarem montar volumes permanentes do NFS em nós do Ubuntu não poderão ser executados.Para volumes NFS do GKE versão 1.32 e mais recentes que usam o driver CSI em árvore do Kubernetes, não será possível montar volumes permanentes em nós do Ubuntu. Quando isso acontece, você 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" 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.1302000 |
|
Os pods que usam syscalls relacionados a io_uring podem ficar travados 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 sinais, incluindo
Quando um pod é afetado por esse problema conhecido, os contêineres dele podem não ser encerrados normalmente. Nos registros do containerd, você pode observar mensagens repetidas semelhantes a esta:
ou
Esses sintomas apontam para processos dentro do contêiner que estão presos em um estado de suspensão ininterrupta (D), o que impede o encerramento adequado do pod.
As cargas de trabalho que usam io_uring diretamente ou indiretamente por 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 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 |
|
As cargas de trabalho que usam o streaming de imagens falham com erros de autenticaçãoUm 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 aparecer no registro do gcfsd.
Para verificar se você foi afetado, pesquise os registros com esta consulta:
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 corrigida do GKE. |
| Operação |
|
|
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
A opção de configuração Talvez você nem sempre veja uma taxa de remoção de pods incomum porque esse problema depende do padrão de uso de 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 acontece porque as cargas de trabalho podem solicitar mais memória do que o kubelet informa como disponível. Se você notar um uso maior de memória de um aplicativo após o upgrade para as versões do GKE mencionadas sem outras mudanças, talvez você esteja sendo afetado pela opção do kernel.
Para verificar se há taxas de remoção de pods incomuns, analise as seguintes métricas com o Metrics Explorer:
É possível usar as seguintes consultas em PromQL. Substitua os valores de
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 de memória que excedem a memória solicitada, talvez a carga de trabalho esteja sendo despejada com mais frequência. AlternativaSe não for possível fazer upgrade para as versões corrigidas e você estiver executando em um ambiente do GKE em que é possível implantar pods privilegiados, desative a opção LRU multigeração usando um DaemonSet.
Depois que o DaemonSet estiver em execução em todos os pools de nós selecionados, a mudança vai entrar em vigor imediatamente, e o cálculo do uso de memória do kubelet voltará ao normal. |
| Operação | 1.28, 1.29, 1.30, 1.31 |
|
Pods travados no status de encerramentoUm bug no ambiente de execução do contêiner (containerd) pode fazer com que pods e contêineres fiquem presos no status "Encerrando" 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.28,1.29 |
|
O streaming de imagens falha devido a links simbólicosUm bug no recurso de streaming de imagens pode fazer com que os contêineres não iniciem. 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"
Se você foi afetado por esse problema, 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 |
|
O streaming de imagens falha devido à falta de arquivosUm bug no recurso de streaming de imagens pode fazer com que os contêineres falhem devido a um ou mais arquivos ausentes. 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. Confira alguns exemplos desses erros:
Se você for afetado por esse problema, desative o streaming de imagens. |
| Rede,upgrades e atualizações | 1.28 |
Erro de configuração do TLS do gatewayIdentificamos um problema na configuração do 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 atuais, 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 futura versão de patch do GKE 1.28. |
|
| Upgrades e atualizações | 1,27 | 1.27.8 ou mais recente |
Problema com o plug-in do dispositivo GPU
Os clusters que executam GPUs e são atualizados da versão 1.26 para uma versão de patch 1.27 anterior a 1.27.8 podem ter problemas com os plug-ins de dispositivo de GPU (
|
| Operação | 1.27,1.28 |
|
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
Alternativa:
Corrija objetos HPA
Para mais detalhes sobre como configurar objetos HPA do |
| Operação | 1.28,1.29 |
|
Falha na implantação do Container Threat DetectionO Container Threat Detection pode não ser implantado em clusters do Autopilot que executam as seguintes versões do GKE:
|
| Rede, upgrades | 1.27, 1.28, 1.29, 1.30 |
|
Problemas de conectividade para pods
|
| Rede | 1.31, 1.32 |
|
Tráfego UDP corrompido entre pods executados no mesmo nóClusters com a visibilidade intranós ativada podem ter problemas com o tráfego UDP entre pods que são executados no mesmo nó. O problema é acionado quando o nó do cluster do GKE é atualizado ou criado com uma das seguintes versões do GKE:
O caminho afetado é o tráfego UDP entre pods no mesmo nó por Hostport ou Service. Resolução Faça upgrade do cluster para uma das seguintes versões corrigidas:
|
| Operação | 1.29,1.30,1.31 |
|
Operador do Ray e criptografia de banco de dados do Cloud KMS incompatíveisAlgumas 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 |
|
Pod do gerenciador de manutenção de GPU travado no estado CrashLoopBackOffCom esse problema, os pods gpu-maintenance-handler ficam presos em um estado "CrashLoopBackOff" nos respectivos nós. Esse estado impede que o rótulo "próxima manutenção" 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 iniciar
com a seguinte assinatura de erro:
Os registros da porta serial de um nó afetado também contêm a seguinte assinatura de erro:
A presença dessas duas assinaturas de erro indica um deadlock 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 deadlock 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 |
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-enginepara pesquisar problemas semelhantes. Você também pode participar do canal do Slack#kubernetes-enginepara receber mais suporte da comunidade. - Abrir bugs ou solicitações de recursos usando o Issue Tracker público.