Timeouts no API server do Kubernetes no GKE: três bugs em três camadas, e a correção veio no kernel do Linux

O caso começou em janeiro de 2026 como um ticket aparentemente banal: pods falhando de forma intermitente ao falar com o API server. O cliente tinha um ambiente GKE multicluster na região europe-west, com Private Service Connect (PSC) expondo o control plane de forma privada. O caminho de um pod até o kube-apiserver é longo: nó worker, NAT e proxy do PSC, balanceador interno, NIC da VM do control plane e, ali, o Envoy na frente do kube-apiserver. O PSC injeta um proxy protocol header em cada conexão nova para preservar o IP do cliente.

Os suspeitos óbvios caíram um a um: operator customizado (kopf), External Secrets Operator, agentes de segurança, conntrack (cerca de 50% de 1,3M de entradas) e tamanho da VM do control plane. A virada veio com capturas de pacotes simultâneas na NIC da VM e dentro do container do kube-apiserver. Os SYNs chegavam, mas o cliente recebia um ACK fora de lugar, que pertencia a uma conexão anterior com a mesma porta de origem. É o challenge ACK da RFC 5961, que o cliente deveria responder com RST para limpar o estado velho.

Em fevereiro de 2026, uma mudança no user space packet switch (USPS) do PSC passou a descartar ACKs classificados como inválidos antes do SYN-ACK. Os challenge ACKs se encaixavam nessa descrição e sumiam em silêncio. Como o NAT do PSC faz muitos pods compartilharem portas de origem, as colisões de 5-tuple eram frequentes. O rollback da mudança aliviou o problema, e em março de 2026 o cliente confirmou a recuperação. Mas era paliativo: a VM mantinha conexões em FIN_WAIT_2 por mais de dois minutos. Daí os outros bugs: reordenamento de pacotes no PIGv por causa do miss-thread do PSC e o half-close do Envoy, que mantém o socket aberto e, por não ser órfão, escapa do tcp_fin_timeout de 60 segundos. A correção definitiva foi um patch no kernel do Linux.

Para quem opera plataforma sobre GKE, o caso sugere um critério de triagem: quando o sintoma aparece em cinco clusters e em clientes externos como runners de CI, o problema provavelmente está no caminho de rede, não nos workloads. Remover operators e agentes costuma ser a primeira reação, mas aqui custou semanas. Capturas simultâneas em dois pontos do caminho foram o que destravou a investigação. Também vale registrar que um fix de segurança numa camada gerenciada pode quebrar uma dependência implícita, e que mitigação não é correção.