Uluslararası bir gizem adamı olan Austin Powers, "Tehlike benim göbek adımdır" derdi. Ancak süper ajanların ve istihbarat servislerinin büyük saygı duyduğu şey, can sıkıntısının tehlikeden çok daha iyi olduğu bilgisayar hizmetleri için hiç de uygun değil.
Istio, OpenShift ve Kubernetes ile birlikte mikro hizmetlerin dağıtımını gerçekten sıkıcı ve öngörülebilir hale getiriyor ve bu harika. Bu konuyu ve çok daha fazlasını Istio serisinin dördüncü ve son gönderisinde konuşacağız.
Can sıkıntısı doğru olduğunda
Bizim durumumuzda can sıkıntısı yalnızca son aşamada, geriye sadece oturup süreci izlemek kaldığında ortaya çıkar. Ancak bunun için önce her şeyi yapılandırmanız gerekiyor ve burada sizi birçok ilginç şey bekliyor.
Yazılımınızın yeni bir sürümünü dağıtırken, riskleri en aza indirmek için tüm seçenekleri göz önünde bulundurmaya değer. Paralel olarak çalışmak, test etmenin çok güçlü ve kanıtlanmış bir yoludur ve Istio, üretim sistemine müdahale etmeden bunu yapmanız için bir "gizli hizmet" (mikro hizmetinizin gizli bir sürümü) kullanmanıza olanak tanır. Bunun için özel bir terim bile var: "Dark Launch", bu da aynı casus adı olan "trafik yansıtma" işleviyle etkinleştiriliyor.
Lütfen önceki paragrafın ilk cümlesinin "yayınlamak" yerine "dağıtmak" terimini kullandığını unutmayın. Mikro hizmetinizi gerçekten istediğiniz sıklıkta dağıtabilmeniz ve elbette kullanabilmeniz gerekir. Bu hizmetin trafiği alıp işleyebilmesi, sonuç üretebilmesi ve ayrıca günlüklere yazıp izleyebilmesi gerekir. Ancak aynı zamanda bu hizmetin kendisinin de üretime geçmesi gerekmez. Yazılımı dağıtmak ve yayınlamak her zaman aynı şey değildir. İstediğiniz zaman dağıtabilirsiniz, ancak yalnızca hazır olduğunuzda yayınlayabilirsiniz.
Can sıkıntısını organize etmek ilginçtir
Tüm HTTP isteklerini mikro hizmet önerisi v1'e yönlendiren aşağıdaki Istio yönlendirme kuralına göz atın (tüm örnekler şuradan alınmıştır: ), aynı anda bunları öneri v2 mikro hizmetine yansıtırken:
Etikete dikkat edin mirror: ekranın alt kısmında - trafik yansıtmayı ayarlayan budur. Evet, bu kadar basit!
Bu kuralın sonucu, üretim sisteminizin (v1) gelen istekleri işlemeye devam etmesi, ancak isteklerin kendilerinin eşzamansız olarak v2'ye yansıtılması, yani tam kopyalarının oraya gitmesi olacaktır. Bu şekilde v2'yi gerçek koşullarda, gerçek veriler ve trafik üzerinde, üretim sisteminin çalışmasına hiçbir şekilde müdahale etmeden test edebilirsiniz. Bu, test organizasyonunu sıkıcı hale getiriyor mu? Evet kesinlikle. Ama bu ilginç bir şekilde yapılıyor.
Drama ekleyelim
Lütfen v2 kodunda, gelen isteklerin veri değişikliklerine yol açabileceği durumların sağlanması gerektiğini unutmayın. İsteklerin kendisi kolayca ve şeffaf bir şekilde yansıtılır, ancak testteki işleme yönteminin seçimi size bağlıdır ve bu biraz endişe vericidir.
Önemli bir noktayı tekrarlayalım
Trafik yansıtma (Dark Launch/Request Mirroring) ile gizli başlatma, kodu hiçbir şekilde etkilemeden gerçekleştirilebilir.
Düşünce için yiyecek
İsteklerin yansıtıldığı yer bunların bir kısmını v1'e değil de v2'ye gönderirse ne olur? Örneğin tüm isteklerin yüzde biri veya yalnızca belirli bir kullanıcı grubundan gelen istekler. Ve sonra zaten v2'nin nasıl çalıştığına bakarak, tüm istekleri yavaş yavaş yeni sürüme aktarın. Veya tam tersi, v1'de bir şeyler ters giderse her şeyi v2'e döndürün. Sanırım buna Kanarya Dağıtımı deniyor. ve eğer Rus kökenli olsaydı muhtemelen şuna bir referans içerecekti: ) ve şimdi buna daha ayrıntılı olarak bakacağız.
Istio'da Canary Dağıtımı: devreye almayı basitleştirme
Dikkatlice ve yavaş yavaş
Canary Dağıtım dağıtım modelinin özü son derece basittir: Yazılımınızın yeni bir sürümünü (bizim durumumuzda bir mikro hizmet) başlattığınızda, önce küçük bir kullanıcı grubuna erişim izni verirsiniz. Her şey yolunda giderse, yeni sürüm çalışmaya başlayana kadar bu grubu yavaş yavaş artırırsınız veya - eğer işe yaramazsa - sonunda tüm kullanıcıları bu sürüme geçirirsiniz. Yeni bir sürümü dikkatlice ve kademeli olarak sunarak ve kullanıcıları kontrollü bir şekilde ona geçirerek riskleri azaltabilir ve geri bildirimi en üst düzeye çıkarabilirsiniz.
Elbette Istio, akıllı istek yönlendirme için çeşitli iyi seçenekler sunarak Canary Dağıtımını basitleştirir. Ve evet, tüm bunlar kaynak kodunuza hiçbir şekilde dokunmadan yapılabilir.
Tarayıcıyı filtreleme
En basit yönlendirme kriterlerinden biri tarayıcı tabanlı yeniden yönlendirmedir. Diyelim ki yalnızca Safari tarayıcılarından gelen isteklerin v2'ye gitmesini istiyorsunuz. İşte nasıl yapıldığı:
Bu yönlendirme kuralını uygulayalım ve ardından komutu kullanalım. curl Mikro hizmete yönelik gerçek istekleri bir döngü içinde simüle edeceğiz. Ekran görüntüsünde görebileceğiniz gibi hepsi v1'e gidiyor:
V2'de trafik nerede? Örneğimizde tüm istekler yalnızca kendi komut satırımızdan geldiğinden, böyle bir şey mevcut değildir. Ancak yukarıdaki ekranın alt satırlarına dikkat edin: Bu, Safari tarayıcısından gelen bir isteği yerine getirmemize bir tepkidir ve bu da şunu üretti:
Sınırsız güç
Düzenli ifadelerin yönlendirme istekleri için çok güçlü yetenekler sağladığını zaten yazmıştık. Aşağıdaki örneğe bir göz atın (ne yaptığını anlayacağınızı düşünüyoruz):
Artık muhtemelen normal ifadelerin neler yapabileceğine dair bir fikriniz vardır.
Akıllı Davran
Akıllı yönlendirme, özellikle de paket başlıklarının düzenli ifadeler kullanılarak işlenmesi, trafiği istediğiniz şekilde yönlendirmenize olanak tanır. Ve bu, yeni kodun uygulanmasını büyük ölçüde basitleştirir - basittir, kodun kendisinin değiştirilmesini gerektirmez ve gerekirse her şey hızlı bir şekilde eski haline döndürülebilir.
Fırsatları
Bilgisayarınızda Istio, Kubernetes ve OpenShift'i denemeye istekli misiniz? Takım mükemmel hazırladı Bu konuyla ilgili ve beraberindeki tüm dosyaları kamuya açık hale getirdik. Öyleyse devam edin ve kendinize hiçbir şeyi inkar etmeyin.
Istio Egress: hediyelik eşya dükkanından çıkış
Istio'yu Red Hat OpenShift ve Kubernetes ile birlikte kullanarak mikro hizmetlerle hayatınızı çok daha kolaylaştırabilirsiniz. Istio'nun hizmet ağı Kubernetes bölmelerinin içinde gizlidir ve kodunuz (çoğunlukla) yalıtılmış olarak çalışır. Performans, değişim kolaylığı, izleme vb. – sepetli konteynerlerin kullanımı sayesinde tüm bunların kullanımı kolaydır. Peki ya mikro hizmetinizin OpenShift-Kubernetes sisteminizin dışında bulunan diğer hizmetlerle iletişim kurması gerekiyorsa?
Burası Istio Egress'in kurtarmaya geldiği yer. Özetle, Kubernetes bölmeleri sisteminizin parçası olmayan kaynaklara (okuyun: "hizmetler") erişmenize olanak tanır. Ek yapılandırma yapmazsanız Istio Egress ortamında trafik yalnızca bir bölme kümesi içinde ve bu tür kümeler arasında dahili IP tablolarına göre yönlendirilir. Ve dışarıdan hizmetlere erişmeniz gerekmediği sürece bu tür bir pupasyon harika çalışıyor.
Çıkış, Çıkış kurallarına veya bir dizi IP adresine dayalı olarak yukarıdaki IP tablolarını atlamanıza olanak tanır.
Diyelim ki httpbin.org/headers adresine GET isteğinde bulunan bir Java programımız var.
(httpbin.org giden hizmet isteklerini test etmek için yalnızca uygun bir kaynaktır.)
Komut satırına girerseniz curl http://httpbin.org/headers, aşağıdakileri göreceğiz:
Veya aynı adresi tarayıcıda açabilirsiniz:
Gördüğünüz gibi orada bulunan servis kendisine iletilen başlıkları döndürüyor.
İthalat ikamesi doğrudan
Şimdi sistemimiz dışında bulunan bu servisin Java kodunu alıp, hatırlayın Istio’nun kurulu olduğu yerde kendimizde çalıştıralım. (Bunu kendiniz iletişime geçerek yapabilirsiniz. .) Uygun imajı oluşturup OpenShift platformunda başlattıktan sonra bu hizmeti şu komutla çağıracağız: curl egresshttpbin-istioegress.$(minishift ip).nip.io, ardından bunu ekranda göreceğiz:
Ne oldu? Her şey işe yaradı. Bulunamadı ne anlama geliyor? Bunu sadece onun için yaptık curl.
IP tablolarını tüm İnternet'e genişletme
Bunun için Istio'nun suçlanması (veya teşekkür edilmesi) gerekir. Sonuçta Istio, tespit ve yönlendirmeden (ve daha önce bahsettiğimiz diğer birçok şeyden) sorumlu sepet konteynerlerinden ibarettir. Bu nedenle IP tabloları yalnızca küme sisteminizin içinde ne olduğunu bilir. Ve httpbin.org dışarıda bulunuyor ve bu nedenle erişilemiyor. Kaynak kodunuzda en ufak bir değişiklik yapmadan, Istio Egress'in kurtarmaya geldiği yer burasıdır.
Aşağıdaki Çıkış kuralı, Istio'yu gerekli hizmeti, bu durumda httpbin.org'u (gerekirse tüm İnternet'te) aramaya zorlar. Bu dosyadan (egress_httpbin.yml) görebileceğiniz gibi, buradaki işlevsellik oldukça basittir:
Geriye kalan tek şey bu kuralı uygulamaktır:
istioctl create -f egress_httpbin.yml -n istioegress
Çıkış kurallarını şu komutla görüntüleyebilirsiniz: istioctl get egressrules:
Ve son olarak komutu tekrar çalıştırıyoruz kıvırmak – ve her şeyin işe yaradığını görüyoruz:
Açıkça düşünüyoruz
Gördüğünüz gibi Istio, dış dünyayla etkileşimi düzenlemenize olanak tanıyor. Başka bir deyişle, yine de OpenShift hizmetleri oluşturabilir ve bunları Kubernetes aracılığıyla yönetebilir, böylece her şeyi gerektiği gibi büyütüp küçülten bölmelerde tutabilirsiniz. Aynı zamanda ortamınızın dışındaki hizmetlere de güvenle erişebilirsiniz. Ve evet, tüm bunların hiçbir şekilde kodunuza dokunmadan yapılabileceğini bir kez daha tekrarlıyoruz.
Bu, Istio'daki serinin son yazısıydı. Bizi izlemeye devam edin - ileride pek çok ilginç şey var!
Kaynak: habr.com