Bir Kubernetes Hizmet Ağı Karşılaştırması

Mikro hizmet mimarisi ve konteynerleştirme tartışılırken, son yıllarda en çok dikkati üretimde kanıtlanmış araçlardan oluşan bir set çekti: hizmet ağı.

Gerçekten de, mikro hizmet mimarisi ve Kubernetes (genellikle "K8'ler" olarak adlandırılır) hızla ölçeklenebilir uygulamalar için norm haline geldi ve hizmetler arasındaki iletişimi yönetme sorununu sıcak bir konu haline getirdi - ve hizmet ağları çekici bir çözüm. Ben kendim üretimde servis ağlarını, özellikle Linkerd, Istio ve daha önceki bir Ambassador biçimini kullandım. Ancak hizmet ağları tam olarak ne yapar? Hangisini kullanmak en iyisidir? Birini kullanmanız gerekip gerekmediğini nasıl anlarsınız?

Bu soruları yanıtlamak, hizmet ağlarının neden geliştirildiğini anlamaya yardımcı olur. Tarihsel olarak, geleneksel BT altyapısı, monolit olarak çalışan uygulamalara sahipti. Bir hizmet, bir sunucuda çalıştı; Daha fazla kapasiteye ihtiyaç duyması halinde çözüm, daha büyük bir makine sağlayarak dikey olarak ölçeklendirmekti.

Bu yaklaşımın sınırlarına ulaşan büyük teknoloji şirketleri, yük dengeleyiciyi uygulama sunucularından ve veritabanı katmanından ayıran üç katmanlı bir mimariyi hızla benimsedi. Bu mimari biraz ölçeklenebilir kalırken, uygulama katmanını mikro hizmetlere ayırmaya karar verdiler. Uygulamaların ölçeklenebilmesi için bu hizmetler arasındaki iletişimin izlenmesi ve güvenliği kritik hale geldi.

Servisler arası iletişime izin vermek için bu şirketler şirket içi kütüphaneler geliştirdi: Twitter'da Finagle, Netflix'te Hystrix ve Google'da Stubby (2016'da gRPC oldu). Bu kitaplıklar, mikro hizmet mimarisinin ortaya çıkardığı sorunları düzeltmeyi amaçladı: hizmetler arasında güvenlik, gecikme, izleme ve yük dengeleme. Ancak büyük bir kitaplığı bir bağımlılık olarak birden çok dilde yönetmek karmaşık ve zaman alıcıdır.

Sonunda, bu tür kitaplık, kullanımı daha kolay, hafif bir proxy ile değiştirildi. Bu tür proxy'ler, uygulama katmanından harici olarak bağımsızdı (potansiyel olarak uygulama için şeffaftı) ve güncellenmesi, bakımı ve dağıtımı daha kolaydı. Böylece hizmet ağı doğdu.

Hizmet Ağı Nedir?

Hizmet ağı, hizmetler arasındaki iletişimi kontrol etmeye yönelik bir yazılım altyapı katmanıdır; genellikle iki bileşenden oluşur:

1. Uygulamanın yakınındaki iletişimleri yöneten veri düzlemi . Tipik olarak bu, daha önce gösterildiği gibi, uygulamayla birlikte bir dizi ağ proxy'si olarak dağıtılır.
2. Servis ağının "beyni" olan kontrol düzlemi . Kontrol düzlemi, yapılandırmaları zorlamak, hizmet keşfini sağlamak ve gözlemlenebilirliği merkezileştirmek için proxy'lerle etkileşime girer.

Servis ağlarının servisler arası iletişim etrafında üç ana hedefi vardır:

1. bağlantı
2. Güvenlik
3. Gözlenebilirlik

bağlantı

Hizmet ağı mimarisinin bu yönü, hizmet keşfine ve dinamik yönlendirmeye izin verir. Ayrıca yeniden denemeler, zaman aşımları, devre kesme ve hız sınırlama gibi iletişim esnekliğini de kapsar.

Servis ağlarının temel özelliklerinden biri yük dengelemedir . Tüm hizmetlerin proxy'ler tarafından birbirine bağlanması, sürekli deneme, rastgele ve en az istek gibi hizmetler arasında yük dengeleme ilkelerinin uygulanmasına olanak tanır. Bu politikalar, tıpkı her hizmetin önünde küçük yük dengeleyicileriniz varmış gibi, orijinal isteği hangi kopyanın alacağına karar vermek için hizmet ağı tarafından kullanılan stratejidir.

Son olarak, servis ağları, trafik kaydırma ve yansıtma şeklinde yönlendirme kontrolü sunar.

Güvenlik

Geleneksel mikro hizmet mimarisinde, hizmetler kendi aralarında şifrelenmemiş trafikle iletişim kurar. Şifrelenmemiş dahili trafik, günümüzde, özellikle genel bulut altyapısı ve sıfır güven ağları için güvenlik açısından kötü bir uygulama olarak kabul edilmektedir.

Donanım üzerinde doğrudan kontrolün olmadığı durumlarda müşteri verilerinin gizliliğini korumanın yanı sıra, dahili trafiği şifrelemek , bir sistem ihlali durumunda hoş bir ekstra karmaşıklık katmanı ekler. Bu nedenle, tüm hizmet ağları, hizmetler arası iletişim, yani tüm proxyler arası iletişim için karşılıklı TLS (mTLS) şifrelemesi kullanır.

Hizmet ağları, belirli ortamları ve hizmetleri hedefleyen ilkelere dayalı olarak trafiğe izin vererek veya reddederek karmaşık yetkilendirme ilkesi matrislerini bile uygulayabilir.

Gözlenebilirlik

Servis ağlarının amacı, servisler arası iletişime görünürlük kazandırmaktır. Bir hizmet ağı, ağı kontrol ederek, gözlemlenebilirliği zorlar ve trafik bazı özelleştirilebilir eşiğe ulaştığında otomatik uyarılara izin veren yedinci katman metrikleri sağlar.

