Service Mesh Mimari Diyagramı: Veri Düzlemi, Kontrol Düzlemi ve mTLS

Bir sistemde onlarca servis olduğunda aynı ağ kodu her birinde karşınıza çıkar: yeniden denemeler, zaman aşımları, servisler arası TLS, çağrı başına metrikler, sürümler için trafik bölme. Bir service mesh bu kodu servislerden çıkarıp ağ yoluna taşır; orada tek bir ekip onu herkes için yapılandırabilir.

Bu yazı bir mesh'in nasıl kurulduğunu, kontrol düzlemi ile veri düzleminin ayrı ayrı ne yaptığını, otomatik mTLS'in nasıl çalıştığını ve mesh'i birçok ekip için yanlış seçim yapan maliyetleri anlatıyor. Diyagram klasik sidecar tasarımını gösteriyor.

Veri düzlemi ve kontrol düzlemi

Veri düzlemi, servisler arasındaki her isteğin yolunda duran bir proxy kümesidir. Sidecar modelinde her pod kendi proxy konteynerini alır. Uygulama yerel proxy'siyle düz HTTP konuşur; hattaki her şeyi proxy halleder: şifreleme, yeniden denemeler, yük dengeleme, metrikler. Istio sidecar olarak Envoy kullanır; Linkerd ise bu iş için özel olarak geliştirilmiş, Rust ile yazılmış kendi proxy'sini kullanır.

Kontrol düzlemi istek trafiğine hiç dokunmaz. Cluster'daki servisleri ve uç noktaları izler, politikalarınızı proxy yapılandırmasına dönüştürür, bu yapılandırmayı her proxy'ye iter ve proxy'lerin kendilerini tanıtmak için kullandığı sertifikaları verir. Istio'da bu bileşen istiod'dir; Istio mimari sayfasına bakın. Linkerd'in mimari referansı karşılık gelen parçaları anlatır.

Otomatik mTLS ve iş yükü kimliği

Her servis çifti arasında karşılıklı TLS (mutual TLS), çoğu ekibi ikna eden özelliktir. Her proxy, kontrol düzleminden iş yükünü adlandıran kısa ömürlü bir sertifika alır. Bu genellikle Kubernetes namespace'i ve service account'undan türetilen bir SPIFFE kimliğidir, örneğin spiffe://cluster.local/ns/shop/sa/orders. İki proxy bağlandığında ikisi de sertifikasını sunar, ikisi de karşı tarafınkini doğrular ve bağlantı şifrelenir.

İki sonucu önemlidir:

• Kimlik, ağ konumunun yerini alır. Bir politika "payments yalnızca orders service account'undan gelen çağrıları kabul eder" diyebilir; bu, "şu alt ağdan" demekten daha güçlüdür.
• Yenileme otomatiktir. Sertifikalar birkaç saat yaşar ve kimse onları yenilemek için ticket açmaz.

Her şey mesh'e girdikten sonra strict modu açın; böylece düz metin bağlantılar sessizce kabul edilmek yerine reddedilir.

Mesh içinden geçen bir istek

orders'tan payments'a giden bir çağrıyı takip edin:

1. orders uygulaması payments servis adına düz bir HTTP isteği gönderir. Trafik yönlendirme bu isteği ağa değil yerel sidecar'a gönderir.
2. orders sidecar'ı, kontrol düzleminin ittiği yapılandırmadan sağlıklı payments uç noktalarını bulur, yük dengeleme algoritmasıyla birini seçer ve bu rota için tanımlı zaman aşımını uygular.
3. payments sidecar'ına bir mTLS bağlantısı açar ya da var olanı yeniden kullanır ve orders sertifikasını sunar.
4. payments sidecar'ı sertifikayı doğrular, yetkilendirme politikasını kontrol eder (orders'ın payments'ı çağırmasına izin var mı?) ve isteği localhost üzerinden payments uygulamasına iletir.
5. İki sidecar da isteği, durumunu ve gecikmesini kaydeder. Çağrı yeniden denenebilir bir durum koduyla başarısız olursa orders sidecar'ı bütçesi dahilinde yeniden deneyebilir.

Uygulamaların hiçbiri bunların olduğunu bilmez. Asıl amaç da budur, risk de: kodda göremediğiniz davranış başka bir yerde, örneğin diyagramda görünür olmalıdır.

Mesh'i devreye almak

Adım adım benimseyin. Kontrol düzlemini kurun, servisleri permissive modda birer namespace olarak ekleyin ki düz metin trafik çalışmaya devam etsin, metrikleri izleyin, sonra her namespace'i strict mTLS'e geçirin. Yetkilendirme politikalarını en son ekleyin; hassas veri tutan servislerden başlayın.

Trafik politikası

Her çağrı bir proxy'den geçtiği için mesh aynı kuralları her yerde uygulayabilir:

• Zaman aşımları ve yeniden denemeler, bir kesinti sırasında yeniden denemeler katlanmasın diye bütçelerle birlikte.
• Circuit breaking ve outlier detection: sürekli başarısız olan örneklere trafik göndermeyi bırakın.
• Trafik bölme, ağırlığa ya da header'a göre; mesh'te canary sürümleri bu şekilde uygulanır.
• Hata enjeksiyonu, test için: çağrıların bir yüzdesine gecikme ya da hata ekleyin.

