Bir Kubernetes orkestra panosunun manuel doğrulaması, arayüzü basit bir görselleştirme katmanı yerine dağıtık bir sistem gözlemcisi olarak ele almayı gerektirir. Metodoloji, Minikube veya Kind kullanarak kontrol edilen bir küme ortamı kurarak başlar, maxSurge yüzdeleri ve maxUnavailable eşiklerini içeren açıkça yapılandırılmış RollingUpdate stratejileri ile örnek bir uygulama dağıtılır. Test edenler, tarayıcı Geliştirici Araçları aracılığıyla Server-Sent Events (SSE) akışlarını izleyerek, pod durum geçişlerinin belirlenen SLA zaman dilimleri içinde yayıldığını doğrularken aynı zamanda Prometheus metriklerinin kazıma aralıklarının pano yenileme döngüleri ile hizalandığını kontrol etmelidir.
Test süreci, üç eşzamanlı doğrulama ipliği içerir. İlk olarak, diagramda senkronizasyon gecikmesini gözlemleyerek kubectl aracılığıyla dağıtım kopyalarını değiştirin. İkincisi, bellek sınırlı stres konteynerleri kullanarak OOMKilled senaryolarını tetiklemek için kaynak baskısı oluşturun. Üçüncüsü, kontrol düzlemini degrade etmek için etcd düğümlerini ağ parçalarıyla simüle ederek zarif hata işleme gözlemleyin. Kritik kontrol noktaları, sona erdirme podlarının belirgin görsel durumlar (Terminating → ContainerCreating → Running) arasında geçiş yaptığını doğrulamak, HorizontalPodAutoscaler olaylarının belirgin bildirim rozetleri oluşturduğunu onaylamak ve pano oturum sürekliliğinin API Sunucusu fail-over'ları sırasında doğru JWT token yenileme mekanizmaları aracılığıyla hayatta kaldığını sağlamaktır.
Monolitik Java EE uygulamalarından konteynerleştirilmiş mikro hizmetlere geçiş yapan bir lojistik şirketi için kritik bir göç sırasında, operasyon ekibi, RabbitMQ destekli bir sipariş işleme sistemini izlemek için özel bir panoya güveniyordu. Problem, panonun tüm podların yeşil durum göstergeleriyle "%100 Tamamlandı" olarak gösterdiğinde, müşteri siparişlerinin bağlantı zaman aşımına uğramasıyla kendini gösterdi. Araştırma, Dağıtım kontrolörü yeni pod'lar oluşturmuşken, ReadinessProbe yapılandırmalarının gerçek hizmet bağımlılıklarıyla uyumsuz olduğunun ortaya çıktığını gösterdi ve bu da pod'ların Flyway veritabanı göçlerini tamamlamadan önce trafik almasına neden oldu.
Gelecekteki sürümlerde bu tür senkronizasyon hatalarını tespit etmek için üç ayrı çözüm düşünüldü. İlk yaklaşım, herhangi bir dağıtımı onaylamadan önce manuel kubectl get pods doğrulaması gerçekleştirmeyi önerdi, bu kesinlikle gerçek küme durumunu sağlasa da, her dağıtım için on beş dakika gerektiriyor ve bu da yüksek baskı altında kaçınılmaz olarak atlanacak tehlikeli bir iş yükü oluşturuyordu.
İkinci çözüm, Selenium kullanarak otomatik ekran görüntüsü karşılaştırma testleri önermekteydi. Bu, pod durum renklerinde görsel regresyonları yakalayabiliyordu, ancak SSE yeniden bağlantıları sırasında arayüzün geçici olarak doğru durumları gösterdiği, ancak eski verileri önbelleğe aldığı zamanları tespit etmekte başarısız oldu.
Üçüncü metodoloji, kontrollü hata enjekte etme ile yapılandırılmış kaos mühendisliğini içeriyordu. Bu yaklaşım, vb. gibi ağ politikaları oluşturup, panonun davranışını tarayıcı Geliştirici Araçları'nın Olay Akışı denetimi aracılığıyla izleyerek, etcd lider seçimlerini simüle etti.
Ekip, üçüncü çözümü seçti çünkü bunun kök nedeni ele aldığına inanıyordu. Panonun React ön yüzü, bağlantı kopmaları sırasında geçersiz kılma olmaksızın Redux durumunda Pod nesnelerini önbelleğe alıyordu. Bu, arayüzün OOMKilled olup yeniden planlamış olan "Hazır" pod'ları göstermesine neden oldu.
Testler, otuz saniyelik aralıklarla SSE bağlantılarını sistematik olarak keserken, aynı anda pod'ları kubectl delete aracılığıyla öldürdüklerinde, yeniden bağlantı mantığının önbelleğe alınmış durumu yeniden oynatmadan önce Kubernetes API Sunucusundan taze güncellemeleri alma durumunu keşfettiler. Sonuç olarak, gelişim ekibi etag tabanlı önbellek geçersiz kılma başlıkları uygulayarak olay yanıt süresini %80 oranında azalttı ve daha önce üretim sürümlerini rahatsız eden yanlış pozitif dağıtım onaylarını önleyerek kritik bir hata düzeltmesi sağladı.
Sunucuya Gönderilen Olayların (SSE) gerçek zamanlı güncellemeler sağladığını nasıl doğru bir şekilde doğrularsınız, sunucu tarafı günlüklerine erişim olmadan veya arka uç kodunu değiştirme yeteneği olmadan?
Birçok aday, "Arayüz güncellenene kadar beklemeyi" önerir, ancak bu, anket mekanizmaları ile gerçek olay odaklı mimariler arasında ayrım yapmayı başaramaz. Doğru yaklaşım, tarayıcı Geliştirici Araçlarını açmak ve Ağ sekmesinin Olay Akışı bölümüne erişmek, böylece bireysel mesaj yüklerini ve zaman damgalarını incelemektir.
Content-Type başlığının text/event-stream okuduğundan ve mesajların toplu HTTP yanıtları yerine ayrı olaylar olarak geldiğinden emin olmalısınız. Ayrıca, otuz saniye boyunca "Çevrimdışı" mod simüle ederek yeniden bağlantı dayanıklılığını test edin, ardından bağlantıyı geri yükleyin ve müşterinin kaybedilen olayları talep etmek için Last-Event-ID başlığını gönderip göndermediğini izleyerek, kesinti sırasında durum geçişlerinin kaybolmadığını onaylayın.
Bir Kubernetes panosunda ReadinessProbe hataları ile LivenessProbe hataları arasındaki kritik ayrım nedir ve bunları karıştırmak yanlış pozitif dağıtım doğrulamalarıyla neden sonuçlanır?
Adaylar genellikle ReadinessProbe hatalarının pod'ları Servis uç noktalarından (trafik durdurma) çıkardığını, ancak konteynerleri öldürmediğini, LivenessProbe hatalarının ise konteyner yeniden başlatmalarını tetiklediğini gözden kaçırırlar. Pano testlerinde bu ayrım görsel olarak ortaya çıkar: başarısız bir readiness probe sarı "Hazır Değil" rozeti göstermelidir, oysa liveness hataları kırmızı "CrashLoopBackOff" durumlarını göstermelidir.
Bunu doğru bir şekilde test etmek için, çevre değişkenleri aracılığıyla probe yanıtlarını geçici olarak değiştirebilen "uyumsuz" bir uygulama dağıtmalısınız, ardından dashboard'un Readiness Probe geçişlerini kubectl port-forwarding karşılaştırmaları aracılığıyla doğrulamalısınız. Bu durumların karıştırılması, testçilerin uygulamaların çalıştığı ancak trafik sunmadığı dağıtımları onaylamasıyla sonuçlanır ve sessiz üretim kesintilerine yol açar.
etcd quorum kaybı sırasında panonun dayanıklılığını test ederken, hangi ölçütlerle API Sunucusu degradasyonunu kabul edilebilir ve kritik UI hataları arasında ayırt edersiniz ki bu, olay müdahalesi sırasında operatörleri yanıltabilir?
Çoğu testçi yalnızca olumlu senaryolara odaklanır ve Kubernetes'in etcd bozulmaları sırasında kısmen işlevsel kaldığını gözden kaçırır; okumalar genellikle başarılı olurken yazmalar başarısız olur. Gelişmiş bir test metodolojisi, üç kontrol düzlemi düğümü ile bir Kind kümesi kurmayı, ardından ağ parçalarını simüle etmek için düğümler arasında 2379/tcp trafiğini engellemek üzere iptables kurallarını kullanmayı içerir.
API Sunucusu yazma işlemleri için HTTP 500 hataları dönerken, arayüz net bir "Kontrol Düzlemi Degradasyonu" bandı göstermeli ve önbelleğe alınmış pod durumlarını açık "Son Güncelleme" zaman damgaları ile göstermeye devam etmelidir. Adaylar genellikle UI'nin bu pencerelerde yıkıcı eylemleri (dağıtımları ölçeklendirmek veya pod’ları silmek gibi) önlemesini doğrulamayı unutur, bunun yerine yalnızca döngüleri gösterecektir. Doğru doğrulama, pano eylemlerini denemek ve bunun API Sunucusunun Durum nesnelerinden kaynaklanan kullanıcı dostu hata mesajlarının ortaya çıktığını onaylamaktır.