Genellikle Jaeger veya Zipkin gibi üçüncü taraf araçlar veya eklentiler tarafından desteklenen bu tür kontrol, HTTP izleme başlıklarını enjekte ederek izlemeyi de sağlar.

Hizmet Ağı Avantajları

Hizmet ağı, bir mikro hizmet mimarisinin yarattığı operasyonel yükün bir kısmını dengelemek için oluşturuldu. Mikro hizmet mimarilerinde deneyime sahip olanlar, günlük olarak çalışmak için önemli miktarda iş aldıklarını bilirler. Mikro hizmetlerin potansiyelinden tam olarak yararlanmak, normalde diğerlerinin yanı sıra merkezi günlük kaydı, yapılandırma yönetimi ve ölçeklenebilirlik mekanizmalarını işlemek için harici araçlar gerektirir. Bir hizmet ağının kullanılması , bu yetenekleri, bunların kurulumunu ve entegrasyonunu standartlaştırır .

Hizmet ağı gözlemlenebilirliği, özellikle, son derece çok yönlü hata ayıklama ve optimizasyon yöntemleri sağlar. Hizmetler arasındaki alışverişlerde ayrıntılı ve eksiksiz görünürlük sayesinde, mühendisler - özellikle SRE'ler - olası hataları ve sistem yanlış yapılandırmalarını daha hızlı giderebilir . Hizmet ağı izleme ile, sisteme girişinden (bir yük dengeleyicide veya harici proxy'de) bir isteği yığın içindeki özel hizmetlere kadar takip edebilirler. Bir isteği eşlemek ve her hizmette karşılaştığı gecikmeyi kaydetmek için günlüğe kaydetmeyi kullanabilirler. Sonuç: sistem performansına ilişkin ayrıntılı bilgiler .

Trafik yönetimi, bir hizmetin yeni sürümlerinin tam sürümüne geçmeden önce güçlü olanaklar sağlar:

1. İsteklerin küçük yüzdelerini yeniden yönlendirin .
2. Daha da iyisi, davranışını gerçek zamanlı trafikle test etmek için üretim isteklerini yeni bir sürüme yansıtın.
3. A/B herhangi bir hizmeti veya hizmet kombinasyonunu test edin.

Servis ağları, yukarıdaki senaryoların tümünü düzene sokarak, üretimdeki sürprizlerden kaçınmayı ve/veya azaltmayı kolaylaştırır.

Kubernetes Hizmet Ağı Karşılaştırması

Birçok yönden hizmet ağları, mikro hizmet mimarisi için nihai araçlar kümesidir; çoğu, en iyi kapsayıcı düzenleme araçlarından biri olan Kubernetes'te çalışır. Bugün Kubernetes'te çalışan ana hizmet ağlarından üçünü seçtik: Linkerd (v2), Istio ve Consul Connect. Ayrıca diğer bazı hizmet ağlarından da bahsedeceğiz: Kuma, Traefik Mesh ve AWS App Mesh. Şu anda kullanım ve topluluk açısından daha az öne çıksalar da, burada gözden geçirmek ve genel olarak sekmeleri tutmak için yeterince umut vericidirler.

Sepet Proxy'leri Hakkında Kısa Bir Not

Tüm Kubernetes hizmet ağları aynı mimari yaklaşımı benimsemez, ancak yaygın olanı sepet modelinden yararlanmaktır. Bu, uygulamanın gelen ve giden ağ trafiğini durdurmak ve düzenlemek için ana uygulamaya bir proxy (sepet) eklemeyi içerir. Pratikte bu, Kubernetes'te, uygulama kapsayıcısının yaşam döngüsünü takip edecek olan her uygulama bölmesinde ikincil bir kapsayıcı aracılığıyla yapılır.

Servis ağlarına sepet yaklaşımının iki ana avantajı vardır:

• Sidecar proxy'leri, çalışma zamanından ve hatta uygulamanın programlama dilinden bağımsızdır.
  • Bu, bir hizmet ağının tüm özelliklerini yığın boyunca kullanılacak her yerde etkinleştirmenin kolay olduğu anlamına gelir.
• Bir sepet, uygulama ile aynı düzeyde izinlere ve kaynaklara erişime sahiptir.
  • Sepet, izlemeyi ana uygulama kod tabanına entegre etmeye gerek kalmadan ana uygulama tarafından kullanılan kaynakların izlenmesine yardımcı olabilir.

Ancak sepetler, bir uygulamayı doğrudan etkilemeleri nedeniyle karışık bir nimettir:

• Sepet başlatma, bir uygulamanın başlatma mekanizmasını kilitleyebilir.
• Sidecar proxy'leri, uygulamanızın üzerine olası gecikme süresi ekler.
• Sidecar proxy'leri ayrıca, büyük ölçekte önemli miktarda paraya mal olabilecek bir kaynak ayak izi ekler.

Bu avantajlar ve dezavantajlar göz önüne alındığında, sepet yaklaşımı, hizmet ağı topluluğunda sıklıkla bir tartışma konusudur. Bununla birlikte, burada karşılaştırılan altı hizmet ağından dördü Envoy sepet proxy'sini kullanır ve Linkerd kendi sepet uygulamasını kullanır; Traefik Mesh tasarımında sepet kullanmaz.

Bağlantı İncelemesi

2017 yılında piyasaya sürülen Linkerd, piyasadaki en eski servis ağıdır. Buoyant (iki eski Twitter mühendisi tarafından kurulan bir şirket) tarafından oluşturulan Linkerd v1, Finagle ve Netty'ye dayanıyordu.

Linkerd v1, eksiksiz, üretime hazır bir hizmet ağı olduğu için zamanının ötesinde olarak tanımlandı. Aynı zamanda kaynak kullanımı açısından da biraz ağırdı. Ayrıca, belgelerdeki önemli boşluklar, kurulum ve üretimde çalıştırmayı zorlaştırdı.

