10.1. Servis Ağı Mimarisi

Bir mesh iki düzleme ayrılır: istek yolunda oturan ve trafiği gerçekten taşıyan proxy’lerden oluşan bir veri düzlemi ve onları yapılandıran bir kontrol düzlemi. Bu ayrımı anlamak, hem mesh’in gücünü (bir servisi yeniden dağıtmadan yönlendirmeyi ya da güvenlik politikasını değiştirmek) hem de maliyetini (her istek artık fazladan bir proxy’den geçer) açıklar. Bu bölüm, Envoy veri düzlemini, Istio ve Linkerd kontrol düzlemlerini, sağladıkları trafik yönetimi ve gözlemlenebilirlik özelliklerini ve maliyet denklemini yeniden yazan sidecar’sız modelleri kapsar.

İncelenen Konular

10.1.1. Servis Ağı Neden Var: L4 ve L7 Problemleri: Mesh’i, her dildeki kütüphanelerin tekdüze çözemediği L4-e-karşı-L7 problemleriyle gerekçelendirir.
10.1.2. Envoy Proxy: Veri Düzleminin Omurgası: Çoğu servis mesh’inin veri düzlemini oluşturan yüksek performanslı proxy olan Envoy’u kapsar.
10.1.3. Istio: istiod ve Birleşik Kontrol Düzlemi: Istio’nun birleşik istiod kontrol düzlemini ve Envoy veri düzlemini nasıl yapılandırdığını açıklar.
10.1.4. Linkerd: Rust Tabanlı Proxy ile Hafif Bir Alternatif: Amaca yönelik inşa edilmiş bir Rust mikro-proxy’si üzerine kurulu hafif bir mesh olan Linkerd’i kapsar.
10.1.5. Trafik Yönetimi: Yük Dengeleme, Yeniden Deneme ve Hata Enjeksiyonu: Uygulama koduna dokunmadan yapılandırılan mesh düzeyinde yük dengeleme, yeniden deneme ve hata enjeksiyonunu açıklar.
10.1.6. Mesh Düzeyinde Gözlemlenebilirlik: Otomatik Telemetri: Bir mesh’in her servis için enstrümantasyon olmadan yaydığı otomatik altın-sinyal telemetrisini kapsar.
10.1.7. Sidecar’sız Mesh: Istio Ambient Modu ve Cilium Service Mesh: Sidecar’sız mesh’leri açıklar — Istio Ambient’in ztunnel ve waypoint ayrımı ve Cilium’un eBPF yaklaşımı.