Tatil bitti ve Istio Service Mesh serisindeki ikinci yazımızla geri döndük.
Bugünün konusu, Rusça elektrik mühendisliğinde "devre kesici" anlamına gelen, halk dilinde "devre kesici" anlamına gelen Circuit Breaker'dır. Yalnızca Istio'da bu makine kısa devre veya aşırı yüklenmiş bir devrenin bağlantısını kesmez, ancak arızalı kapların bağlantısını keser.
Bunun ideal olarak nasıl çalışması gerektiği
Mikro hizmetler Kubernetes tarafından (örneğin OpenShift platformunda) yönetildiğinde, yüke bağlı olarak otomatik olarak ölçeklendirilir ve küçültülür. Mikro hizmetler bölmeler halinde çalıştığından, bir uç noktada kapsayıcıya alınmış bir mikro hizmetin birden fazla örneği olabilir ve Kubernetes, istekleri yönlendirir ve bunlar arasında yük dengesini sağlar. Ve - ideal olarak - tüm bunların mükemmel şekilde çalışması gerekir.
Mikro hizmetlerin küçük ve geçici olduğunu hatırlıyoruz. Burada ortaya çıkma ve kaybolma kolaylığı anlamına gelen geçicilik çoğu zaman hafife alınmaktadır. Bir kapsülde başka bir mikro hizmet örneğinin doğuşu ve ölümü oldukça beklenen şeylerdir; OpenShift ve Kubernetes bunu iyi bir şekilde hallediyor ve her şey harika çalışıyor - ama yine teoride.
Gerçekten nasıl çalışıyor?
Şimdi bir mikro hizmetin belirli bir örneğinin, yani bir konteynerin kullanılamaz hale geldiğini hayal edin: ya yanıt vermiyor (hata 503) ya da daha rahatsız edici olanı, yanıt veriyor, ancak çok yavaş. Yani hata veriyor veya isteklere cevap vermiyor ama otomatik olarak havuzdan kaldırılmıyor. Bu durumda ne yapılmalı? Yeniden denemek için mi? Bunu yönlendirme şemasından kaldırmalı mıyım? Peki "çok yavaş" ne anlama geliyor; sayı olarak kaç tane var ve bunları kim belirliyor? Belki biraz ara verip daha sonra tekrar deneyebiliriz? Eğer öyleyse, ne kadar sonra?
Istio'da Havuz Fırlatma Nedir?
Ve burada Istio, hatalı konteynerleri yönlendirme ve yük dengeleme kaynak havuzundan geçici olarak kaldıran ve Havuz Çıkarma prosedürünü uygulayan Devre Kesici koruma makineleriyle kurtarmaya geliyor.
Istio, bir aykırı değer tespit stratejisi kullanarak çizgiyi aşan bölme eğrilerini tespit eder ve bunları uyku penceresi adı verilen önceden belirlenmiş bir süre boyunca kaynak havuzundan kaldırır.
Bunun OpenShift platformundaki Kubernetes'te nasıl çalıştığını göstermek için, depodaki örnekten normal şekilde çalışan mikro hizmetlerin ekran görüntüsüyle başlayalım. . Burada her biri bir konteyner çalıştıran v1 ve v2 olmak üzere iki bölmemiz var. Istio yönlendirme kuralları kullanılmadığında Kubernetes varsayılan olarak eşit dengeli, dönüşümlü yönlendirmeyi kullanır:
Bir kazaya hazırlanıyoruz
Havuz Çıkarma işlemini yapmadan önce bir Istio yönlendirme kuralı oluşturmanız gerekir. Diyelim ki istekleri podlar arasında 50/50 oranında dağıtmak istiyoruz. Ek olarak v2 kapsayıcılarının sayısını şu şekilde birden ikiye çıkaracağız:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Şimdi trafiğin podlar arasında 50/50 oranında dağıtılması için bir yönlendirme kuralı belirledik.
Bu kuralın sonucu şöyle görünür:
Bu ekranın 50/50 değil 14:9 olmasında hata bulabilirsiniz ama zamanla durum düzelecektir.
Bir aksaklık yapmak
Şimdi iki v2 kapsayıcısından birini devre dışı bırakalım, böylece bir sağlıklı v1 kapsayıcımız, bir sağlıklı v2 kapsayıcımız ve bir hatalı v2 kapsayıcımız olsun:
Aksaklığın düzeltilmesi
Yani hatalı bir konteynerimiz var ve Havuzdan Çıkarma zamanı geldi. Çok basit bir yapılandırma kullanarak, bu başarısız kapsayıcıyı, sağlıklı bir duruma dönmesi (yeniden başlatma veya performansı geri yükleme) umuduyla 15 saniye boyunca herhangi bir yönlendirme şemasından hariç tutacağız. Bu yapılandırmanın neye benzediği ve çalışmasının sonuçları şöyle:
Gördüğünüz gibi, başarısız olan v2 kapsayıcısı artık havuzdan kaldırıldığı için yönlendirme istekleri için kullanılmıyor. Ancak 15 saniye sonra otomatik olarak havuza geri dönecektir. Aslında az önce Havuzdan Çıkarmanın nasıl çalıştığını gösterdik.
Mimarlık inşa etmeye başlayalım
Havuz Çıkarma, Istio'nun izleme yetenekleriyle birleştiğinde, arıza süresini ve arızaları ortadan kaldırmasa bile azaltmak amacıyla hatalı konteynerleri otomatik olarak değiştirmek için bir çerçeve oluşturmaya başlamanıza olanak tanır.
NASA'nın yüksek sesli bir sloganı var - Yazarı uçuş direktörü olarak kabul edilen Başarısızlık Bir Seçenek Değildir . Rusçaya “Başarısızlık bir seçenek değildir” şeklinde tercüme edilebilir ve buradaki anlam, yeterli iradeye sahipseniz her şeyin işe yarayabileceğidir. Ancak gerçek hayatta başarısızlıklar öylece gerçekleşmez, her yerde ve her şeyde kaçınılmazdır. Mikro hizmetler durumunda onlarla nasıl başa çıkılır? Bize göre iradeye değil, konteynerlerin yeteneklerine güvenmek daha iyidir. , ve .
Istio, yukarıda yazdığımız gibi fiziksel dünyada kendini kanıtlamış olan devre kesici konseptini uygulamaktadır. Ve tıpkı bir elektrik devre kesicisinin bir devrenin sorunlu bölümünü kapatması gibi, Istio'nun yazılımı Circuit Breaker da uç noktada bir sorun olduğunda (örneğin, sunucu çöktüğünde veya çökmeye başladığında) bir istek akışı ile sorunlu kapsayıcı arasındaki bağlantıyı açar. yavaşla.
Dahası, ikinci durumda daha fazla sorun ortaya çıkar, çünkü bir konteynerin frenleri yalnızca ona erişen hizmetlerde art arda gecikmelere neden olmakla kalmaz, bunun sonucunda bir bütün olarak sistemin performansını düşürür, aynı zamanda tekrarlanan gecikmelere neden olur. Zaten yavaş çalışan bir hizmete yapılan talepler durumu daha da kötüleştiriyor.
Teoride Devre Kesici
Circuit Breaker, isteklerin bir uç noktaya akışını kontrol eden bir proxy'dir. Bu nokta çalışmayı durdurduğunda veya belirtilen ayarlara bağlı olarak yavaşlamaya başladığında proxy'nin konteynerle bağlantısı kesilir. Daha sonra trafik, yük dengeleme nedeniyle diğer konteynerlere yönlendirilir. Bağlantı belirli bir uyku penceresi boyunca (örneğin iki dakika) açık kalır ve ardından yarı açık olarak kabul edilir. Bir sonraki isteği gönderme girişimi, bağlantının sonraki durumunu belirler. Hizmette her şey yolundaysa bağlantı çalışır duruma döner ve tekrar kapanır. Hizmette hâlâ bir sorun varsa bağlantı kesilir ve uyku penceresi yeniden etkinleştirilir. Basitleştirilmiş bir Devre Kesici durum şeması şöyle görünür:
Burada tüm bunların tabiri caizse sistem mimarisi düzeyinde gerçekleştiğini belirtmek önemlidir. Dolayısıyla bir noktada uygulamalarınıza, yanıt olarak varsayılan bir değer sağlamak veya mümkünse hizmetin varlığını göz ardı etmek gibi Circuit Breaker ile çalışmayı öğretmeniz gerekecektir. Bunun için bir bölme modeli kullanılır, ancak bu makalenin kapsamı dışındadır.
Devre Kesici pratikte
Örneğin, tavsiye mikro hizmetimizin iki versiyonunu OpenShift'te çalıştıracağız. Sürüm 1 iyi çalışacak, ancak v2'de sunucudaki yavaşlamaları simüle etmek için bir gecikme oluşturacağız. Sonuçları görüntülemek için aracı kullanın :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Her şey işe yarıyor gibi görünüyor, ama ne pahasına? İlk bakışta %100 kullanılabilirliğe sahibiz, ancak daha yakından baktığımızda maksimum işlem süresinin 12 saniye kadar olduğunu görüyoruz. Bu açıkça bir darboğazdır ve genişletilmesi gerekmektedir.
Bunu yapmak için yavaş konteynerlere yapılan çağrıları ortadan kaldırmak için Istio'yu kullanacağız. Devre Kesici kullanıldığında ilgili yapılandırma şu şekilde görünür:
httpMaxRequestsPerConnection parametresini içeren son satır, mevcut bağlantıya ek olarak ikinci bir bağlantı oluşturmaya çalışırken ile bağlantının kesilmesi gerektiğini belirtir. Konteynerimiz yavaş bir hizmeti simüle ettiğinden, bu tür durumlar periyodik olarak ortaya çıkacak ve ardından Istio 503 hatası döndürecektir, ancak kuşatma şunu gösterecektir:
Tamam, Devre Kesicimiz var, sırada ne var?
Bu nedenle, hizmetlerin kaynak koduna hiç dokunmadan otomatik kapatmayı uyguladık. Devre Kesiciyi ve yukarıda açıklanan Havuz Çıkarma prosedürünü kullanarak, fren konteynerlerini normale dönene kadar kaynak havuzundan çıkarabilir ve durumlarını belirli bir sıklıkta kontrol edebiliriz - örneğimizde bu iki dakikadır (sleepWindow parametresi).
Bir uygulamanın 503 hatasına yanıt verme yeteneğinin hâlâ kaynak kodu düzeyinde ayarlandığını unutmayın. Duruma bağlı olarak Circuit Breaker'ı kullanmanın birçok stratejisi vardır.
Bir sonraki yazıda: Halihazırda yerleşik olan veya Istio'ya kolayca eklenen izleme ve izlemenin yanı sıra sisteme kasıtlı olarak nasıl hatalar ekleneceği hakkında konuşacağız.
Kaynak: habr.com