Böylece Buoyant, eksiksiz bir üretim modeliyle çalışma, deneyim kazanma ve bu bilgeliği uygulama fırsatı buldu. Sonuç, Linkerd'in 2018'de piyasaya sürülen şirketi yeniden yazdığı ve o yılın ilerleyen saatlerinde Linkerd v2 olarak yeniden adlandırılan Conduit oldu. Linkerd v2, beraberinde birkaç zorlayıcı iyileştirme getirdi; Buoyant'ın Linkerd v1'i aktif olarak geliştirmesi uzun zaman önce sona erdiği için, bu makalenin geri kalanında “Linkerd”den bahsetmemiz v2'ye atıfta bulunuyor.

Tamamen açık kaynak olan Linkerd, veri düzlemi için Rust'ta yazılmış ev yapımı bir proxy'ye ve kontrol düzlemi için Go'da yazılmış kaynak koduna güvenir.

bağlantı

Linkerd proxy'ler yeniden deneme ve zaman aşımı özelliklerine sahiptir ancak bu yazı itibariyle devre kesme veya gecikme enjeksiyonu yoktur. Giriş desteği kapsamlıdır; Linkerd, aşağıdaki giriş denetleyicileriyle entegrasyona sahiptir:

• Traefik
• Nginx
• GCE
• Büyükelçi
• gloo
• kontur
• Kongo

Linkerd'deki hizmet profilleri, kullanıcı metrikleri, yeniden deneme ayarlaması ve zaman aşımı ayarlarını her bir rota bazında vererek gelişmiş yönlendirme yetenekleri sunar. Yük dengelemeye gelince, Linkerd otomatik proxy enjeksiyonu, kendi gösterge panosu ve Grafana için yerel destek sunar.

Güvenlik

Linkerd'deki mTLS desteği, otomatik günlük anahtar dönüşü gibi ilk kurulumunun otomatik olması açısından uygundur.

Gözlenebilirlik

Kutunun dışında, Linkerd istatistikleri ve rotaları bir CLI aracılığıyla gözlemlenebilir. GUI tarafında, seçenekler arasında önceden hazırlanmış Grafana panoları ve yerel bir Linkerd panosu bulunur.

Linkerd, bir Prometheus örneğine bağlanabilir.

İzleme, toplayıcı olarak OpenTelemetry (eski adıyla OpenCensus) ve Jaeger izlemeyi kendisi yapan bir eklenti aracılığıyla etkinleştirilebilir.

Kurulum

Linkerd kurulumu, Kubernetes'teki kaynaklarınıza bir açıklama ekleyerek yapılan bir sepet proxy'si enjekte edilerek yapılır. Bu konuda gitmenin iki yolu vardır:

1. Bir Helm tablosu kullanma. (Birçoğu için Helm, Kubernetes kaynakları için gidilecek yapılandırma ve şablon yöneticisidir.)
2. Linkerd CLI'yi kurun, ardından bunu Linkerd'i bir kümeye kurmak için kullanın.

İkinci yöntem, bir yükleme komut dosyasının indirilmesi ve çalıştırılmasıyla başlar:

 curl -sL https://run.linkerd.io/install | sh

Buradan, Linkerd CLI aracı linkerd , Linkerd'in geri kalanını yüklemeye ve uygulama kümesi ve kontrol düzlemi ile etkileşime girmeye yardımcı olan kullanışlı bir araç takımı sağlar.

linkerd check --pre , Linkerd kurulumunuz için gerekli tüm ön kontrolleri çalıştıracak ve potansiyel bir Linkerd kurulumunun neden henüz çalışmayabileceğine dair net ve kesin günlükler sağlayacaktır. --pre olmadan, bu komut kurulum sonrası hata ayıklama için kullanılabilir.

Bir sonraki adım, aşağıdakileri çalıştırarak Linkerd'i kümeye kurmaktır:

 linkerd install | kubectl apply -f -

Linkerd daha sonra çok küçük bir kaynak ayak izi ile birçok farklı bileşeni kuracaktır; bu nedenle, kendilerinin bir mikro hizmet yaklaşımı vardır:

• CLI ve kontrol panelinin etkileşime girdiği genel API'yi sağlayan linkerd-controller
• mTLS'yi uygulamak için sertifika yetkilisini sağlayan linkerd-identity
• bir bölmenin konfigürasyonunu değiştirerek proxy enjeksiyonunu yöneten linkerd-proxy-injector
• dahili Linkerd bileşenlerinin yanı sıra dağıtımların ve bölmelerin izlenmesine izin veren bir gösterge panosu sunan linkerd-web

Linkerd, yapılandırmasının çoğunu CustomResourceDefinitions (CRD'ler) dayandırır. Bu, Kubernetes eklenti yazılımı geliştirirken en iyi uygulama olarak kabul edilir; bu, bir Kubernetes kümesine kalıcı bir şekilde eklenti yüklemek gibidir.

Bazı yaygın efsaneler nedeniyle Linkerd kullanıcılarının gerçekte peşinde olduğu şey olan veya olmayan dağıtılmış izleme eklemek, linkerd-collector ve linkerd-jaeger ile başka bir adım gerektirir. Bunun için önce bir yapılandırma dosyası oluştururuz:

 cat >> config.yaml << EOF tracing: enabled: true EOF

İzlemeyi etkinleştirmek için şunu çalıştırırız:

 linkerd upgrade --config config.yaml | kubectl apply -f -

Sepet proxy'lerine dayalı tüm hizmet ağlarında olduğu gibi, izlemeyi etkinleştirmek için uygulama kodunuzu değiştirmeniz gerekecektir. Bunun büyük kısmı, izleme başlıklarını yaymak için bir istemci kitaplığı eklemekten ibarettir; daha sonra her hizmete dahil edilmesi gerekir.

Linkerd'in Service Mesh Interface (SMI) uyumlu API'si aracılığıyla ortaya çıkan trafik bölme özelliği, zaten kanarya sürümlerine izin veriyor. Ancak bunları ve trafik yönetimini otomatikleştirmek için Flagger gibi harici araçlara da ihtiyacınız olacak.

İşaretleyici , Linkerd'in "altın" metrikler olarak adlandırdığı şeyi değerlendirecek olan aşamalı bir dağıtım aracıdır: "istek hacmi, başarı oranı ve gecikme dağılımları." (Başlangıçta, Google SRE'ler altın sinyaller terimini kullandı ve dördüncü bir tane olan doygunluğu içeriyordu, ancak Linkerd bunu kapsamaz çünkü bu, CPU ve bellek kullanımı gibi doğrudan erişilebilir olmayan metrikler gerektirebilir.) İşaretleyici, trafiği bölerken bunları izler. bir geri besleme döngüsü kullanarak; bu nedenle, otomatikleştirilmiş ve ölçüme duyarlı kanarya sürümlerini uygulayabilirsiniz.

