GKE’de kube-apiserver zaman aşımı: üç katmanda üç ayrı hata

Google Cloud destek ekibi, GKE cluster’larında pod’ların kube-apiserver’a aralıklı ulaşamamasının bir nedeninin, RFC 5961’deki challenge ACK paketlerini düşüren bir Private Service Connect değişikliği olduğunu anlattı. Sorun europe-west bölgesinde birden fazla cluster’ı etkiledi ve yaklaşık 800 geliştiricinin haftalarca production’a deploy yapmasını engelledi. Ekip üç farklı katmanda üç ayrı kök neden buldu; son düzeltme bir Linux kernel patch’i olarak geldi.

Belirti neden yanıltıcıydı

Hata mesajı sıradandı: dial tcp ...:443: i/o timeout. Bu mesajı gören çoğu ekip önce kendi koduna bakar, müşteri de öyle yaptı. Oysa ilk günden bir ipucu vardı. Zaman aşımı DaemonSet’lerde, Deployment’larda, sistem pod’larında ve cluster dışındaki GitHub Actions runner’larında aynı anda görünüyordu.

Bu kadar farklı client aynı hedefe ulaşamıyorsa sorun client’larda değil, aradaki yoldadır. Paylaşılan zaman çizelgesine göre bariz şüphelileri elemek yaklaşık 20 gün aldı. İlk 10 gün hata aralıklı kaldı ve kolayca göz ardı edildi.

Elenen şüpheliler ne öğretiyor

Ekibin sırayla elediği liste tanıdık:

• Yeni kurulan kopf tabanlı operator (hatalar kurulumdan sekiz gün önce başlamıştı)
• External Secrets Operator ve güvenlik agent’ları (kaldırıldılar, zaman aşımı sürdü)
• conntrack tablosu (varsayılan 1,3 milyonluk üst sınırın yaklaşık yarısında)
• Control plane kapasitesi (VM büyütüldü, kube-apiserver gecikmesi zaten normaldi)

Buradaki ders zaman çizelgesinde. Operator’ün hatalardan sonra geldiğini log’lar baştan söylüyordu. “Ne değişti?” diye sorarken yalnızca kendi değişikliklerinize bakarsanız, yönetilen servisin altındaki katmanı kaçırırsınız. Bu vakada sorunun bir kaynağı müşterinin hiç dokunmadığı yerdeydi: Private Service Connect’in USPS (user space packet switch) katmanına gelen bir sürüm güncellemesi.

challenge ACK araya giren katmana takılınca

Paket yakalama iki noktadan aynı anda yapıldı: control plane VM’inin NIC’inde ve kube-apiserver container’ının içinde. İki uç karşılaştırılınca tablo netleşti. Yeni SYN paketi VM’e ulaşıyor, ama karşılığında SYN-ACK yerine eski bir bağlantıya ait ACK dönüyordu.

RFC 5961’e göre bu beklenen davranış. Sunucu aynı 5-tuple için eski bağlantının durumunu hâlâ tutuyorsa, yeni SYN’e challenge ACK gönderir. Client bunu görünce RST yollar, sunucu durumu temizler, sonraki SYN normal kabul edilir. Mekanizma ancak bu ACK client’a ulaşırsa işler.

USPS’in yeni sürümü başka bir güvenlik hatasını kapatmak için handshake sırasında SYN-ACK’ten önce gelen ACK’leri “geçersiz” sayıp düşürmeye başlamıştı. Challenge ACK de tam bu tarife uyuyor. Client RST gönderemiyor, eski durum temizlenmiyor, SYN yeniden denemeleri zaman aşımıyla bitiyor. Andromeda’daki “invalid ACK” düşüş sayacının sürüm geçişiyle aynı dönemde sıçraması bağlantıyı doğruladı.

Asıl risk şu: TCP’nin eski bağlantı durumunu temizleme yolu, aradaki bir NAT, proxy ya da stateful firewall’un “anormal” bulduğu paketi düşürmesiyle bozulabiliyor. Kendi yönettiğiniz load balancer ya da firewall’da handshake öncesi ACK’leri eleyen bir kural varsa, aynı belirti sizde de ortaya çıkabilir.

Kendi ortamınızda nereden başlanır

Benzer aralıklı zaman aşımlarında önce client tarafında yakalama alın. Wireshark’ta “TCP Port numbers reused” etiketini arayın. Destek ekibi bu etiketi başta zararsız saymıştı, oysa ipucunun kendisiydi.

Yönettiğiniz Linux sunucularında challenge ACK sayacına ve FIN_WAIT_2’de bekleyen bağlantılara şöyle bakabilirsiniz:

nstat -az | grep -i challenge
ss -tan state fin-wait-2 | wc -l
sudo tcpdump -i any -w apiserver.pcap 'tcp port 443'

Sunucuda sayaç artıyor ama client tarafında RST görmüyorsanız, aradaki bir katman bu paketleri yutuyor olabilir. GKE’de control plane VM’ine erişiminiz olmadığı için destek kaydı açın ve iki uçtan eş zamanlı yakalama isteyin. Belirtinin başladığı tarihi kesin verin. Bu vakada eşleşmeyi bulduran şey bir tarih korelasyonuydu.

Metinde açık kalan sorular

Yazı üç ayrı kök nedenden söz ediyor, ama elimizdeki bölüm yalnızca USPS katmanını anlatıyor. Diğer iki hatanın ne olduğu ve kalıcı çözümün neden bir Linux kernel patch’i olarak geldiği bu metinde yok. Düzeltmeyi içeren kernel sürümü de belirtilmemiş. europe-west bölgesinde Private Service Connect kullanan GKE cluster’ları işletiyorsanız, düzeltmenin node ve control plane sürümlerinize ulaşıp ulaşmadığını Google desteğine doğrudan sorun.