Problemas conhecidos de rede do GKE

Autopilot Standard

---

Esta página lista os problemas conhecidos de 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 (SLO) 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 a versão do GKE:

1,30 1,29 1.28 1,27

Ou pesquise seu problema:

Versões identificadas	Versões corrigidas	Problema e solução alternativa
1.30, 1.31, 1.32		Os nós recém-criados não são adicionados aos balanceadores de carga internos da camada 4 Google Cloud os balanceadores de carga criados para serviços de LoadBalancer interno podem perder nós recém-criados no grupo de instâncias de back-end. O problema será mais visível em um cluster que foi dimensionado para zero nós e depois redimensionado 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 de ativá-la. Crie outro serviço LoadBalancer interno. Quando a sincronização for concluída, 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. Você pode 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 está configurado para criar um NEG independente para um serviço e uma das portas configuradas é removida do serviço, o controlador de NEG deixa de gerenciar os endpoints do NEG. Além dos serviços em que o usuário cria uma anotação NEG independente, isso também afeta os serviços referenciados pelo gateway do GKE, pelo MCI e pelo gateway de vários clusters do GKE. Alternativa: Ao remover uma porta de um serviço com uma anotação 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 são provisionados. Esse problema será corrigido em uma versão futura do 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 de estabelecimento de conexão Clusters nas versões do plano de controle 1.26.6-gke.1900 e mais recentes podem apresentar falhas intermitentes de 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 dos sintomas.
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 si mesmo usando um serviço ou o endereço IP virtual de um balanceador de carga de rede de passagem interno, 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 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 seja 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 de 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 possa se comunicar com ele mesmo usando um serviço. Isso impede que a flag FIN do TCP 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 a quantidade de 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 ficarem 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.28, 1.29, 1.30, 1.31		Os pods do Calico não estão saudáveis em clusters com menos de três nós no total 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 ou menos vCPUs alocáveis e política de rede ativada. Isso ocorre devido a recursos de CPU insuficientes. Alternativas: Dimensione 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ó.