Kurulum sürecini inceledikten sonra, bir Linkerd hizmet ağının çalışır durumda olması ve yaygın olarak istenen yeteneklerden yararlanması için en az bir düzine hizmetin çalışmasının kolay olduğu ortaya çıkıyor. Bununla birlikte, bunların çoğu kurulum sırasında Linkerd tarafından diğer servis ağlarından daha fazla sağlanır.

Linkerd Hizmet Ağı Özeti

Avantajlar:

Linkerd, dahili araç Finagle üzerinde çalışmış ve daha sonra Linkerd v1'den öğrenmiş iki eski Twitter mühendisi olan yaratıcılarının deneyimlerinden yararlanır. İlk hizmet ağlarından biri olan Linkerd, gelişen bir topluluğa (Slack'in 5.000'den fazla kullanıcısı, ayrıca aktif bir posta listesi ve Discord sunucusuna sahiptir) ve kapsamlı bir belge ve eğitim setine sahiptir. Nordstrom, eBay, Strava, Expedia ve Subspace gibi büyük şirketler tarafından benimsenmesinin kanıtladığı gibi, Linkerd 2.9 sürümünün yayınlanmasıyla olgunlaştı. Linkerd için Buoyant'ın ücretli, kurumsal düzeyde desteği mevcuttur.

Dezavantajları:

Linkerd hizmet ağlarını tam potansiyelleriyle kullanmak için oldukça güçlü bir öğrenme eğrisi var. Linkerd yalnızca Kubernetes kapsayıcılarında desteklenir (yani, VM tabanlı, "evrensel" mod yoktur). Linkerd sepet proxy'si Elçi değil. Bu, Buoyant'ın uygun gördükleri şekilde ayarlamasına izin verirken, Envoy'un sunduğu doğal genişletilebilirliği ortadan kaldırır. Bu aynı zamanda Linkerd'in devre kesme, gecikmeli enjeksiyon ve hız sınırlama desteğinden yoksun olduğu anlamına gelir. Linkerd kontrol düzlemini kolayca kontrol etmek için belirli bir API sunulmaz. (Yine de gRPC API bağlamasını bulabilirsiniz.)

Linkerd, v1'den bu yana kullanılabilirliği ve kurulum kolaylığı açısından büyük ilerleme kaydetti. Resmi olarak açıklanmış bir API'nin olmaması dikkate değer bir eksikliktir. Ancak, iyi düşünülmüş belgeler sayesinde Linkerd'deki kullanıma hazır işlevselliği test etmek kolaydır.

Konsolos Bağlantı İncelemesi

Bir sonraki hizmet ağı yarışmacımız Consul Connect, benzersiz bir melezdir. HashiCorp'tan Consul, dağıtılmış mimariler için uzun yıllardır var olan anahtar-değer depolamasıyla daha iyi bilinir. Consul'ün eksiksiz bir servis araçları paketine dönüşmesinin ardından, HashiCorp bunun üzerine bir servis ağı oluşturmaya karar verdi: Consul Connect.

Hibrit doğası hakkında kesin olmak gerekirse:

Consul Connect veri düzlemi, C++ ile yazılmış Envoy'u temel alır. Consul Connect'in kontrol düzlemi Go'da yazılmıştır. Bu, bir anahtar/değer deposu olan Consul KV tarafından desteklenen kısımdır.

Diğer hizmet ağlarının çoğu gibi, Consul Connect de uygulama bölmenize bir sepet proxy'si enjekte ederek çalışır. Mimari açısından, Consul Connect aracılar ve sunucular üzerine kuruludur. Kutunun dışında, Consul Connect'in pod anti-afinitesini belirten bir StatefulSet olarak üç veya beş sunucu kullanarak yüksek kullanılabilirliğe (HA) sahip olması amaçlanmıştır. Pod anti-affinity, dağıtılmış bir yazılım sisteminin pod'larının aynı düğümde (sunucu) sonlanmamasını sağlama, böylece herhangi bir tek düğümün arızalanması durumunda kullanılabilirliği garanti etme uygulamasıdır.

bağlantı

Consul Connect'i bu alanda öne çıkaran pek bir şey yok; herhangi bir hizmet ağının ne yaptığını (ki bu oldukça fazladır) artı yol tabanlı yönlendirme, trafik kaydırma ve yük dengeleme için katman yedi özellikleri sağlar.

Güvenlik

Diğer hizmet ağlarında olduğu gibi, Consul Connect temel mTLS yetenekleri sağlar. Ayrıca, bir kümedeki sertifikaları yönetmek ve imzalamak için bir CA sağlayıcısı olarak kullanılabilen Consul ve Vault (ayrıca HashiCorp tarafından) arasında yerel entegrasyona da sahiptir.

Gözlenebilirlik