Yeniden denemenin iki yerde birden yapılmasına dikkat edin. Uygulama da sidecar da yeniden denerse, başarısız tek bir çağrı birçok çağrıya dönüşür. Yeniden denemeler için tek bir sahip seçin ve bunu yazılı hale getirin.

Neredeyse bedava gözlemlenebilirlik

Proxy'ler, uygulamaları değiştirmeden kaynak ve hedef başına istek sayılarını, hata oranlarını ve gecikmeyi raporlar. Trace span'leri de başlatıp yayabilirler; ama gelen isteklerdeki trace header'larını giden isteklere aktarmak yine uygulamanın işidir, yoksa trace'ler her serviste kopar.

Sidecar'lar ve ambient mod

Sidecar'ların gerçek maliyetleri vardır: her pod'daki bir proxy CPU ve bellek kullanır, her adıma gecikme ekler, pod başlatmayı ve yükseltmeleri daha karmaşık hale getirir. Istio'nun ambient modu pod başına sidecar'ı kaldırır. ztunnel adlı düğüm başına bir proxy mTLS'i ve katman 4 politikasını üstlenir; isteğe bağlı waypoint proxy'leri ise katman 7 özelliklerini yalnızca onlara ihtiyaç duyan servisler için sağlar. Bedeli farklı bir işletim modeli ve sidecar'lara göre daha kısa bir üretim geçmişidir.

Mimari diyagram

Nasıl okunur:

• Sol: ingress gateway dışarıdan gelen trafiği alır ve orders pod'undaki sidecar'a bir mTLS bağlantısı açar.
• Orta: her pod'un içinde sidecar isteği localhost üzerinden uygulamaya iletir. orders sidecar'ı payments ve inventory sidecar'larını mTLS ile çağırır; uygulamalar hiçbir zaman sertifikayla uğraşmaz.
• Alt: kontrol düzlemi proxy'lere yapılandırma ve sertifika iter (kesikli kenarlar). İstek yolunda yer almaz.
• Sağ: sidecar'lar metrik ve trace raporlar (noktalı). Markdown bloğu payments için bir politikayı gösterir: onu kimin çağırabileceği, zaman aşımları ve yeniden denemeler, outlier ejection ve strict mTLS.

Mesh ne zaman kullanılmamalı

• Bir avuç servis ya da birkaç uydusu olan bir monolit. Bir kütüphane ya da bir API ağ geçidi bu ihtiyaçları maliyetin çok küçük bir kısmıyla karşılar.
• Sahiplenecek bir ekip yoksa. Mesh; yükseltme, hata ayıklama becerisi ve nöbet bilgisi isteyen bir altyapıdır.
• Asıl hedef yalnızca şifrelemeyse. Birçok bulut ve CNI eklentisi, tam bir mesh olmadan pod trafiğini şifreleyebilir.

Mesh diyagramına neler konmalı

• İki düzlem de, açıkça ayrılmış ve kontrol düzlemi istek yolunun dışında olacak şekilde.
• TLS'in nerede başlayıp bittiği: proxy'den proxy'ye mTLS, localhost'ta ise düz HTTP.
• Kimlikler, en azından erişim politikası olan servisler için.
• Davranışı değiştiren politikalar: zaman aşımları, yeniden denemeler, circuit breaking.

Kubernetes mimari diyagramı mesh'in çalıştığı cluster'ı gösteriyor, sıfır güven mimarisi diyagramı kimlik tabanlı politikaların neden önemli olduğunu açıklıyor, mikroservis mimari diyagramı ise servislerin kendisini ele alıyor.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Ingress gateway için C4 Modeli paketinden bir Konteyner ekleyin.
3. Her pod için Temel paketinden bir Çerçeve ekleyin; içine sidecar için bir Bileşen, uygulama için bir Konteyner koyun.
4. Kontrol düzlemi için bir Konteyner, DevOps paketinden de Metrikler ekleyin.
5. Sidecar'lar arasına mTLS kenarları, kontrol düzleminden kesikli kenarlar ve noktalı telemetri kenarları çizin; bir servisin politikasını içeren, Temel paketinden bir Markdown bloğu ekleyin.

Örnek 13 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

Service mesh ile API ağ geçidi arasındaki fark nedir? API ağ geçidi sisteme dışarıdan giren trafiği yönetir. Service mesh ise sistemin içindeki servisler arasındaki trafiği yönetir. Birçok sistem ikisini birden kullanır.

Service mesh gecikme ekler mi? Evet, her proxy adımı biraz gecikme ekler; bu genellikle adım başına birkaç milisaniyenin oldukça altındadır. Buna proxy'lerin CPU ve bellek kullanımı da eklenir. Kendi trafiğiniz için ölçün.

Mesh için uygulama kodumu değiştirmem gerekir mi? Çoğunlukla hayır. İstisna tracing'dir: trace'lerin servisler arasında birleşmesi için uygulamaların trace header'larını aktarması gerekir.

Ambient mod nedir? Sidecar'sız bir Istio veri düzlemi: düğüm başına bir proxy mTLS'i ve katman 4'ü üstlenir, isteğe bağlı waypoint proxy'leri de gereken yerlerde katman 7 özelliklerini sağlar.

Mesh'in sahibi kim olmalı? Bir platform ekibi. Servis ekipleri mesh'in özelliklerini politikalar aracılığıyla kullanır, ama birinin onu yükseltmesi, izlemesi ve hatalarını ayıklaması gerekir.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.