🥇Kubernetes'teki canlılık araştırmaları tehlikeli olabilir

Not. tercüme: Zalando'nun baş mühendisi Henning Jacobs, Kubernetes kullanıcıları arasında canlılık (ve hazırlık) araştırmalarının amacını ve bunların doğru kullanımını anlama konusunda sorunlar olduğunu defalarca fark etti. Bu nedenle düşüncelerini, sonunda K8 belgelerinin bir parçası haline gelecek olan bu geniş notta topladı.

Kubernetes'te şu şekilde bilinen durum denetimleri: canlılık araştırmaları (yani kelimenin tam anlamıyla "yaşayabilirlik testleri" - yaklaşık çeviri.)oldukça tehlikeli olabilir. Mümkünse bunlardan kaçınmanızı öneririm: Tek istisna, bunların gerçekten gerekli olduğu ve bunların kullanımının ayrıntılarının ve sonuçlarının tamamen farkında olduğunuz durumlardır. Bu yayında canlılık ve hazırlık kontrollerinden bahsedilecek ve ayrıca hangi durumlarda olduğunu ve bunları kullanmamalısınız.

Meslektaşım Sandor yakın zamanda Twitter'da hazırlık/canlılık araştırmalarının kullanımıyla ilgili olanlar da dahil olmak üzere karşılaştığı en yaygın hataları paylaştı:

Yanlış yapılandırılmış livenessProbe yüksek yük durumlarını (kartopu kapatma + potansiyel olarak uzun kapsayıcı/uygulama başlatma süresi) ağırlaştırabilir ve bağımlılığın azalması gibi diğer olumsuz sonuçlara yol açabilir (Ayrıca bakınız son makalem K3s+ACME kombinasyonundaki istek sayısının sınırlandırılması hakkında). Canlılık araştırması, harici bir veritabanı olan sağlık kontrolüyle birleştirildiğinde durum daha da kötüdür: tek bir veritabanı hatası tüm kapsayıcılarınızı yeniden başlatır!

Genel mesaj "Canlılık problarını kullanmayın" bu durumda pek bir faydası olmuyor o yüzden hazırlık ve canlılık kontrollerinin ne işe yaradığına bakalım.

Not: Aşağıdaki testlerin çoğu orijinal olarak Zalando'nun dahili geliştirici belgelerine dahil edilmiştir.

Hazırlık ve Canlılık kontrolleri

Kubernetes, adı verilen iki önemli mekanizma sağlar. Canlılık araştırmaları ve hazırlık araştırmaları. Uygulamanın beklendiği gibi çalıştığını doğrulamak için düzenli olarak bir HTTP isteği göndermek, TCP bağlantısı açmak veya kapsayıcıda bir komut yürütmek gibi bazı eylemler gerçekleştirirler.

Kubernetes'in kullanım alanları hazırlık sondalarıKonteynerin ne zaman trafiği kabul etmeye hazır olduğunu anlamak için. Tüm kapları hazırsa bir kapsül kullanıma hazır kabul edilir. Bu mekanizmanın bir kullanımı, Kubernetes hizmetleri (ve özellikle Ingress) için hangi bölmelerin arka uç olarak kullanıldığını kontrol etmektir.

Canlılık araştırmaları Kubernetes'in konteyneri yeniden başlatma zamanının geldiğini anlamasına yardımcı olun. Örneğin, böyle bir kontrol, bir uygulama tek bir yerde sıkışıp kaldığında ortaya çıkan çıkmaza müdahale etmenize olanak tanır. Kapsayıcının bu durumda yeniden başlatılması, hatalara rağmen uygulamanın ayağa kalkmasına yardımcı olur, ancak aynı zamanda ardışık arızalara da yol açabilir (aşağıya bakın).

Canlılık/hazırlık kontrollerini geçemeyen bir uygulama güncellemesini dağıtmaya çalışırsanız Kubernetes durumu beklediği için kullanıma sunulması durdurulacaktır. Ready tüm bölmelerden.

Örnek