Consul Connect, yedinci katman yetenekleri sağlamak için Envoy'u bir yardımcı proxy olarak dahil ederek en yaygın gözlemlenebilirlik yaklaşımını benimser. Consul Connect kullanıcı arabirimini metrikleri getirecek şekilde yapılandırmak, yerleşik bir yapılandırma dosyasını değiştirmeyi ve ayrıca Prometheus gibi bir metrik sağlayıcıyı etkinleştirmeyi içerir. İlgili hizmete özel ölçümleri göstermek için bazı Grafana panolarını yapılandırmak da mümkündür.

Kurulum

Consul Connect, bir Helm şeması kullanılarak bir Kubernetes kümesine kurulur:

 helm repo add hashicorp https://helm.releases.hashicorp.com

Kullanıcı arabirimini etkinleştirmek veya Consul Connect modülünün yan aracı proxy'sini enjekte etmesini sağlamak istiyorsanız, varsayılan değerleri değiştirmeniz values.yaml :

 helm install -f consul-values.yml hashicorp hashicorp/consul

Üyelere danışmak ve çeşitli düğümleri kontrol etmek için Consul, kapsayıcılardan birine çalıştırmayı ve ardından CLI aracı exec kullanmanızı consul .

Consul'un sağladığı kullanıma hazır web kullanıcı arabirimini sunmak için kubectl port-forward service/hashicorp-consul-ui 18500:80 çalıştırın.

Consul Connect Hizmet Ağı Özeti

Avantajlar:

• Konsolos, HashiCorp tarafından desteklenmektedir; bir freemium ürünü olarak, kurumsal düzeyde destek sunan ek özelliklere sahip kurumsal bir sürüm de vardır. Geliştirme ekibi deneyimi açısından Consul, piyasadaki en eski araçlardan biridir.
• Consul, sağlam bir kurumsal topluluğa sahiptir ve 50.000 düğümlü altyapı üzerinde çalıştığı bilinmektedir. Ayrıca, 2014'ten beri piyasada ve onu piyasaya göre olgun bir ürün yapıyor.
• Consul Connect, yerel destek sayesinde bir VM içinde iyi çalışır.
• Consul Connect ile, üst düzey teknoloji şirketlerinde hizmet öncesi ağ uygulamaları kadar derin uygulama entegrasyonları elde etmek mümkündür. Bu, tamamen belgelenmiş, kitaplık düzeyinde bir API'nin kullanıma sunulması sayesindedir.

Dezavantajları:

• Consul Connect, diğer hizmet ağlarından daha dik bir öğrenme eğrisine sahiptir ve görsel panoları ve ölçümleri çalıştırmak için daha fazla ayarlamaya ihtiyaç duyacaktır.
• HashiCorp'un belgeleri basit değildir ve kullanıcıları doğru şekilde yapılandırmak için kazmaya ve denemeye bırakır.
• Trafik yönetimi belgelerini bulmak zordur ve çoğunlukla, özellikle Consul Connect trafik yönetimi hakkında ayrıntılı bilgi vermeyen Envoy belgelerine giden bağlantılardan oluşur.
• Consul Connect'in SMI arayüzü hala deneyseldir.

Consul Connect, kurumsal düzeyde bir ürün arayanlar için çok iyi bir seçim olabilir. HashiCorp, ürünlerinin kalitesiyle tanınır ve Consul Connect bir istisna değildir. Burada diğer hizmet ağlarına kıyasla iki güçlü avantaj görebiliyorum: kurumsal sürümle şirketten güçlü destek ve her türlü mimariye (yalnızca Kubernetes değil) hazır bir araç.

Istio İnceleme

Mayıs 2017'de Google, IBM ve Lyft Istio'yu duyurdu. Istio, servis ağı araçları yarışına girdiğinde, teknoloji alanında çok iyi bir görünürlük kazandı. Yazarları, 1.9 sürümüne kadar kullanıcı geri bildirimlerine dayalı özellikler eklediler.

Istio, o sırada rakiplerine göre önemli yeni özellikler vaat etti: otomatik yük dengeleme, hata enjeksiyonu ve daha fazlası. Bu, topluluğun büyük ilgisini çekti, ancak aşağıda ayrıntılandıracağımız gibi, Istio'yu kullanmak önemsiz olmaktan uzaktır: Istio'nun üretime alınması özellikle karmaşık olarak kabul edilmiştir.

