Timeouts na API do GKE: Google rastreia mistério de rede até três falhas combinadas

O caso começou em janeiro de 2026, com um ticket que dizia só isto: pods falhando de forma intermitente ao acessar o API server do Kubernetes. O cliente rodava vários clusters GKE na região europe-west com Private Service Connect (PSC) expondo o control plane de forma privada. Operators próprios, External Secrets Operator e agentes de segurança foram descartados um a um. Conntrack estava em cerca de 50% de uma capacidade padrão de 1,3 milhão de entradas, e aumentar a VM do control plane não ajudou. Cerca de 800 desenvolvedores ficaram sem conseguir fazer deploy em produção.

As capturas de pacotes simultâneas, na NIC da VM do control plane e dentro do container do kube-apiserver, mostraram o SYN chegando e o cliente recebendo de volta um ACK fora de lugar, em vez de SYN-ACK. Era um challenge ACK (RFC 5961). Uma mudança no USPS, a camada de software do PSC, passou a descartar esses ACKs como inválidos. Como o NAT do PSC concentra muitos pods na mesma porta de origem, as colisões de 5-tupla eram frequentes. O rollback em fevereiro mitigou, e em março de 2026 o cliente confirmou a recuperação. Mas foi paliativo. A causa de fundo eram três falhas combinadas: reordenação de pacotes no PIGv por causa do processamento de miss-thread do PSC, o Envoy mantendo sockets em half-close (shutdown(SHUT_WR)) e um bug no TCP do Linux, corrigido com patch no kernel. Detalhe técnico: o tcp_fin_timeout (60 segundos na VM) só vale para sockets órfãos, então não limpava os que o Envoy segurava.

Em 30 de outubro de 2026, o CEVIU noticiou "Timeouts no API server do Kubernetes no GKE: três bugs em três camadas, e a correção veio no kernel do Linux", com o relato do ticket de janeiro de 2026. A matéria de agora fecha o diagnóstico: aponta a combinação de reordenação no PSC, half-close no Envoy e o bug de TCP no Linux, além do patch de kernel que resolveu a causa subjacente.

Para quem opera clusters com control plane privado, a leitura é que timeout intermitente no API server nem sempre vem de workload, operator ou capacidade. Quando os suspeitos óbvios caem, captura de pacotes em mais de um ponto do caminho vira a ferramenta que decide. Também mostra que um rollback pode esconder a causa raiz: o problema só ficou resolvido de fato com o patch no kernel.