Ey Habr! Makalenin çevirisini dikkatinize sunuyorum. yazar Matt Klein.
Bu sefer hem servis ağı bileşenlerinin, hem veri düzleminin hem de kontrol düzleminin açıklamasını "istedim ve tercüme ettim". Bu açıklama bana en anlaşılır ve ilginç geldi ve en önemlisi “Hiç gerekli mi?” anlayışına yol açtı.
"Hizmet ağı" fikri son iki yılda giderek daha popüler hale geldikçe (Orijinal makale 10 Ekim 2017) ve alandaki katılımcıların sayısı arttıkça, tüm ekip arasında kafa karışıklığının da orantılı bir şekilde arttığını gördüm. Farklı çözümlerin nasıl karşılaştırılacağı ve karşılaştırılacağı konusunda teknoloji topluluğu.
Bu durumu en iyi şekilde Temmuz ayında yazdığım aşağıdaki tweet dizisi özetlemektedir:
Hizmet ağı karışıklığı #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Elçi. Hiçbiri Istio'ya eşit değil. Istio tamamen farklı bir şey. 1 /
Birincisi basitçe veri düzlemleridir. Kendi başlarına hiçbir şey yapmazlar. Daha fazlasının havasında olmalılar. 2/
Istio, parçaları birbirine bağlayan bir kontrol düzlemi örneğidir. Bu başka bir katman. /son
Önceki tweet'lerde birkaç farklı projeden (Linkerd, NGINX, HAProxy, Envoy ve Istio) bahsediliyor, ancak daha da önemlisi veri düzlemi, hizmet ağı ve kontrol düzleminin genel kavramları tanıtılıyor. Bu yazıda bir adım geriye gidip "veri düzlemi" ve "kontrol düzlemi" terimleriyle ne demek istediğimi çok yüksek düzeyde anlatacağım ve ardından bu terimlerin tweet'lerde bahsedilen projelere nasıl uygulandığından bahsedeceğim.
Gerçekten hizmet ağı nedir?
Şekil 1: Hizmet ağına genel bakış
Şekil 1 Hizmet ağı kavramını en temel düzeyde göstermektedir. Dört hizmet kümesi (AD) vardır. Her hizmet örneği yerel bir proxy sunucusuyla ilişkilendirilir. Tek bir uygulama örneğinden gelen tüm ağ trafiği (HTTP, REST, gRPC, Redis vb.) yerel bir proxy üzerinden uygun harici hizmet kümelerine aktarılır. Bu şekilde, uygulama örneği ağın bir bütün olarak farkında olmaz ve yalnızca yerel proxy'sinin farkında olur. Gerçekte, dağıtılmış sistem ağı hizmetten kaldırıldı.
Veri düzlemi
Hizmet ağında, uygulama için yerel olarak konumlandırılan bir proxy sunucusu aşağıdaki görevleri gerçekleştirir:
- Hizmet keşfi. Uygulamanız için hangi hizmetler/uygulamalar mevcut?
- Sağlık kontrolü. Hizmet keşfi tarafından döndürülen hizmet örnekleri sağlıklı mı ve ağ trafiğini kabul etmeye hazır mı? Bu, hem aktif (örneğin yanıt/durum kontrolü) hem de pasif (örneğin, sağlıksız bir hizmet durumunun göstergesi olarak art arda 3 5xx hatasının kullanılması) durum kontrollerini içerebilir.
- Yönlendirme. Bir REST hizmetinden "/foo" isteği alındığında, isteğin hangi hizmet kümesine gönderilmesi gerekir?
- Yük dengeleme. Yönlendirme sırasında bir hizmet kümesi seçildikten sonra istek hangi hizmet örneğine gönderilmelidir? Hangi zaman aşımı ile? Hangi devre kesme ayarlarıyla? İstek başarısız olursa yeniden denenmeli mi?
- Kimlik doğrulama ve yetkilendirme. Gelen istekler için, arayan hizmet mTLS veya başka bir mekanizma kullanılarak kriptografik olarak tanımlanabilir/yetkilendirilebilir mi? Tanınmışsa/yetkilendirilmişse, hizmette istenen işlemin (uç nokta) çağrılmasına izin veriliyor mu, yoksa kimliği doğrulanmamış bir yanıt mı döndürülmeli?
- Gözlenebilirlik. Operatörlerin dağıtılmış trafik akışını ve ortaya çıkan hata ayıklama sorunlarını anlayabilmesi için her istek için ayrıntılı istatistikler, günlükler/günlükler ve dağıtılmış izleme verileri oluşturulmalıdır.
Veri düzlemi, servis ağında önceki tüm noktalardan sorumludur. Aslında hizmetin yerel proxy'si (yardımcı dosya) veri düzlemidir. Başka bir deyişle veri düzlemi, bir hizmete gönderilen veya bir hizmetten gönderilen her ağ paketinin koşullu olarak yayınlanmasından, iletilmesinden ve izlenmesinden sorumludur.
Kontrol düzlemi
Yerel bir proxy'nin veri düzleminde sağladığı ağ soyutlaması sihirlidir(?). Ancak proxy, B hizmetine giden "/foo" yolunu gerçekte nasıl biliyor? Proxy istekleri tarafından doldurulan hizmet bulma verileri nasıl kullanılabilir? Yük dengeleme, zaman aşımı, devre kesme vb. için parametreler nasıl yapılandırılır? Bir uygulamayı mavi/yeşil yöntemini veya zarif trafik geçiş yöntemini kullanarak nasıl dağıtırsınız? Sistem genelinde kimlik doğrulama ve yetkilendirme ayarlarını kim yapılandırır?
Yukarıdaki öğelerin tümü servis ağının kontrol düzleminin kontrolü altındadır. Kontrol düzlemi bir dizi yalıtılmış durum bilgisi olmayan proxy'yi alır ve bunları dağıtılmış bir sisteme dönüştürür.
Bence birçok teknoloji uzmanının ayrı veri düzlemi ve kontrol düzlemi kavramlarını kafa karıştırıcı bulmasının nedeni, çoğu insan için veri düzleminin tanıdık, kontrol düzleminin ise yabancı/anlaşılır olmasıdır. Uzun süredir fiziksel ağ yönlendiricileri ve anahtarları ile çalışıyoruz. Paketlerin/isteklerin A noktasından B noktasına gitmesi gerektiğini ve bunu yapmak için donanım ve yazılım kullanabileceğimizi anlıyoruz. Yeni nesil yazılım proxy'leri, uzun süredir kullandığımız araçların süslü versiyonlarıdır.
Şekil 2: İnsan kontrol düzlemi
Ancak çoğu ağ operatörü sistemin bu bölümünü herhangi bir teknoloji bileşeniyle ilişkilendirmese de, kontrol düzlemlerini uzun süredir kullanıyoruz. Nedeni basit:
Günümüzde kullanılan çoğu kontrol düzlemi....
Üzerinde Figür 2 "İnsan kontrol düzlemi" dediğim şeyi gösteriyor. Hala çok yaygın olan bu dağıtım türünde, muhtemelen huysuz bir insan operatör, potansiyel olarak komut dosyaları aracılığıyla statik yapılandırmalar oluşturur ve bunları bazı özel işlemler yoluyla tüm proxy'lere dağıtır. Proxy'ler daha sonra bu konfigürasyonu kullanmaya başlar ve güncellenmiş ayarları kullanarak veri düzlemini işlemeye başlar.
Şekil 3: Gelişmiş servis ağı kontrol düzlemi
Üzerinde Figür 3 servis ağının “genişletilmiş” kontrol düzlemini gösterir. Aşağıdaki parçalardan oluşur:
- İnsan: Hala bir bütün olarak sistemin tamamıyla ilgili üst düzey kararlar alan (umarım daha az öfkeli) bir kişi var.
- Kontrol düzlemi kullanıcı arayüzü: Bir kişi, sistemi kontrol etmek için bir tür kullanıcı arayüzüyle etkileşime girer. Bu bir web portalı, bir komut satırı uygulaması (CLI) veya başka bir arayüz olabilir. Operatör, kullanıcı arayüzünü kullanarak aşağıdakiler gibi genel sistem yapılandırma parametrelerine erişebilir:
- Dağıtım kontrolü, mavi/yeşil ve/veya kademeli trafik geçişi
- Kimlik Doğrulama ve Yetkilendirme Seçenekleri
- Yönlendirme tablosu spesifikasyonları; örneğin A uygulaması "/foo" hakkında bilgi istediğinde ne olur?
- Zaman aşımları, yeniden denemeler, devre kesme ayarları vb. gibi yük dengeleyici ayarları.
- İş yükü planlayıcısı: Hizmetler, Kubernetes veya Nomad gibi bir tür planlama/düzenleme sistemi aracılığıyla altyapı üzerinde çalıştırılır. Zamanlayıcı, hizmetin yerel proxy'siyle birlikte yüklenmesinden sorumludur.
- Hizmet keşfi. Zamanlayıcı hizmet örneklerini başlatıp durdurduğunda, sistem durumu durumunu hizmet keşif sistemine bildirir.
- Sepet proxy yapılandırma API'leri : Yerel proxy'ler, operatör müdahalesi olmadan sonuçta tutarlı bir model kullanarak çeşitli sistem bileşenlerinden durumu dinamik olarak çıkarır. Şu anda çalışan tüm hizmet örneklerinden ve yerel proxy sunucularından oluşan sistemin tamamı, sonuçta tek bir ekosistemde birleşir. Envoy'un evrensel veri düzlemi API'si bunun pratikte nasıl çalıştığının bir örneğidir.
Temel olarak kontrol düzleminin amacı, sonuçta veri düzlemi tarafından kabul edilecek politikayı belirlemektir. Daha gelişmiş kontrol düzlemleri, doğru çalışmaları koşuluyla, bazı sistemlerin daha fazla parçasını operatörün elinden alacak ve daha az manuel işlem gerektirecektir!...
Veri düzlemi ve kontrol düzlemi. Veri düzlemi ve kontrol düzlemi özeti
- Hizmet ağı veri düzlemi: Sistemdeki her paketi/isteği etkiler. Uygulama/hizmet keşfi, durum kontrolü, yönlendirme, yük dengeleme, kimlik doğrulama/yetkilendirme ve gözlemlenebilirlikten sorumludur.
- Servis ağı kontrol düzlemi: Servis ağı içinde çalışan tüm veri düzlemleri için politika ve yapılandırma sağlar. Sistemdeki hiçbir pakete/isteğe dokunmaz. Kontrol düzlemi tüm veri düzlemlerini dağıtılmış bir sisteme dönüştürür.
Mevcut proje manzarası
Yukarıdaki açıklamayı anladıktan sonra service mesh projesinin mevcut durumuna bakalım.
- Veri düzlemleri: Linkerd, NGINX, HAProxy, Envoy, Traefik
- Kontrol düzlemleri: Istio, Nelson, SmartStack
Yukarıdaki çözümlerin her birinin derinlemesine analizine girmek yerine, şu anda ekosistemde en çok kafa karışıklığına neden olduğuna inandığım bazı noktalara kısaca değineceğim.
Linkerd, 2016'nın başlarında hizmet ağı için ilk veri düzlemi proxy sunucularından biriydi ve hizmet ağı tasarım modeline yönelik farkındalığı ve dikkati artırma konusunda harika bir iş çıkardı. Bundan yaklaşık 6 ay sonra Envoy Linkerd'e katıldı (gerçi 2015'in sonlarından beri Lyft'teydi). Linkerd ve Envoy, hizmet ağlarını tartışırken en sık bahsedilen iki projedir.
Istio Mayıs 2017'de duyuruldu. Istio projesinin hedefleri, şekilde gösterilen genişletilmiş kontrol düzlemine çok benzer. Figür 3. Istio Elçisi varsayılan vekildir. Dolayısıyla Istio kontrol düzlemidir ve Envoy veri düzlemidir. Kısa sürede Istio büyük bir heyecan yarattı ve Envoy'un yerine diğer veri düzlemleri entegre olmaya başladı (hem Linkerd hem de NGINX, Istio ile entegrasyon gösterdi). Aynı kontrol düzlemi içinde farklı veri düzlemlerinin kullanılabilmesi, kontrol düzlemi ile veri düzleminin mutlaka sıkı bir şekilde bağlı olmadığı anlamına gelir. Envoy'un genel veri düzlemi API'si gibi bir API, sistemin iki parçası arasında bir köprü oluşturabilir.
Nelson ve SmartStack, kontrol düzlemi ile veri düzleminin ayrımını daha iyi göstermeye yardımcı olur. Nelson, Envoy'u vekil olarak kullanıyor ve HashiCorp yığınını temel alan hizmet ağı için güvenilir bir kontrol düzlemi oluşturuyor; Göçebe vb. SmartStack belki de yeni hizmet ağları dalgasının ilkiydi. SmartStack, HAProxy veya NGINX çevresinde bir kontrol düzlemi oluşturarak kontrol düzlemini servis ağından veri düzleminden ayırma yeteneğini gösterir.
Hizmet ağına sahip mikro hizmet mimarisi giderek daha fazla ilgi görüyor (haklı olarak!) ve giderek daha fazla proje ve satıcı bu yönde çalışmaya başlıyor. Önümüzdeki birkaç yıl içinde hem veri düzleminde hem de kontrol düzleminde birçok yeniliğin yanı sıra farklı bileşenlerin daha fazla karıştırıldığını göreceğiz. Sonuçta mikro hizmet mimarisi operatör için daha şeffaf ve büyülü (?) hale gelmelidir.
Umarım giderek daha az sinirleniriz.
Temel çıkarımlar
- Servis ağı iki farklı bölümden oluşur: veri düzlemi ve kontrol düzlemi. Her iki bileşen de gereklidir ve onlar olmadan sistem çalışmaz.
- Herkes kontrol düzlemine aşinadır ve bu noktada kontrol düzlemi siz olabilirsiniz!
- Tüm veri düzlemleri özellikler, performans, yapılandırılabilirlik ve genişletilebilirlik açısından birbirleriyle rekabet eder.
- Tüm kontrol düzlemleri özellikler, yapılandırılabilirlik, genişletilebilirlik ve kullanım kolaylığı açısından birbirleriyle rekabet eder.
- Bir kontrol düzlemi, birden fazla veri düzleminin kullanılabilmesi için doğru soyutlamaları ve API'leri içerebilir.
Kaynak: habr.com