Tarihsel olarak, Istio projesi kaynak kodu değişiklikleri açısından sık sık gündeme geldi. Kontrol düzlemi için bir mikro hizmet mimarisini benimsedikten sonra, Istio şimdi (versiyon 1.5'ten beri) monolitik bir mimariye geri döndü. Istio'nun merkezileştirmeye geri dönme gerekçesi, mikro hizmetlerin operatörler için izlenmesinin zor olması, kod tabanının çok fazla olması ve projenin kurumsal olgunluğa erişmiş olmasıydı - artık silolarda çalışan çok sayıda küçük ekibin olması gerekmiyordu.

Bununla birlikte, Istio, yol boyunca en yüksek açık GitHub sorunlarından birine sahip olduğu için ün kazandı. Bu yazı itibariyle, sayı yaklaşık 800 sayı açık ve yaklaşık 12.000 kapalı. Sorun sayıları aldatıcı olsa da, bu durumda daha önce bozulan özellikler ve kontrol dışı kaynak kullanımı açısından anlamlı bir gelişmeyi temsil ederler.

bağlantı

Istio, Consul Connect ve Linkerd'e kıyasla trafik yönetiminde oldukça güçlü. Bu, kapsamlı bir alt özellik teklifi sayesindedir: istek yönlendirme, hata yerleştirme, trafik kaydırma, istek zaman aşımları, devre kesme ve hizmet ağına giriş ve çıkış trafiğini kontrol etme. Sanal hizmetler ve hedef kuralları kavramı, onu trafik yönetimi açısından çok eksiksiz hale getirir.

Ancak, tüm bu olasılıklar bir öğrenme eğrisi ve Kubernetes kümenizdeki bu yeni kaynakların yönetimi ile birlikte gelir.

Güvenlik

Istio, iki ana eksene sahip kapsamlı bir güvenlikle ilgili araçlar setine sahiptir: kimlik doğrulama ve yetkilendirme. Istio, farklı kapsamlarda farklı düzeyde ilkeler uygulayabilir: iş yüküne özel, ad alanı genelinde veya ağ genelinde. Bu tür tüm güvenlik kaynakları AuthorizationPolicy veya PeerAuthentication gibi Istio CRD'ler aracılığıyla yönetilir.

Standart mTLS desteğinin ötesinde, Istio, şifrelenmemiş trafiği kabul edecek veya reddedecek şekilde de yapılandırılabilir.

Gözlenebilirlik

Burada, Istio, hizmet ağı hakkında sağlam bilgiler sunan çeşitli telemetri türleri ile kutudan çıktığı gibi oldukça gelişmiştir. Metrikler dört altın sinyale (gecikme, trafik, hatalar ve bir dereceye kadar doygunluk) dayanır.

Özellikle, Istio, kontrol düzleminin kendisi için ölçümler sağlar. Ayrıca, izlemeyi etkinleştirmek için Jaeger, Lightstep ve Zipkin ile açık uyumluluğa sahip olan dağıtılmış izlemeler ve erişim günlükleri sunar.

Yerel bir gösterge panosu yok, ancak Kiali yönetim konsolu için resmi destek var.

Kurulum

Kurulum, resmi adımları takip etmek kadar basittir. Istio ayrıca bir beta özelliği olarak GKE'ye yerel olarak entegre edilmiştir, ancak burada GKE, en son monolit sürümün aksine eski mikro hizmet sürümü olan Istio 1.4.X'i kullanır.

Yerel yükleme, en son sürümün indirilmesiyle başlar:

 curl -L https://istio.io/downloadIstio | sh -

Yeni oluşturulan istio-* klasörüne cd girdikten sonra, istioctl yardımcı programı aracını kullanabilmek için onu yolunuza ekleyebilirsiniz:

 export PATH=$PWD/bin:$PATH

Buradan, Istio'yu istioctl aracılığıyla istioctl :

 istioctl install

Bu, Istio'yu default bir profille yükleyecektir. istioctl profilleri, farklı kurulum konfigürasyonları oluşturmanıza ve gerektiğinde bunlar arasında geçiş yapmanıza olanak tanır. Ancak tek profilli bir senaryoda bile, bazı CRD'leri değiştirerek Istio'nun kurulumunu derinlemesine özelleştirebilirsiniz.

Trafik yönetiminin yerinde olduğundan emin olmak için birkaç tür CRD'yi ( VirtualService , DestinationRule ve Gateway ) yönetmeniz gerekeceğinden, Istio kaynaklarını yönetmek daha zor olacaktır.

• VirtualService kaynağı, bir hizmeti ve isteklere uygulanan farklı yönlendirme kurallarını bildiren bir yapılandırmadır.
• Hedefe özel trafik ilkelerini gruplamak ve uygulamak için bir DestinationRule kaynağı kullanılır.
• Gelen ve giden hizmet ağ trafiğini yönetmek için bir Gateway kaynağı oluşturulur (yani, ek Envoy proxy'leri, ancak sepetler yerine uçta çalışır).

Anlamsal ayrıntılar bu incelemenin kapsamı dışındadır, ancak bunların her birinin birlikte çalıştığını gösteren hızlı bir örneğe bakalım. Diyelim ki products adlı bir hizmeti olan bir e-ticaret sitemiz var. VirtualService Hizmetimiz şöyle görünebilir:

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: products-route namespace: ecommerce spec: hosts: - products # interpreted as products.ecommerce.svc.cluster.local http: - match: - uri: prefix: "/listv1" - uri: prefix: "/catalog" rewrite: uri: "/listproducts" route: - destination: host: products # interpreted as products.ecommerce.svc.cluster.local subset: v2 - route: - destination: host: products # interpreted asproducts.ecommerce.svc.cluster.local subset: v1

Karşılık gelen DestinationRule şu şekilde olabilir:

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: products spec: host: products trafficPolicy: loadBalancer: simple: RANDOM # or LEAST_CONN or ROUND_ROBIN subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v3 labels: version: v3

Son olarak, Gateway :

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: cert-manager-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"

Bu üç dosya yerinde olduğunda, bir Istio kurulumu temel trafiği işlemeye hazır olacaktır.

Istio Hizmet Ağı Özeti

Avantajlar:

• Farklı hizmet ağları arasında Istio, bu yazı itibariyle en büyük çevrimiçi topluluğa sahip olanıdır. Ana rakiplerinden biri olarak 10 kattan fazla Stack Overflow sonuçlarıyla, web üzerinde en çok konuşulan hizmet ağıdır; GitHub'a katkıda bulunanlar da aynı şekilde Linkerd'inkilerin ötesinde bir büyüklük sırasıdır.
• Istio, hem Kubernetes hem de VM modlarını destekler; ikincisi, 1.9 sürümünden itibaren beta sürümündedir.

Dezavantajları:

• Istio iki anlamda özgür değildir:
  • Belgeleri okumak, kurmak, düzgün çalışmasını sağlamak ve bakımını yapmak için gereken süre açısından gereksinimleri yüksektir. Altyapı boyutuna ve hizmetlerin sayısına bağlı olarak, Istio'nun tam olarak işlevsel olması ve üretime entegre olması için birkaç hafta ila birkaç ay süren tam zamanlı çalışma gerekecektir.
  • Ayrıca önemli miktarda kaynak ek yükü ekler: Envoy kapsayıcısı için saniyede 1.000 istek (RPS) için 350 milicore (mCPU) gerekir. Kontrol düzleminin kendisi bile kaynak tüketebilir. (Önceden, kaynak kullanımını tahmin etmek zor olurdu, ancak biraz çabadan sonra istiod , 1 vCPU ve 1.5 GB bellek kullanarak dengelendi.)
• Linkerd'den farklı olarak yerel yönetici panosu yoktur.
• Istio, kendi giriş ağ geçidinin kullanılmasını gerektirir.
• Istio kontrol düzlemi yalnızca Kubernetes kapsayıcılarında desteklenir (yani, Istio'nun veri düzleminden farklı olarak VM modu yoktur).

Istio, teknoloji devlerinin karşı karşıya oldukları bir zorluğun üstesinden gelmek için açık kaynaklı bir proje oluşturmak üzere bir araya gelmelerine harika bir örnektir. Istio projesinin bir bütün olarak kendisini yapılandırması (mikro hizmetlerden monolit mimariye geçişi hatırlatarak) ve başlangıçtaki birçok sorununu çözmesi biraz zaman aldı. Bugün, Istio kesinlikle bir hizmet ağından beklenebilecek her şeyi yapıyor ve büyük ölçüde genişletilebilir. Ancak tüm bu olanaklar, bir üretim ortamında kullanımını desteklemek için bilgi, çalışma saatleri ve bilgi işlem kaynakları açısından büyük gereksinimleri beraberinde getiriyor.

Kuma Hızlı İnceleme

Kong tarafından oluşturulan ve daha sonra açık kaynaklı olan Kuma, 2020'nin sonlarında 1.0'a ulaştı. Bir dereceye kadar, ilk hizmet ağlarının oldukça ağır ve çalıştırılması zor olmasına yanıt olarak oluşturuldu.

Özellik listesi, çok modüler olduğunu öne sürüyor; Kuma'nın arkasındaki fikir, onu Kubernetes veya diğer altyapılarda halihazırda çalışan uygulamalarla entegrasyona yönlendirmektir.

• Trafik yönetimi alanında Kuma, hata enjeksiyonu ve devre kesme gibi ortak hizmet ağı özellikleri sunar.
• Servisler arası mTLS şifrelemesinin ötesinde, veri düzlemi ile kontrol düzlemi arasındaki alışverişler, bir veri düzlemi proxy belirteci aracılığıyla Kuma'da güvence altına alınır.
• Gözlenebilirlik , Kuma'da metrikler, izleme ve günlük kaydı etrafında farklı trafik politikaları aracılığıyla tanımlanır.
• Kontrol düzleminin 5653 numaralı bağlantı noktasında çalışan kendi DNS çözümleyicisi sayesinde Kuma aracılığıyla hizmet keşfi yapılabilir.
• Kuma, çoklu ağ işlevselliğine büyük önem verir: Çok bölgeli dağıtım türüyle birkaç Kubernetes kümesini veya VM ortamını ortak bir Kuma kümesinde kolayca birleştirebilirsiniz.
• Kuma, mevcut Kong kullanıcıları için Kong Gateway ile kolayca entegre olur .

Kuma'nın evrensel (Kubernetes olmayan) sürümü, bağımlılık olarak PostgreSQL'i gerektirir ve Kong'un CTO'su özellikle SMI'yi desteklemeye karşıdır. Ancak Kuma, başlangıçtan itibaren çoklu bulut ve çoklu küme dağıtımları fikriyle geliştirildi ve gösterge paneli bunu yansıtıyor.

Kuma, hizmet ağı alanında hala genç olsa da, şimdiye kadar birkaç üretim kullanımı vakası ile, ilginç ve gelecek vaat eden bir rakip.

Traefik Mesh Hızlı İnceleme

Aslen Maesh olarak adlandırılan Traefik Mesh (Traefik Labs tarafından), servis ağı takımlama yarışında yeni gelen başka bir oyuncu. Proje misyonu, kullanımı ve yapılandırmayı kolaylaştırarak hizmet ağını demokratikleştirmek; geliştiricilerin iyi düşünülmüş Traefik Proxy deneyimi, onları bunu başarmak için birinci sınıf bir konuma getirdi.

• Traefik Mesh'teki trafik yönetimi özellikleri arasında devre kesme ve hız sınırlaması bulunur.
• Gözlemlenebilirlik açısından Traefik Mesh, kurulum süresinden tasarruf sağlayan yerel OpenTracing Desteği ve kullanıma hazır ölçümler (standart kurulum otomatik olarak Prometheus ve Grafana'yı içerir) içerir.
• Güvenlik için - mTLS'nin yanı sıra - özellikler SMI uyumludur ve Traefik Mesh, erişim kontrolü aracılığıyla trafik izinlerinin ince ayarına izin verir.

Traefik Mesh'in kümeye yüklenmesi için CoreDNS'ye ihtiyacı var. (Azure, 1.12'den beri CoreDNS'yi varsayılan olarak kullanıyor olsa da, GKE bu yazı itibariyle varsayılan olarak kube-dns'ye ayarlanmıştır, yani bu durumda önemli bir ekstra adım söz konusudur.) Ayrıca çoklu küme yeteneklerinden de yoksundur.

Bununla birlikte, Traefik Mesh, sepet enjeksiyonu kullanmadığı için hizmet ağı karşılaştırmamızda benzersizdir. Bunun yerine, hizmetler arasında bir proxy görevi görmesi için tüm düğümlerde bir DaemonSet olarak dağıtılır ve bu da onu istilacı yapmaz. Genel olarak, Traefik Mesh'in kurulumu ve kullanımı kolaydır.

AWS App Mesh Hızlı İnceleme

Bulut sağlayıcıları dünyasında AWS, Kubernetes (veya özellikle EKS) ve aynı zamanda diğer hizmetleri ile takılabilir yerel bir hizmet ağı uygulayan ilk şirkettir. AWS App Mesh, Kasım 2018'de piyasaya sürüldü ve AWS, o zamandan beri üzerinde yineleniyor. AWS App Mesh'in ana avantajı, önceden var olan AWS ekosistemi ve pazar konumudur; AWS'nin arkasındaki büyük topluluk, genel olarak kullanımını ve kullanılabilirliğini yönlendirmeye devam edecek.

• AWS App Mesh'teki trafik yönetimi , ortak özelliklerin yanı sıra devre kesmeyi de içerir.
• Since AWS App Mesh is hosted by AWS, it's a fully managed service , which means not having to worry about resource usage or control plane availability.
• Observability in AWS App Mesh can be done through Prometheus or AWS X-Ray.

The project is not open source, doesn't support SMI, and there's not much info online about HA standards for the control plane. AWS App Mesh is more complex to set up than other Kubernetes-native service meshes and has very little community online (24 answers on Stack Overflow, 400 stars on GitHub) but that's because users are meant to benefit from AWS support.

AWS App Mesh has native integration with AWS, starting with EKS and extending to other AWS services like ECS (Fargate) and EC2. Unlike Traefik Mesh, it has multicluster support. Plus, like most service meshes, it's based on injecting Envoy, the battle-tested sidecar proxy.

Kubernetes Service Mesh Comparison Tables

The six Kubernetes service mesh options presented here have a few things in common:

• Protocol support : They all work with HTTP, HTTP/2, gRPC, TCP, and WebSockets.
• They all have basic security in the form of mTLS between proxies by default.
• Service meshes, by design, provide some form of load balancing .
• These six, at least, also include a request retrying option among their traffic management features.
• Lastly, service discovery is a core feature of any service mesh.

But there are certainly differences worth highlighting when it comes to service mesh infrastructure, traffic management, observability, deployment, and other aspects.

altyapı

Trafik Yönetimi

Observability

* OpenCensus and OpenTracing merged into OpenTelemetry in 2019, but you might find Linkerd articles referring to OpenCensus, as well as Istio and Traefik Mesh articles referring to OpenTracing.

dağıtım

Other Service Mesh Considerations

Should We Use a Kubernetes Service Mesh?

Now that we have seen what service meshes are, how they work, and the multitude of differences between them, we can ask: Do we need a service mesh?

That's the big question for SREs and cloud engineers these past few years. Indeed, microservices bring operational challenges in network communication that a service mesh can solve. But service meshes, for the most part, bring their own challenges when it comes to installation and operation.

One problem we can see emerging in many projects is that with service meshes, there is a gap between the proof-of-concept stage and the production stage. That is, it's unfortunately rare for companies to achieve staging environments that are identical to production in every aspect; with service meshes involving crucial infrastructure, scale- and edge-related effects can bring deployment surprises.

Service meshes are still under heavy development and improvement. This could actually be attractive for teams with high deployment velocities—those who have mastered “the art of staying state-of-the-art” and can closely follow the development cycle of cloud-native tools.

For others, though, the pace of service mesh evolution could be more of a pitfall. It would be easy enough to set up a service mesh but then forget about the need to maintain it. Security patches may go unapplied or, even if remembered, may carry with them unplanned issues in the form of deprecated features or a modified set of dependencies.

There's also a notable cost in terms of manpower to set up a service mesh in production. It would be a sensible goal for any team to evaluate this and understand if the benefits from a service mesh would outweigh the initial setup time. Service meshes are hard, no matter what the “easy” demo installations show.

In short, service meshes can solve some of the problems typical to projects deployed at scale but may introduce others, so be prepared to invest time and energy. In a hypothetical infrastructure involving 25 microservices and load of five queries per second, I would recommend having at least one person (preferably two) dedicated for at least a month to preparing a proof of concept and validating key aspects before thinking about running it in production. Once it's set up, anticipate the need for frequent upgrades—they will impact a core component of your infrastructure, namely network communications.

Kubernetes Service Meshes: A (Complex) Evolution in Scalable App Architecture

We've seen what service meshes are: a suite of tooling to answer new challenges introduced by microservices architecture. Through traffic management, observability, service discovery, and enhanced security, service meshes can reveal deep insights into app infrastructure.

There are multiple actors on the market, sometimes promoted by GAFAM et al., that have in some cases open-sourced or promoted their own internal tooling. Despite two different implementation types, service meshes will always have a control plane—the brain of the system—and a data plane, made of proxies that will intercept the requests of your application.

Reviewing the three biggest service meshes (Linkerd, Consul Connect, and Istio) we have seen the different strategies they've chosen to implement and the advantages they bring. Linkerd, being the oldest service mesh on the market, benefits from its creators' experience at Twitter. HashiCorp, for its part, offers the enterprise-ready Consul Connect, backed by a high level of expertise and support. Istio, which initially garnered ample attention online, has evolved into a mature project, delivering a feature-complete platform in the end.

But these actors are far from being the only ones, and some less-talked-about service meshes have emerged: Kuma, Traefik Mesh, and AWS App Mesh, among others. Kuma, from Kong, was created with the idea of making the service mesh idea “simple” and pluggable into any system, not just Kubernetes. Traefik Mesh benefited from experience with the preexisting Traefik Proxy and made the rare decision to eschew sidecar proxies. Last but not least, AWS decided to develop its own version of the service mesh, but one that relies on the dependable Envoy sidecar proxy.

In practice, service meshes are still hard to implement. Although service mesh benefits are compelling, their impact, critically, cuts both ways: Failure of a service mesh could render your microservices unable to communicate with each other, possibly bringing down your entire stack. A notorious example of this: Incompatibility between a Linkerd version and a Kubernetes version created a complete production outage at Monzo, an online bank.

Nonetheless, the whole industry is structuring itself around Kubernetes and initiatives like the Microsoft-spearheaded SMI, a standard interface for service meshes on Kubernetes. Among numerous other projects, the Cloud Native Computing Foundation (CNCF) has the Envoy-based Open Service Mesh (OSM) initiative, which was also originally introduced by Microsoft. The service mesh ecosystem remains abuzz, and I predict a champion emerging in the coming years, the same way Kubernetes became the de facto container orchestration tool.