Burada bir yolu kontrol eden hazırlık araştırmasının bir örneği verilmiştir /health varsayılan ayarlarla HTTP aracılığıyla (aralık: 10 saniye, zaman aşımı: 1 saniye, başarı eşiği: 1, başarısızlık eşiği: 3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

Öneriler

HTTP uç noktasına (REST vb.) sahip mikro hizmetler için her zaman bir hazırlık sondası tanımlayınuygulamanın (pod) trafiği kabul etmeye hazır olup olmadığını kontrol eder.
Hazırlık sondasının olduğundan emin olun. gerçek web sunucusu bağlantı noktasının kullanılabilirliğini kapsar:
- "yönetici" veya "yönetim" (örneğin, 9090) olarak adlandırılan bağlantı noktalarını yönetim amacıyla kullanmak, readinessProbe, uç noktanın yalnızca birincil HTTP bağlantı noktasının (8080 gibi) trafiği kabul etmeye hazır olması durumunda Tamam döndürdüğünden emin olun*;
  *Zalando'da bunun gerçekleşmediği en az bir vakanın farkındayım; readinessProbe "Yönetim" bağlantı noktasını kontrol ettim, ancak önbellek yükleme sorunları nedeniyle sunucunun kendisi çalışmaya başlamadı.
- ayrı bir bağlantı noktasına hazırlık araştırması eklemek, ana bağlantı noktasındaki aşırı yükün durum denetimine yansıtılmamasına neden olabilir (yani, sunucudaki iş parçacığı havuzu dolu, ancak durum denetimi hala her şeyin yolunda olduğunu gösteriyor) ).
Emin olun Hazırlık araştırması, veritabanı başlatma/geçişini mümkün kılar;
- Bunu başarmanın en kolay yolu, yalnızca başlatma tamamlandıktan sonra HTTP sunucusuyla iletişime geçmektir (örneğin, bir veritabanını Uçuş yolu ve benzeri.); yani, sağlık kontrolü durumunu değiştirmek yerine, veritabanı geçişi tamamlanana kadar web sunucusunu başlatmayın*.
  * Veritabanı geçişlerini bölmenin dışındaki init kapsayıcılarından da çalıştırabilirsiniz. Hala bağımsız uygulamaların, yani uygulama konteynerinin veritabanını harici koordinasyon olmadan istenen duruma nasıl getireceğini bildiği uygulamaların hayranıyım.
