Dağıtık sistemlerin işleyişinde önemli bir nokta arıza yönetimidir. Kubernetes, sisteminizin sağlığını izleyen ve çalışmayı durduran hizmetleri yeniden başlatan denetleyicileri kullanarak bu konuda yardımcı olur. Ancak Kubernetes, genel sistem sağlığından emin olmak için uygulamalarınızı zorla durdurabilir. Bu seride Kubernetes'in işini daha verimli bir şekilde yapmasına ve uygulama kesinti süresini azaltmasına nasıl yardımcı olabileceğinizi inceleyeceğiz.
Konteynerlerden önce çoğu uygulama sanal veya fiziksel makinelerde çalışıyordu. Uygulamanın çökmesi veya donması durumunda, devam eden görevi iptal etmek ve programı yeniden yüklemek uzun zaman alıyordu. En kötü senaryoda, birisinin bu sorunu geceleri, en uygunsuz saatlerde manuel olarak çözmesi gerekiyordu. Önemli bir görevi yalnızca 1-2 çalışan makine gerçekleştiriyor olsaydı, böyle bir aksama kesinlikle kabul edilemezdi.
Bu nedenle, anormal bir sonlandırma durumunda uygulamayı otomatik olarak yeniden başlatmak için manuel yeniden başlatmalar yerine süreç düzeyinde izlemeyi kullanmaya başladılar. Program başarısız olursa izleme işlemi çıkış kodunu yakalar ve sunucuyu yeniden başlatır. Kubernetes gibi sistemlerin ortaya çıkışıyla birlikte sistem arızalarına yönelik bu tür yanıtlar altyapıya kolayca entegre edildi.
Kubernetes, kaynakların konteynerlerden düğümlere giden yolda sağlıklı kalmasını sağlamak için bir farkı gözlemle-harekete geç olay döngüsünü kullanır.
Bu, artık süreç izlemeyi manuel olarak çalıştırmanıza gerek olmadığı anlamına gelir. Bir kaynağın Durum Denetimi'nde başarısız olması durumunda Kubernetes, kaynağı otomatik olarak yenisiyle hazırlayacaktır. Ancak Kubernetes, uygulamanızı hatalara karşı izlemekten çok daha fazlasını yapar. Birden fazla makinede çalışacak şekilde uygulamanın daha fazla kopyasını oluşturabilir, uygulamayı güncelleyebilir veya uygulamanızın birden fazla sürümünü aynı anda çalıştırabilir.
Bu nedenle Kubernetes'in tamamen sağlıklı bir konteyneri sonlandırabilmesinin birçok nedeni vardır. Örneğin dağıtımınızı yükseltirseniz Kubernetes, yenilerini başlatırken eski kapsülleri yavaş yavaş durduracaktır. Bir düğümü kapatırsanız Kubernetes, o düğümdeki tüm bölmeleri çalıştırmayı durdurur. Son olarak, bir düğümün kaynakları biterse Kubernetes, bu kaynakları serbest bırakmak için tüm bölmeleri kapatacaktır.
Bu nedenle, uygulamanızın son kullanıcı açısından minimum etkiyle ve minimum kurtarma süresiyle sona ermesi kritik öneme sahiptir. Bu, kapatmadan önce kaydedilmesi gereken tüm verileri kaydetmesi, tüm ağ bağlantılarını kapatması, kalan işi tamamlaması ve diğer acil görevleri yönetmesi gerektiği anlamına gelir.
Uygulamada bu, uygulamanızın Unix işletim sistemlerindeki kill yardımcı programının varsayılan sinyali olan işlem sonlandırma sinyali olan SIGTERM mesajını işleyebilmesi gerektiği anlamına gelir. Bu mesajı aldıktan sonra uygulama kapatılmalıdır.
Kubernetes bir pod'u sonlandırmaya karar verdiğinde bir dizi olay meydana gelir. Kubernetes'in bir konteyneri veya kapsülü kapatırken attığı her adıma bakalım.
Diyelim ki bölmelerden birini sonlandırmak istiyoruz. Bu noktada yeni trafik almayı bırakacak; bölmede çalışan kapsayıcılar etkilenmeyecek ancak tüm yeni trafik engellenecek.
Bir bölmedeki kaplara gönderilen özel bir komut veya HTTP isteği olan preStop kancasına bakalım. Uygulamanız SIGTERM alırken doğru şekilde kapanmıyorsa, doğru şekilde kapatmak için preStop'u kullanabilirsiniz.
Çoğu program, bir SIGTERM sinyali aldıklarında sorunsuz bir şekilde çıkar, ancak üçüncü taraf kodu veya tam olarak kontrol etmediğiniz bir sistem kullanıyorsanız, preStop kancası, uygulamayı değiştirmeden sorunsuz bir kapatmaya zorlamanın harika bir yoludur.
Bu kancayı çalıştırdıktan sonra Kubernetes, bölmedeki konteynerlere bir SIGTERM sinyali göndererek bağlantılarının yakında kesileceğini bildirecek. Bu sinyali aldıktan sonra kodunuz kapatma işlemine geçecektir. Bu süreç, veritabanı bağlantısı veya WebSocket akışı gibi uzun ömürlü bağlantıların durdurulmasını, mevcut durumun kaydedilmesini ve benzerlerini içerebilir.
Bir preStop kancası kullansanız bile, uygulamanıza bir SIGTERM sinyali gönderdiğinizde uygulamanıza tam olarak ne olduğunu ve nasıl davrandığını kontrol etmek çok önemlidir, böylece sistem işleminde pod kapanmasının neden olduğu olaylar veya değişiklikler beklendiği gibi gerçekleşmez. sana bir sürpriz.
Bu noktada Kubernetes, başka bir işlem yapmadan önce, sonlandırmaGracePeriodSecond adı verilen belirli bir süreyi veya bir SIGTERM sinyali aldığında düzgün bir şekilde kapanma süresini bekleyecektir.
Varsayılan olarak bu süre 30 saniyedir. PreStop kancası ve SIGTERM sinyaliyle paralel çalıştığına dikkat etmek önemlidir. Kubernetes, preStop kancasının ve SIGTERM'in sona ermesini beklemez; uygulamanız TerminationGracePeriod sona ermeden çıkarsa Kubernetes hemen bir sonraki adıma geçer. Bu nedenle bu sürenin saniye cinsinden değerinin pod'un doğru şekilde kapatılması için gereken süreden az olmadığını kontrol edin, 30 saniyeyi geçiyorsa YAML'de süreyi istenilen değere yükseltin. Verilen örnekte 60'lardır.
Ve son olarak son adım, eğer konteynerler GracePeriod sonlandırıldıktan sonra hala çalışıyorsa, bir SIGKILL sinyali gönderecekler ve zorla silinecekler. Bu noktada Kubernetes diğer tüm pod nesnelerini de temizleyecek.
Kubernetes, pod'ları birçok nedenden dolayı sonlandırır; bu nedenle, istikrarlı bir hizmet sağlamak için uygulamanızın her durumda düzgün bir şekilde sonlandırıldığından emin olun.
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, , sizin için bizim tarafımızdan icat edilen benzersiz bir giriş seviyesi sunucu analoğu: (RAID1 ve RAID10, 24 adede kadar çekirdek ve 40 GB'a kadar DDR4 ile mevcuttur).
Amsterdam'daki Equinix Tier IV veri merkezinde Dell R730xd 2 kat daha mı ucuz? Sadece burada Hollanda'da! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99$'dan! Hakkında oku
Kaynak: habr.com