Dağıtılmış sistemlerin yönetilmesi zor olabilir çünkü sistemin çalışması için hepsinin düzgün çalışması gereken çok sayıda hareketli, değişen öğe vardır. Unsurlardan biri arızalanırsa sistem bunu tespit etmeli, bypass etmeli ve düzeltmeli ve tüm bunlar otomatik olarak yapılmalıdır. Bu Kubernetes En İyi Uygulamalar serisinde, bir Kubernetes kümesinin sağlığını test etmek için Hazırlık ve Canlılık testlerinin nasıl ayarlanacağını öğreneceğiz.
Durum Denetimi, uygulama örneğinizin çalışıp çalışmadığını sisteme bildirmenin basit bir yoludur. Uygulama örneğiniz kapalıysa diğer hizmetler ona erişmemeli veya ona istek göndermemelidir. Bunun yerine, isteğin halihazırda çalışmakta olan veya daha sonra başlatılacak olan uygulamanın başka bir örneğine gönderilmesi gerekir. Ayrıca sistem, uygulamanızın kaybolan işlevselliğini geri yüklemelidir.
Varsayılan olarak Kubernetes, bölmelerdeki tüm kapsayıcılar çalışırken bir bölmeye trafik göndermeye başlar ve kilitlendiklerinde kapsayıcıları yeniden başlatır. Bu varsayılan sistem davranışı başlangıç için yeterince iyi olabilir, ancak özel sağlık kontrollerini kullanarak ürün dağıtımınızın güvenilirliğini artırabilirsiniz.
Neyse ki Kubernetes bunu yapmayı oldukça kolaylaştırıyor, dolayısıyla bu kontrolleri göz ardı etmek için hiçbir mazeret yok. Kubernetes iki tür Durum Denetimi sağlar ve her birinin nasıl kullanıldığına ilişkin farklılıkları anlamak önemlidir.
Hazırlık testi, Kubernetes'e uygulamanızın trafiği yönetmeye hazır olduğunu bildirmek için tasarlanmıştır. Bir hizmetin bir pod'a trafik göndermesine izin vermeden önce Kubernetes'in hazırlık kontrolünün başarılı olduğunu doğrulaması gerekir. Hazırlık testi başarısız olursa Kubernetes, test başarılı olana kadar bölmeye trafik göndermeyi durduracaktır.
Canlılık testi Kubernetes'e uygulamanızın canlı mı yoksa ölü mü olduğunu söyler. İlk durumda Kubernetes onu kendi haline bırakacak, ikincisinde ise ölü pod'u silecek ve yerine yenisini koyacaktır.
Uygulamanızın ısınmasının ve başlatılmasının 1 dakika sürdüğü bir senaryo hayal edelim. İş akışı başlamış olsa bile, uygulama tamamen yüklenip çalışana kadar hizmetiniz çalışmaya başlamayacaktır. Bu dağıtımı birden fazla kopyaya ölçeklendirmek istiyorsanız da sorun yaşarsınız çünkü bu kopyalar tamamen hazır olana kadar trafik almamalıdır. Ancak varsayılan olarak Kubernetes, konteyner içindeki işlemler başlar başlamaz trafik göndermeye başlayacaktır.
Hazırlık testini kullanırken Kubernetes, hizmetin yeni kopyaya trafik göndermesine izin vermeden önce uygulamanın tamamen çalışmasını bekleyecektir.
Uygulamanın uzun süre askıda kaldığı ve hizmet isteklerinin durdurulduğu başka bir senaryo hayal edelim. İşlem çalışmaya devam ettikçe Kubernetes varsayılan olarak her şeyin yolunda olduğunu varsayacak ve çalışmayan bölmeye istek göndermeye devam edecektir. Ancak Liveness kullanılırken Kubernetes, uygulamanın artık isteklere hizmet vermediğini algılayacak ve varsayılan olarak ölü podu yeniden başlatacaktır.
Hazır olma ve yaşayabilirliğin nasıl test edildiğine bakalım. Üç test yöntemi vardır: HTTP, Komut ve TCP. Kontrol etmek için bunlardan herhangi birini kullanabilirsiniz. Bir kullanıcıyı test etmenin en yaygın yolu bir HTTP araştırmasıdır.
Uygulamanız bir HTTP sunucusu olmasa bile Canlılık testiyle etkileşim kurmak için uygulamanızın içinde hafif bir HTTP sunucusu oluşturabilirsiniz. Bundan sonra Kubernetes bölmeye ping göndermeye başlayacak ve HTTP yanıtı 200 veya 300 ms aralığındaysa bölmenin sağlıklı olduğunu gösterecektir. Aksi takdirde modül "sağlıksız" olarak işaretlenecektir.
Komut testleri için Kubernetes, komutu kapsayıcınızın içinde çalıştırır. Komut sıfır çıkış koduyla dönerse konteyner sağlıklı olarak işaretlenir, aksi takdirde 1'den 255'e kadar bir çıkış durum numarası alındığında konteyner "hasta" olarak işaretlenir. Bu test yöntemi, bir HTTP sunucusunu çalıştıramıyorsanız veya çalıştırmak istemiyorsanız ancak uygulamanızın durumunu kontrol edecek bir komut çalıştırabiliyorsanız kullanışlıdır.
Son doğrulama mekanizması TCP testidir. Kubernetes belirtilen bağlantı noktasında TCP bağlantısı kurmaya çalışacaktır. Eğer bu yapılabilirse, konteyner sağlıklı kabul edilir; değilse, yaşanmaz olarak kabul edilir. Bu yöntem, bir HTTP isteğiyle veya komut yürütmeyle test etmenin pek iyi sonuç vermediği bir senaryo kullanıyorsanız yararlı olabilir. Örneğin, TCP kullanarak doğrulamaya yönelik ana hizmetler gRPC veya FTP olacaktır.
Testler farklı parametrelerle çeşitli şekillerde yapılandırılabilir. Bunların ne sıklıkta yürütüleceğini, başarı ve başarısızlık eşiklerinin ne olduğunu ve yanıtların ne kadar süre bekleneceğini belirtebilirsiniz. Daha fazla bilgi için Hazırlık ve Canlılık testlerine ilişkin belgelere bakın. Bununla birlikte, Canlılık testini ayarlarken çok önemli bir nokta vardır: test gecikmesinin başlangıçDelaySeconds ayarı. Bahsettiğim gibi bu testin başarısız olması modülün yeniden başlatılmasına neden olacaktır. Bu nedenle, uygulama kullanıma hazır olana kadar testin başlamadığından emin olmanız gerekir, aksi takdirde yeniden başlatmalar arasında geçiş yapmaya başlar. P99 başlatma süresini veya arabellekteki ortalama uygulama başlatma süresini kullanmanızı öneririm. Uygulamanızın başlatma süresi hızlandıkça veya yavaşladıkça bu değeri ayarlamayı unutmayın.
Uzmanların çoğu, Durum Denetimlerinin herhangi bir dağıtılmış sistem için zorunlu bir denetim olduğunu ve Kubernetes'in de istisna olmadığını doğrulayacaktır. Hizmet durumu kontrollerinin kullanılması Kubernetes'in güvenilir, sorunsuz çalışmasını sağlar ve kullanıcılar için zahmetsizdir.
Devamı çok yakında...
Bazı reklamlar 🙂
Bizimle kaldığın için teşekkürler. Yazılarımızı beğeniyor musunuz? Daha ilginç içerik görmek ister misiniz? Sipariş vererek veya arkadaşlarınıza tavsiye ederek bize destek olun,
Amsterdam'daki Equinix Tier IV veri merkezinde Dell R730xd 2 kat daha mı ucuz? Sadece burada
Kaynak: habr.com