Kubernetes Container'ları için En İyi Uygulamalar: Durum Denetimleri

TL; DR

• Konteynerlerin ve mikro hizmetlerin yüksek gözlemlenebilirliğine ulaşmak için günlükler ve birincil ölçümler yeterli değildir.
• Daha hızlı kurtarma ve daha fazla esneklik için uygulamaların Yüksek Gözlenebilirlik İlkesini (HOP) uygulaması gerekir.
• Uygulama düzeyinde NOP şunları gerektirir: uygun günlük kaydı, yakın izleme, akıl sağlığı kontrolleri ve performans/geçiş takibi.
• NOR'un bir unsuru olarak çekleri kullanın hazırlıkSondası и canlılık Sondası Kubernet'ler.

Durum Denetimi Şablonu nedir?

Görev açısından kritik ve yüksek düzeyde kullanılabilir bir uygulama tasarlarken hata toleransı gibi bir hususu düşünmek çok önemlidir. Bir uygulama, hatadan hızlı bir şekilde kurtulursa hataya dayanıklı olarak kabul edilir. Tipik bir bulut uygulaması, her bileşenin ayrı bir konteynere yerleştirildiği bir mikro hizmet mimarisini kullanır. Ve bir küme tasarlarken k8s üzerindeki uygulamanın yüksek oranda kullanılabilir olduğundan emin olmak için belirli kalıpları takip etmeniz gerekir. Bunların arasında Sağlık Kontrolü Şablonu da bulunmaktadır. Uygulamanın k8'lere sağlıklı olduğunu nasıl bildireceğini tanımlar. Bu yalnızca bölmenin çalışıp çalışmadığına ilişkin bilgi değil, aynı zamanda istekleri nasıl alıp yanıtladığıyla da ilgilidir. Kubernetes, kapsülün durumu hakkında ne kadar çok şey bilirse, trafik yönlendirme ve yük dengeleme konusunda o kadar akıllı kararlar alır. Böylece Yüksek Gözlenebilirlik Prensibi, uygulamanın taleplere zamanında yanıt vermesini sağlar.

Yüksek Gözlemlenebilirlik Prensibi (HOP)

Yüksek gözlemlenebilirlik ilkesi aşağıdakilerden biridir: Container mimarisine alınmış uygulamaları tasarlama ilkeleri. Mikro hizmet mimarisinde hizmetler, isteklerinin nasıl işlendiği (ve haklı olarak öyle) ile ilgilenmez, ancak önemli olan, alıcı hizmetlerden nasıl yanıt aldıklarıdır. Örneğin, bir kullanıcının kimliğini doğrulamak için, bir kapsayıcı diğerine bir HTTP isteği göndererek belirli bir formatta yanıt beklemektedir; hepsi bu. PythonJS de isteği işleyebilir ve Python Flask yanıt verebilir. Konteynerler birbirine gizli içerikli kara kutular gibidir. Ancak NOP ilkesi, her hizmetin ne kadar sağlıklı olduğunun yanı sıra hazırlık ve hata toleransı durumunu gösteren birden fazla API uç noktasını açığa çıkarmasını gerektirir. Kubernetes, yönlendirme ve yük dengelemeye yönelik sonraki adımları düşünmek için bu göstergeleri ister.

İyi tasarlanmış bir bulut uygulaması, ana olaylarını standart I/O akışları STDERR ve STDOUT'u kullanarak günlüğe kaydeder. Daha sonra, günlükleri merkezi bir izleme sistemine (örneğin Prometheus) ve bir günlük toplama sistemine (ELK yazılım paketi) ileten filebeat, logstash veya fluentd gibi bir yardımcı hizmet gelir. Aşağıdaki şemada bir bulut uygulamasının Sağlık Testi Modeli ve Yüksek Gözlenebilirlik Prensibine göre nasıl çalıştığı gösterilmektedir.

Kubernetes'te Sağlık Kontrolü Deseni nasıl uygulanır?

Kutunun dışında k8s, denetleyicilerden birini kullanarak bölmelerin durumunu izler (dağıtımlar, Çoğaltma Setleri, Daemon Setleri, Durumsal Kümeler vesaire vesaire.). Bölmenin bir nedenden dolayı düştüğünü fark eden denetleyici, onu yeniden başlatmaya veya başka bir düğüme taşımaya çalışır. Ancak bir bölme, çalışır durumda olduğunu ancak kendisinin çalışmadığını bildirebilir. Bir örnek verelim: uygulamanız Apache'yi web sunucusu olarak kullanıyor, bileşeni kümenin birkaç bölmesine yüklediniz. Kitaplık yanlış yapılandırıldığından uygulamaya yapılan tüm istekler 500 koduyla (dahili sunucu hatası) yanıt verir. Teslimatı kontrol ederken kapsüllerin durumunu kontrol etmek başarılı sonuç verir ancak müşteriler farklı düşünüyor. Bu istenmeyen durumu şu şekilde anlatacağız:

