Soru tarihi
Kuruluşlar monolitik mimarilerden Kubernetes tarafından düzenlenen mikro hizmetlere geçtikçe, dağıtım stratejileri bakım pencerelerinden rolling güncellemelerine kaydı. İlk otomasyon çerçeveleri, dağıtım sonrası işlevsel doğrulamaya odaklanırken, pod sonlandırmaları sırasında geçici durumu göz ardı etti. Bu göz ardı, kullanıcıların dağıtımlar sırasında zorla çıkış yapmasına neden olan kritik boşluklar yarattı. Uygulamalar sağlık kontrollerini geçse de, oturum durumu geçici konteyner belleğinde saklandığı için oluşuyordu.
Problem
Uygulamalar oturum durumunu iç süreçte (örneğin, Spring Boot gömülü Tomcat veya Node.js belleği) koruduğunda, rolling güncellemeler pod sonlandırıldığında hemen oturumun yok olmasına neden olur. Standart Kubernetes hazırlık probe'ları, yeni podların trafik alıp almadığını doğrulamakla kalır, eski podların aktif bağlantıları boşaltıp boşaltmadığını kontrol etmez. Bu, NGINX veya diğer giriş denetleyicilerinin kapatma sırasında podlara istek yönlendirebileceği veya WebSocket bağlantılarının nazik bir şekilde kesilmeden koparak veri kaybı ve kimlik doğrulama hatalarına yol açtığı bir nokta oluşturur; bu, manuel testlerin yük altında güvenilir şekilde yeniden üretilemediği durumdur.
Çözüm
Aktif dağıtımlar sırasında sentetik kullanıcı simülasyonu ile dışa çıkarılmış oturum depolamasını (Redis veya Memcached) birleştiren otomatik bir doğrulama çerçevesi uygulayın. Çerçeve, kimlik doğrulaması yapılmış sentetik oturumların bir tabanını korurken, kontrollü bir rolling güncellemesini koordine eder, oturum token'larının pod sonlandırmaları sırasında sürdüğünü ve preStop kancalarının aktif isteklerin SIGTERM yayılımından önce tamamlanmasına izin verdiğini doğrular.
Bağlam
Gerçek zamanlı ticaret verilerini işleyen bir finans hizmetleri platformu, haftalık dağıtımlar sırasında kritik oturum düşüşleri yaşadı. Ticaretçiler, işlem ortasında yeniden kimlik doğrulaması yapmak zorunda kaldı ve bu da düzenleyici uyumluluk uyarılarına neden oldu ve piyasa dalgalanması sırasında gelir kaybına yol açtı.
Problem tanımı
Platform, varsayılan bellek içi oturum saklamaya sahip Spring Boot uygulamaları kullanıyordu. Kubernetes rolling güncellemeleri sırasında, yük dengeleyici hemen sonlandırma olarak işaretlenmiş podlara yönlendirmeyi durdurdu, ancak canlı fiyat akışları için mevcut WebSocket bağlantıları pod süreci çıkarken hemen kesildi. Bu, sağlıksız kontroller geçmesine ve dağıtımın başarıyla tamamlanmasına rağmen, her dağıtımda 30-40 aktif oturumun kaybolmasına sebep oldu.
Düşünülen farklı çözümler
Çözüm A: Pod sonlandırma nazik sürelerini uzatın ve istemci tarafı yeniden bağlantı mantığına güvenin.
Bu yaklaşım terminationGracePeriodSeconds değerini 60 saniyeye çıkardı ve mevcut HTTP isteklerinin doğal olarak tamamlanmasına izin verdi. Artı yönleri arasında minimal kod değişiklikleri ve hızlı uygulama yer alıyordu. Ancak dezavantajları şiddetliydi: bu dağıtımları önemli ölçüde yavaşlattı, WebSocket durumu yeniden sağlanmasını veya mesaj tamponlamayı ele almadı ve akış periyodunda yeni isteklerin gelmesiyle ilgili bir garanti sunmadı, bu da işlem zincirlerinde kısmi veri kaybına yol açtı.
Çözüm B: İstemci tarafı oturum sadakatiyle IP hash'i uygulayın.
Ekip, kullanıcıların her zaman aynı pod'a yönlendirilmesini sağlamak için NGINX'in ip_hash yük dengelemesini kullanmayı düşünmüştür. Artı yönleri arasında basitlik ve dış bağımlılık olmaması vardır. Ancak dezavantajları arasında NAT senaryolarında zayıf dağıtım, belirli bir pod'un sonlandığında tam oturum kaybı (taşınma yok) ve düşük trafik dönemlerinde pürüzsüz bir şekilde ölçeklemeyi sağlama yetersizliği, belirli kullanıcıların bağlantılarını kesmektedir.
Çözüm C: Otomatik drenaj doğrulaması ile Redis destekli oturum depolamasına geçiş yapın.
Bu çözüm, tüm oturum verilerini kümelenmiş bir Redis instance'ına dışa çıkarır ve uygulama kapanmadan önce pod'un hizmetten çıkarılmasına izin veren 15 saniye uyuyan preStop kancalarını uygular. Otomasyon çerçevesi, 500 eş zamanlı kimlik doğrulaması yapılmış oturum gerçekleştirmek için Selenium ve k6 kullanmayı, bir rolling güncelleme tetiklemeyi ve dağıtım penceresi sırasında sıfır oturumun 401 Yetkisiz veya bağlantı hataları vermediğini doğrulamayı artırılmıştır.
Seçilen çözüm
Ekip, kök nedeni (ephemeral altyapıya oturum bağlılığı) ele alan Çözüm C'yi seçti, semptomları maskelemeyi değil. Dışa çıkarılmış depolama, dağıtımların ötesinde dayanıklılık sağladı, podlerin kullanıcı etki alanı olmadan yeniden başlatılmasına olanak tanıdı. Otomatik doğrulama bileşeni, çözümün gerçekçi yük altında çalıştığını kanıtlamak için kritik öneme sahipti ve oturum taşınma gecikmesi üzerine metrikler sağladı.
Sonuç
Uygulama sonrası, otomasyon paketi, bir geliştiricinin üretime ulaşmadan önce bir özellik dalında bellek içi depolamaya yanlışlıkla geri döndüğü bir gerileşmeyi tespit etti. CI boru hattı artık dağıtımları %100 'oturum kalıcılığı puanı' ile geçerli kılmaktadır ve sentetik kullanıcılar 50 ardışık rolling güncelleme boyunca sürekli kimlik doğrulaması sağlamakta, tek bir oturum kaybı yaşamamaktadır.
Dışa çıkarılmış önbelleklerdeki oturum depolaması, yük dengeleyicilerindeki yapışkan oturumlardan nasıl farklıdır ve ikincisi sıfır kesinti dağıtım doğrulamasını çözmede neden başarısız olur?
Birçok aday, oturum kalıcılığını (yapışkan oturumlar) oturum dışa çıkarılmasıyla karıştırır. Yapışkan oturumlar, kullanıcının her zaman aynı sunucuya yönlendirilmesini sağlar, ancak o sunucu bir rolling güncelleme sırasında sonlandığında, oturum geri dönülmez bir şekilde kaybolur. Dışa çıkarılmış depolama, oturumu uygulama süreci döngüsünden ayırır. Kubernetes'te bir pod Sonlandırma durumuna girdiğinde, sonunda denetleyici onu hizmet uç noktalarından çıkarır, ancak mevcut bağlantılar devam eder. Dışa çıkarılmış depolama olmadığında, doğru drenaj olsa bile, oturum pod ile birlikte ölür. Otomatik doğrulama, oturum çerezi veya token'ın, hangi yeni pod'un sonraki isteği işlediğinden bağımsız olarak Redis'ten aynı kullanıcı bağlamını almakta olup olmadığını doğrulamalıdır.
Nazik kapatma dizilerini doğrulamak için hangi özel otomasyon mantığı gereklidir ve ön durak kancasını yük olmadan test etmenin yetersiz olduğu neden?
Adaylar genellikle, ön durak kancasını izole bir şekilde doğrulamanın yalnızca scriptin var olduğunu kanıtladığını, yük altında çalışıp çalışmadığını kanıtlamadığını gözden kaçırıyor. Zorlu soru, bağlantı drenajı ve pod sonlandırması arasındaki yarış koşulunu simüle etmekle ilgilidir. Otomasyon, sürdürülen istek akışını üretmeli (kullanarak k6 veya JMeter) ve aynı zamanda kubectl rollout restart'ı tetiklemelidir. container_cpu_usage_seconds_total metriklerinin, öncesiz SIGTERM gönderilmeden önce neredeyse sıfıra düştüğünü doğrulamalıdır, bu da kullanılmazlık onaylar, aynı anda HTTP hata oranlarının sıfır kalmasını sağlamalıdır. Pod loglarında 'Kapama başlatıldı' kontrolü yapmak yetersizdir, çünkü yük dengeleyici hâlâ istekleri yönlendirebilir ve uç nokta yayılma gecikmesinde (tipik olarak iptables proxy modunda 5-15 saniye) yönlendirme yapabilir.
WebSocket bağlantıları için oturum bütünlüğünü özel olarak nasıl doğrularsınız, zira bunlar durumsuz HTTP isteklerinin aksine kalıcı TCP bağlantıları sürdürmektedir?
Bu sıkça göz ardı edilmektedir çünkü HTTP oturum testi, uzun ömürlü bağlantılara kıyasla daha basittir. WebSocket'lerin kapatma el sıkışmasını ve durum uzlaşmasını açıkça test edilmesi gerekmektedir. Otomasyon çerçevesi, Socket.IO veya yerel WebSocket bağlantıları kurmalı, bir rolling güncelleme tetiklemesi ve bağlantının, client tarafı yeniden bağlantı mantığının harekete geçmesine izin veren nazik bir kapatma kodu (1001) alıp almadığını doğrulamalıdır, bu da ani bir TCP sıfırlamada etkili olmaktan kaçınmaktır. Yeni bir pod'a yeniden bağlantı kurulduğunda, istemcinin Redis'ten yeniden kimlik doğrulaması olmadan aynı oturum kimliğini sürdürmesi gerekmektedir. Adaylar, geçiş sırasında mesajları tamponlayabilecek STOMP veya MQTT protokol katmanlarını hesaba katmadıkları için başarısız olurlar ve pod değişimi sırasında dışa çıkarılmış oturum deposunda hiçbir mesaj kaybolmadığının doğrulanmasını gerektirir.