Problemas conhecidos de rede do GKE

Autopilot Standard

---

Nesta página, listamos os problemas conhecidos da rede 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.

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

Selecione sua versão do GKE:

1.32 1.31 1,30 1,29 1.28 1,27

Ou pesquise seu problema:

Versões identificadas	Versões corrigidas	Problema e solução alternativa
1.31, 1.32, 1.33	1.33.1-gke.1107000 e mais recente	Interrupções nos balanceadores de carga de entrada e de serviço em clusters com uma rede legada Uma incompatibilidade com redes legadas faz com que os back-ends de um balanceador de carga gerenciado pelo GKE implantado usando Entrada ou Service sejam desconectados. Isso resulta em um balanceador de carga sem back-ends ativos, o que, por sua vez, faz com que todas as solicitações recebidas para esses balanceadores de carga sejam descartadas. O problema afeta clusters do GKE que usam uma rede legada e estão na versão 1.31 ou mais recente. Para identificar clusters do GKE com uma rede legada, execute o seguinte comando: gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(subnetwork)" Um cluster com uma rede legada vai receber uma saída vazia para esse comando. Alternativa: Como as redes legadas foram descontinuadas há algum tempo, a solução preferida é migrar sua rede legada para uma rede VPC. Para fazer isso, converta uma rede legada que contém clusters do GKE. Se não for possível fazer essa migração agora, entre em contato com o Cloud Customer Care.
1.30, 1.31, 1.32	1.30.10-gke.1070000 e mais recente 1.31.5-gke.1068000 e mais recente 1.32.1-gke.1002000 e mais recente	Os nós recém-criados não são adicionados aos balanceadores de carga internos da camada 4 Os balanceadores de carga Google Cloud criados para serviços LoadBalancer internos podem não incluir nós recém-criados no grupo de instâncias de back-end. O problema será mais visível em um cluster que foi escalonado para zero nós e depois escalonado de volta para um ou mais nós. Alternativas: Ative o subagrupamento do GKE e recrie o serviço. Observação: não é possível desativar a criação de subconjuntos do GKE depois que ela é ativada. Crie outro serviço de balanceamento de carga interno. Quando ele for sincronizado, o grupo de instâncias também será corrigido para o serviço afetado. O novo serviço pode ser removido após a sincronização. Adicione e remova o rótulo node.kubernetes.io/exclude-from-external-load-balancers de um dos nós. Adicione um nó ao cluster. É possível remover o nó depois que o serviço começar a funcionar.
1.27,1.28,1.29,1.30,1.31		O controlador NEG para de gerenciar endpoints quando a porta é removida do serviço Quando o controlador de NEG é configurado para criar um NEG independente para um serviço e uma das portas configuradas é removida posteriormente do serviço, o controlador de NEG acaba parando de gerenciar endpoints para o NEG. Além dos serviços em que o usuário cria uma anotação de NEG independente, isso também afeta os serviços referenciados pelo Gateway do GKE, MCI e Gateway de vários clusters do GKE. Alternativa: Ao remover uma porta de um serviço com uma anotação de NEG independente, a anotação também precisa ser atualizada para remover a porta em questão.
1.28		Erro de configuração de TLS do gateway Identificamos 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.
1.27,1.28,1.29	1.26.13-gke.1052000 e mais recente 1.27.10-gke.1055000 e mais recente 1.28.6-gke.1095000 e mais recente 1.29.1-gke.1016000 e mais recente	Falhas intermitentes no estabelecimento de conexão Os clusters nas versões 1.26.6-gke.1900 e mais recentes do plano de controle podem encontrar falhas intermitentes no estabelecimento de conexão. As chances de falhas são baixas e não afetam todos os clusters. As falhas devem parar completamente alguns dias após o início do sintoma.
1.27,1.28,1.29	1.27.11-gke.1118000 ou mais recente 1.28.7-gke.1100000 ou mais recente 1.29.2-gke.1217000 ou mais recente	Problemas de resolução de DNS com o Container-Optimized OS As cargas de trabalho executadas em clusters do GKE com nós baseados no Container-Optimized OS podem ter problemas de resolução de DNS.
1.28	1.28.3-gke.1090000 ou mais recente	A política de rede descarta uma conexão devido à pesquisa incorreta de acompanhamento de conexão Para clusters com o GKE Dataplane V2 ativado, quando um pod cliente se conecta a ele mesmo usando um serviço ou o endereço IP virtual de um balanceador de carga de rede de passagem interna, o pacote de resposta não é identificado como parte de uma conexão devido a uma pesquisa de conntrack incorreta no plano de dados. Isso significa que uma política de rede que restringe o tráfego de entrada do pod é aplicada incorretamente no pacote. O impacto desse problema depende do número de pods configurados para o serviço. Por exemplo, se o serviço tiver um pod de back-end, a conexão sempre vai falhar. Se o serviço tiver dois pods de back-end, a conexão falhará 50% do tempo. Alternativa: É possível atenuar esse problema configurando port e containerPort no manifesto do serviço com o mesmo valor.
1.27,1.28	1.28.3-gke.1090000 ou mais recente 1.27.11-gke.1097000 ou mais recente	Quedas de pacotes para fluxos de conexão com alça de cabelo Para clusters com o GKE Dataplane V2 ativado, quando um pod cria uma conexão TCP com ele mesmo usando um serviço, de modo que o pod é a origem e o destino da conexão, o rastreamento de conexão eBPF do GKE Dataplane V2 rastreia incorretamente os estados de conexão, levando a um vazamento de entradas conntrack. Quando uma tupla de conexão (protocolo, IP de origem/destino e porta de origem/destino) vaza, novas conexões que usam a mesma tupla de conexão podem resultar no descarte de pacotes de retorno. Alternativa: Use uma das seguintes soluções alternativas: Ative a reutilização de TCP (sinal de atividade) para um aplicativo em execução em um pod que pode se comunicar com ele mesmo usando um serviço. Isso impede que a flag TCP FIN seja emitida e evita o vazamento da entrada do conntrack. Ao usar conexões de curta duração, exponha o pod usando um balanceador de carga de proxy, como o Gateway, para expor o serviço. Isso faz com que o destino da solicitação de conexão seja definido como o endereço IP do balanceador de carga, impedindo que o GKE Dataplane V2 execute SNAT no endereço IP de loopback.
Anterior a 1.31.0-gke.1506000	1.31.0-gke.1506000 e mais recente	A rede digitada pelo dispositivo em várias redes do GKE falha com nomes de rede longos A criação do cluster falha com o seguinte erro: error starting very-long-string-that-exceeds-character-limit-gpu-nic0 device plugin endpoint: listen unix /var/lib/kubelet/plugins_registry/networking.gke.io.networks_very-long-string-that-exceeds-character-limit-gpu-nic0.sock: bind: invalid argument Alternativa: Limite o comprimento dos nomes de objetos de rede digitados pelo dispositivo a 41 caracteres ou menos. O caminho completo de cada soquete de domínio UNIX é composto, incluindo o nome de rede correspondente. O Linux tem uma limitação de comprimentos de caminho de soquete (menos de 107 bytes). Depois de considerar o diretório, o prefixo do nome do arquivo e a extensão .sock, o nome da rede é limitado a no máximo 41 caracteres.
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.
1.31, 1.32	1.32.1-gke.1729000 ou mais recente 1.31.6-gke.1020000 ou mais recente	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: 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 Hostport ou Service. 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
1.28, 1.29, 1.30, 1.31		Pods do Calico não íntegros em clusters com menos de três nós totais e vCPU insuficiente Os pods calico-typha e calico-node não podem ser programados em clusters que atendam a todas as seguintes condições: menos de três nós no total, cada nó com uma vCPU alocável ou menos e política de rede ativada. Isso acontece devido a recursos de CPU insuficientes. Alternativas: Faça o escalonamento para um mínimo de três pools de nós com um nó usando uma vCPU alocável. Redimensione um único pool de nós para um mínimo de três nós com uma vCPU alocável. Use um tipo de máquina com pelo menos duas vCPUs alocáveis em um pool de nós com um único nó.