Örneğimizde k8s bunu yapar işlevsellik kontrolü. Bu doğrulama türünde kubelet, konteynerdeki sürecin durumunu sürekli olarak kontrol eder. Sürecin durduğunu anladığında yeniden başlatacaktır. Hata, uygulamanın yeniden başlatılmasıyla çözülebiliyorsa ve program herhangi bir hata durumunda kapatılacak şekilde tasarlanmışsa, NOP'u ve Sağlık Testi Modelini takip etmek için ihtiyacınız olan tek şey bir süreç sağlık kontrolüdür. Tek üzücü şey, yeniden başlatmayla tüm hataların ortadan kaldırılmamasıdır. Bu durumda k8s, bölmeyle ilgili sorunları tespit etmek için 2 daha derin yol sunar: canlılık Sondası и hazırlıkSondası.

Canlılık Probu

Zamanı geldi canlılık Sondası kubelet 3 tür kontrol gerçekleştirir: yalnızca bölmenin çalışıp çalışmadığını belirlemekle kalmaz, aynı zamanda istekleri almaya ve bunlara yeterince yanıt vermeye hazır olup olmadığını da belirler:

• Pod'a bir HTTP isteği ayarlayın. Yanıt, 200 ila 399 aralığında bir HTTP yanıt kodu içermelidir. Bu nedenle, 5xx ve 4xx kodları, işlem çalışıyor olsa bile bölmenin sorun yaşadığının sinyalini verir.
• Bölmeleri HTTP dışı hizmetlerle (örneğin Postfix posta sunucusu) test etmek için bir TCP bağlantısı kurmanız gerekir.
• Bir bölme için (dahili olarak) isteğe bağlı bir komut yürütün. Komut tamamlama kodu 0 ise kontrol başarılı kabul edilir.

Bunun nasıl çalıştığına bir örnek. Bir sonraki pod tanımı, HTTP isteklerinde 500 hatası atan bir NodeJS uygulamasını içeriyor.Böyle bir hata alındığında konteynerin yeniden başlatıldığından emin olmak için livenessProbe parametresini kullanıyoruz:

apiVersion: v1
kind: Pod
metadata:
 name: node500
spec:
 containers:
   - image: magalix/node500
     name: node500
     ports:
       - containerPort: 3000
         protocol: TCP
     livenessProbe:
       httpGet:
         path: /
         port: 3000
       initialDelaySeconds: 5

Bu diğer pod tanımlarından farklı değil ama bir nesne ekliyoruz .spec.containers.livenessProbe... Parametre httpGet HTTP GET isteğinin gönderildiği yolu kabul eder (örneğimizde bu /, ancak savaş senaryolarında şöyle bir şey olabilir /api/v1/status). Başka bir livenessProbe bir parametre kabul ediyor initialDelaySecondsdoğrulama işlemine belirli bir saniye kadar beklemesi talimatını verir. Gecikme gereklidir çünkü konteynerin başlaması için zamana ihtiyacı vardır ve yeniden başlatıldığında bir süreliğine kullanılamayacaktır.

Bu ayarı bir kümeye uygulamak için şunu kullanın:

kubectl apply -f pod.yaml

Birkaç saniye sonra aşağıdaki komutu kullanarak bölmenin içeriğini kontrol edebilirsiniz:

kubectl describe pods node500

Çıktının sonunda bulun bu ne.

Gördüğünüz gibi livenessProbe bir HTTP GET isteği başlattı, kapsayıcı 500 hatası oluşturdu (bu, yapmaya programlandığı şeydi) ve kubelet bunu yeniden başlattı.

NideJS uygulamasının nasıl programlandığını merak ediyorsanız işte kullanılan app.js ve Dockerfile:

uygulama.js

var http = require('http');

var server = http.createServer(function(req, res) {
    res.writeHead(500, { "Content-type": "text/plain" });
    res.end("We have run into an errorn");
});

server.listen(3000, function() {
    console.log('Server is running at 3000')
})

Dockerfile

FROM node
COPY app.js /
EXPOSE 3000
ENTRYPOINT [ "node","/app.js" ]

Şunu unutmamak önemlidir: livenessProbe yalnızca başarısız olursa kabı yeniden başlatır. Yeniden başlatma, konteynerin çalışmasını engelleyen hatayı düzeltmezse kubelet, sorunu düzeltmek için harekete geçemeyecektir.

hazırlıkSondası

