Linode Kubernetes cluster oluşumu, subnet ID'leri bir milyonu geçince başarısız oldu

17 Ekim 2026'dan itibaren, dünya genelinde yeni Linode Kubernetes Engine-Enterprise (LKE-E) cluster'ları kurma girişimleri, çekirdek bileşenleri asla bekleme (pending) durumundan çıkmayan cluster'lar üretti. Olayla ilgili dev.to'da yayımlanan bir yazıya göre kök neden şaşırtıcı derecede küçüktü: Linode'un Virtual Private Cloud içindeki subnet'lerin tanımlayıcıları 1.000.000 eşiğini geçip yedinci bir basamak kazandı.

Ne bozuldu

Arıza, alttaki buluttan load balancer, route ve diğer ağ kaynaklarını isteyen ve bunları cluster'ın beklediği durumla uyumlu tutan Kubernetes bileşeni olan Cloud Controller Manager'daydı. Bir yazılım mantığı hatası nedeniyle bileşen, artık yedi basamaklı olan subnet ID'lerini düz tamsayı yerine kayan noktalı (floating-point) ayrıştırma yoluyla ele aldı. Bu olduğunda, 1000000 gibi bir değer 1e+06 şeklinde üslü forma dönüştürülebilir. Sayısal olarak aynı, metinsel olarak çok farklı — ve sıradan basamaklar bekleyen her tüketici için geçersiz. Denetleyici subnet'i çözemediği için işini tamamlayamadı ve ona bağımlı çekirdek bileşenler, yeni oluşturulan her cluster'da bekleme durumunda kaldı.

Kapsam ve kurtarma

dev.to'da alıntılanan olay özeti, etkinin net bir şekilde ikiye bölündüğünü ortaya koyuyor. Mevcut cluster'lar, çalışan iş yükleri ve mevcut cluster'ların ölçeklendirilmesi süreç boyunca çalışmaya devam etti; yalnızca yeni sağlanan cluster'lar takıldı. Bu asimetri tek başına teşhis edicidir: eski yollar başarılı olup yenileri başarısız olduğunda, arıza genellikle tüm platformda değil, oluşum sürecinin bir yerindedir.

Linode'un ana şirketi Akamai sorunu iki cepheden çözdü. Kodu, bu tanımlayıcıların kesinlikle tamsayı olarak ele alınması şekilde değiştirdi ve bozuk değerlerle yazılmış özel kaynakları (custom resource) yamalayarak takılan cluster'ları geri getirdi. Yeni test cluster'larının doğru şekilde sağlandığına dair iç testler doğrulandıktan sonra, etkinin 20 Ekim 2026 saat yaklaşık 19:49 UTC'de azaltıldığı ilan edildi ve 21 Ekim'de saat 15:49 UTC'de bir olay sonrası değerlendirme güncellemesi yayımlandı.

Neden fazladan bir basamak bunu yaptı

Bir tanımlayıcı sayı gibi görünebilir ama işlevi bir etikettir. Kimse subnet ID'lerini toplamaz ya da ortalamasını almaz; tek gerçek gereksinim, o metnin veritabanından API'ye, JSON'a ve uygulama koduna her adımda değişmeden ulaşmasıdır. Kayan nokta gösterimi bu gereksinimi iki kez ihlal eder: büyük tamsayılar her zaman tam olarak temsil edilemez ve bir float'ın biçimlendirilmesi görünümünü değiştirebilir. 999999'dan 1000000'a geçiş, birçok biçimlendiricinin bilimsel gösterime geçtiği tam noktadır; bu yüzden yıllardır doğru çalışan kod, bir sayacın bir basamak uzadığı gün başarısız olabilir. dev.to'daki yazar, aynı tuzağın başka yerlerde de ortaya çıktığına dikkat çekiyor: telefon numaralarının baştaki sıfırları kaybetmesi, kart numaralarının duyarlık kaybetmesi, zaman damgalarının son basamaklarını kaybetmesi.

Önerilen savunmalar basit. Go'da tanımlayıcıları float64 üzerinden geçirmek yerine strconv.ParseInt ile ayrıştırın ve JSON sayılarının sessizce float'a dönüştürülmeden önce denetlenebilmesi için decoder'ın UseNumber seçeneğiyle json.Number kullanın. Python'da tanımlayıcılar için float ve boolean değerleri reddedin ve girdinin yalnızca basamaklardan oluştuğunu doğrulayın. ID'leri uçtan uca metin (string) olarak tutmak ve tanımlayıcıların bir sisteme girdiği noktada özellikle 999999, 1000000 ve 1000001 ile test yapmak, bu hata sınıfını müşterilerden önce yakalar.

Neden önemli

Bu, sessiz bir hata modunun somut ve kamuya açık bir örneği: opak bir tanımlayıcının sayı gibi ele alınması ve sayısal bir temsilin sistem sınırından sızması. Orkestrasyon araçlarında bu özellikle sancılıdır, çünkü belirti sessizliktir. Faydalı bir hata mesajı olmayan beklemedeki bir cluster, kusur değil yavaşlık gibi görünür ve bu, teşhisi zorlaştırır. Bulut API'leriyle konuşan sağlama (provisioning) hatları veya Kubernetes denetleyicileri geliştiren ekipler, bir ID'nin bir float'tan, genel amaçlı bir biçimlendiriciden veya serbest bir JSON parser'ından geçtiği her yeri denetlemeli ve basamak uzunluğu sınırları çevresinde testler eklemelidir. Olay ayrıca, büyümenin tek başına uykudaki hataları tetikleyebileceğini hatırlatıyor: 17 Ekim'de kodda hiçbir şey değişmedi. Veri yalnızca bir basamak uzadı ve gizli bir varsayım sonunda çöktü.