Kullanmak httpGet tipik durum kontrolü uç noktaları aracılığıyla hazırlık kontrolleri için (örneğin, /health).
Varsayılan kontrol parametrelerini anlayın (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- varsayılan seçenekler bölmenin olacağı anlamına gelir hazır değil yaklaşık 30 saniye sonra (3 başarısız akıl sağlığı kontrolü).
Sağlık ve ölçüm yönetimini normal trafikten ayırmak için teknoloji yığını (örneğin Java/Spring) izin veriyorsa "yönetim" veya "yönetim" için ayrı bir bağlantı noktası kullanın:
- ama 2. noktayı unutmayın.
Gerekirse, önbelleği ısıtmak/yüklemek ve kapsayıcı ısınana kadar 503 durum kodunu döndürmek için hazırlık araştırması kullanılabilir:
- Ayrıca yeni çeki okumanızı tavsiye ederim startupProbe, 1.16 sürümünde göründü (bunun hakkında Rusça yazdık burada - yaklaşık. çeviri.).

Dikkat

Dış bağımlılıklara güvenmeyin (veri ambarları gibi) hazırlık/canlılık testleri çalıştırılırken - bu, ardışık arızalara yol açabilir:
- Örnek olarak, bir Postgres veritabanına bağlı olarak 10 bölmeli durum bilgisi olan bir REST hizmetini ele alalım: kontrol, DB ile çalışan bir bağlantıya bağlı olduğunda, ağ/DB tarafında bir gecikme varsa 10 bölmenin tümü başarısız olabilir - genellikle her şey olabileceğinden daha kötü biter;
- Spring Data'nın varsayılan olarak veritabanı bağlantısını kontrol ettiğini lütfen unutmayın*;
  * Bu, Spring Data Redis'in varsayılan davranışıdır (en azından son kontrol ettiğimde öyleydi), bu da "felaket" bir hataya yol açtı: Redis kısa bir süreliğine kullanılamadığında tüm bölmeler "çöktü".
- Bu anlamda "harici", aynı uygulamanın diğer bölmeleri anlamına da gelebilir; yani, basamaklı çökmeleri önlemek için ideal olarak denetim, aynı kümedeki diğer bölmelerin durumuna bağlı olmamalıdır:
  - sonuçlar, dağıtılmış durumdaki uygulamalar için farklılık gösterebilir (örneğin, bölmelerde bellek içi önbelleğe alma).
Canlılık sondası kullanmayın kapsüller için (gerçekten gerekli oldukları ve kullanımlarının özelliklerinin ve sonuçlarının tamamen farkında olduğunuz durumlar istisnadır):
- Bir canlılık araştırması asılı konteynerlerin kurtarılmasına yardımcı olabilir, ancak uygulamanız üzerinde tam kontrole sahip olduğunuz için, askıda kalan süreçler ve kilitlenmeler gibi şeylerin ideal olarak gerçekleşmemesi gerekir: en iyi alternatif, uygulamayı kasıtlı olarak çökertmek ve onu önceki sabit durumuna geri getirmektir;
- Başarısız bir canlılık araştırması, konteynerin yeniden başlatılmasına neden olur ve bu da potansiyel olarak önyüklemeyle ilgili hataların etkilerini artırır: konteynerin yeniden başlatılması, kesinti süresine neden olur (en azından uygulama başlatma süresi boyunca, örneğin 30+ saniye), yeni hatalara neden olur, diğer konteynerler üzerindeki yükün arttırılması ve arıza olasılığının arttırılması vb.;
- Dış bağımlılıkla birleştirilmiş canlılık kontrolleri, olası en kötü kombinasyondur ve ardışık arızalarla tehdit eder: veritabanı tarafında hafif bir gecikme, tüm konteynerlerinizin yeniden başlatılmasına yol açacaktır!
Canlılık ve hazırlık kontrollerinin parametreleri farklı olmalı:
- aynı durum kontrolüne sahip ancak daha yüksek bir yanıt eşiğine sahip bir canlılık araştırması kullanabilirsiniz (failureThreshold), örneğin durumu atayın hazır değil 3 denemeden sonra canlılık probunun 10 denemeden sonra başarısız olduğunu düşünün;
Exec kontrollerini kullanmayınzombi süreçlerinin ortaya çıkmasına neden olan bilinen sorunlarla ilişkili oldukları için:
- ayrıntılar: bkz. Datadog uzmanlarının sunumu.

Özet

Bir kapsülün ne zaman trafik almaya hazır olduğunu belirlemek için hazırlık araştırmalarını kullanın.
Canlılık problarını yalnızca gerçekten ihtiyaç duyulduğunda kullanın.
Hazırlık/canlılık problarının yanlış kullanımı kullanılabilirliğin azalmasına ve ardışık arızalara yol açabilir.

Konuyla ilgili ek materyaller

Kubernetes belgeleri: Canlılık ve Hazırlık Araştırmalarını Yapılandırma;
Kubernetes Canlılık ve Hazırlık Araştırmaları Yeniden İncelendi: Kendinizi Diğer Ayağından Vurmaktan Nasıl Kaçınabilirsiniz?;
NRE Laboratuvarlarında Otopsi Sonrası Kesinti (aynı zamanda livenessProbe'dan da bahsediyor).

1-2019-09'dan 29 No'lu Güncelleme

Veritabanı geçişi için init kapsayıcıları hakkında: Dipnot eklendi.

EJ hatırlattı PDB hakkında: Canlılık kontrolleriyle ilgili sorunlardan biri, bölmeler arasındaki koordinasyon eksikliğidir. Kubernetes'in sahip olduğu Pod Kesinti Bütçeleri (PDB) Bir uygulamanın karşılaşabileceği eşzamanlı hataların sayısını sınırlamak için; ancak kontroller PDB'yi dikkate almaz. İdeal olarak, K8'lere "Test başarısız olursa bir bölmeyi yeniden başlatın, ancak işleri daha da kötüleştirmemek için hepsini yeniden başlatmayın" diyebiliriz.

Bryan mükemmel bir şekilde ifade etti: “Tam olarak ne olduğunu bildiğiniz zaman canlılık araştırmasını kullanın. yapılacak en iyi şey uygulamayı öldürmektir"(yine, kendinizi kaptırmayın).

2-2019-09'dan 29 No'lu Güncelleme

Kullanmadan önce belgelerin okunmasıyla ilgili: İlgili isteği oluşturdum (özellik isteği) canlılık araştırmaları hakkında belgeler eklemek için.

çevirmenden PS

Blogumuzda da okuyun:

Kaynak: habr.com

Kubernetes'teki canlılık araştırmaları tehlikeli olabilir