readinessProbe, sorun giderme eylemleri dışında livenessProbes'a (GET istekleri, TCP iletişimleri ve komut yürütme) benzer şekilde çalışır. Arızanın tespit edildiği konteyner yeniden başlatılmaz ancak gelen trafikten izole edilir. Container'lardan birinin çok fazla hesaplama yaptığını veya ağır yük altında olduğunu, bunun da yanıt sürelerinin artmasına neden olduğunu düşünün. LivenessProbe durumunda, yanıt kullanılabilirliği kontrolü tetiklenir (timeoutSeconds kontrol parametresi aracılığıyla), ardından kubelet konteyneri yeniden başlatır. Konteyner başlatıldığında yoğun kaynak gerektiren görevleri gerçekleştirmeye başlar ve yeniden başlatılır. Bu, yanıt hızı gerektiren uygulamalar için kritik olabilir. Örneğin, bir araba yoldayken sunucudan yanıt bekler, yanıt gecikir ve araba kaza yapar.

GET isteği yanıt süresini iki saniyeyi geçmeyecek şekilde ayarlayacak ve uygulamanın GET isteğine 5 saniye sonra yanıt verecek bir redinessProbe tanımı yazalım. Pod.yaml dosyası şu şekilde görünmelidir:

apiVersion: v1
kind: Pod
metadata:
 name: nodedelayed
spec:
 containers:
   - image: afakharany/node_delayed
     name: nodedelayed
     ports:
       - containerPort: 3000
         protocol: TCP
     readinessProbe:
       httpGet:
         path: /
         port: 3000
       timeoutSeconds: 2

Kubectl ile bir pod konuşlandıralım:

kubectl apply -f pod.yaml

Birkaç saniye bekleyip, hazırlık Probunun nasıl çalıştığını görelim:

kubectl describe pods nodedelayed

Çıktının sonunda bazı olayların benzer olduğunu görebilirsiniz. Bu.

Gördüğünüz gibi kubectl, kontrol süresi 2 saniyeyi aştığında pod'u yeniden başlatmadı. Bunun yerine isteği iptal etti. Gelen iletişimler diğer çalışan bölmelere yönlendirilir.

Pod'un yükü kaldırıldığı için kubectl'in istekleri tekrar ona yönlendirdiğini unutmayın: GET isteklerine verilen yanıtlar artık gecikmez.

Karşılaştırma için değiştirilmiş app.js dosyasını aşağıda bulabilirsiniz:

var http = require('http');

var server = http.createServer(function(req, res) {
   const sleep = (milliseconds) => {
       return new Promise(resolve => setTimeout(resolve, milliseconds))
   }
   sleep(5000).then(() => {
       res.writeHead(200, { "Content-type": "text/plain" });
       res.end("Hellon");
   })
});

server.listen(3000, function() {
   console.log('Server is running at 3000')
})

TL; DR
Bulut uygulamalarının ortaya çıkmasından önce günlükler, uygulama sağlığını izlemenin ve kontrol etmenin birincil aracıydı. Ancak herhangi bir düzeltici önlem alma olanağı yoktu. Günlükler günümüzde hala kullanışlıdır; acil durumları analiz etmek ve karar vermek için toplanıp bir günlük toplama sistemine gönderilmeleri gerekir. [Bütün bunlar örneğin monit kullanan bulut uygulamaları olmadan yapılabilirdi, ancak k8s ile bu çok daha kolay hale geldi :) – editörün notu. ]

Günümüzde düzeltmelerin neredeyse gerçek zamanlı olarak yapılması gerekiyor, dolayısıyla başvuruların artık kara kutular olması gerekmiyor. Hayır, gerektiğinde anında yanıt verebilmeleri için izleme sistemlerinin süreçlerin durumu hakkında değerli verileri sorgulamasına ve toplamasına olanak tanıyan uç noktaları göstermeleri gerekir. Buna, Yüksek Gözlemlenebilirlik İlkesini (HOP) izleyen Performans Testi Tasarım Modeli adı verilir.

Kubernetes varsayılan olarak 2 tür durum denetimi sunar: readinessProbe ve livenessProbe. Her ikisi de aynı kontrol türlerini kullanır (HTTP GET istekleri, TCP iletişimleri ve komut yürütme). Bölmelerdeki sorunlara yanıt olarak aldıkları kararlarda farklılık gösterirler. livenessProbe, hatanın tekrarlanmayacağı umuduyla kapsayıcıyı yeniden başlatır ve readinessProbe, sorunun nedeni çözülene kadar bölmeyi gelen trafikten yalıtır.

Doğru uygulama tasarımı her iki kontrol türünü de içermeli ve özellikle bir istisna atıldığında yeterli veri toplandığından emin olmalıdır. Ayrıca izleme sistemine (Prometheus) önemli sağlık ölçümlerini sağlayan gerekli API uç noktalarını da göstermelidir.

Kaynak: habr.com