Sorunun geçmişi

Servis mesh mimarileri, microservice iletişim karmaşıklığını gidermek amacıyla API geçitlerinden, Istio ve Linkerd gibi yan uygulama tabanlı çözümlere evrildi. Şirketler, satıcı bağımlılığını önlemek ve dayanıklılığı artırmak için çok bulutlu stratejileri benimsedikçe, bu mesh'lerin heterojen bulut sağlayıcıları arasında federasyon yapma gerekliliği ön plana çıktı. İlk denemeler merkezi kontrol düzlemlerine veya VPN merkez-peri modellerine dayanıyordu; bu da, küresel uygulamalar için kabul edilemez gecikmeler ve tek hata noktaları ekledi. Bu soru, finansal ticaret platformları ve sıkı gecikme SLA'larına ve çevrimdışı kullanılabilir kenar hesaplamaya ihtiyaç duyan IoT dağıtımları gibi karşılaşılan zorlukları sentezler.

Sorun

AWS, Azure ve GCP arasında servis mesh'lerini federasyon yapmanın, uyumsuz ağ soyutlamaları, değişen CNI uygulamaları ve özel kimlik sistemleri nedeniyle benzersiz engelleri vardır. Bulutlar arası trafik genellikle kamu interneti veya pahalı özel bağlantılar üzerinden geçer ve değişken gecikmeler ve paket kayıpları gerçekleşir, bu da 50ms altı gereksinimlerini ihlal eder. Asimetrik ağ bölümleri sırasında - AWS us-east-1'in GCP europe-west1'e ulaşabilmesi fakat Azure southeast-asia'ya ulaşamaması durumunda merkezi bir OIDC sağlayıcısına bağımlı iş yükleri varsa, sıfır güven mTLS kimlik doğrulamasını korumak imkansız hale gelir. Ayrıca, geçici kenar düğümleri (örneğin, 5G MEC cihazları veya otonom araç birimleri) kalıcı kimliklere sahip olmayıp, merkezi kontrol düzlemleriyle uzun süreli bağlantıları koruyamazlar. Ancak, manuel müdahale olmadan güvenlik perimetresine anında kaydolmaları gerekmektedir.

Çözüm

Ağ topolojisinden bağımsız yük iş yükü kimlikleri için SPIFFE/SPIRE'ı kullanan, merkezi bir Istio birincil-ikinci federasyon topolojisi uygulayın.

Her bulut sağlayıcısında, gecikme farkındalığına sahip yönlendirme ve çapraz küme yük dengelemesi için WASM filtreleri ile yapılandırılmış Envoy proxyleri olarak hizmet veren bölgesel giriş geçitleri dağıtın. Bölgesel geçitler arasında trafik şifrelemek için WireGuard veya IPsec tünelleri kurun ve hizmet düzeylerinde mTLS için doğrudan yan-yana iletişime izin verin. Her bölgede SPIRE sunucularını, bölümler sırasında SVID doğrulamalarına olanak tanıyan, S3 bucket'larına yayınlanan federasyon güven paketleri ile yapılandırın. Kenar düğümleri için, S3'te barındırılan yapılandırmalar ve STS geçici kimlik bilgilerinin yüklenmesi ile başlatılan Istio ortam ağı ztunnel ajanlarını kullanarak, en yakın bölgesel geçitle karşılıklı TLS bağlantısı kurun; böylece kalıcı kontrol düzlemi bağlantısına ihtiyaç duyulmaz.

Hayattan bir durum

Küresel bir yüksek frekanslı ticaret platformu, AWS us-east-1'deki emir yürütme hizmetlerini, GCP europe-west1'deki risk analizi mikro hizmetleriyle ve Azure southeast-asia'daki müşteri portföy verileriyle bağlamayı gerektiriyordu. Şirket yükümlülüğü, arbitrasyon kayıplarını önlemek için bulutlar arası risk puanlama çağrıları için 50ms altı gidiş-dönüş gecikmesi talep etti. Kuzey Amerika ile Avrupa arasında simüle edilen bir denizaltı kablo kesintisi sırasında, şirketin yerel veri merkezindeki mevcut IPSec VPN merkezi bir darboğaz haline geldi ve gecikmeyi 180ms artırarak ticareti 12 dakika boyunca durdurdu.

Sorun açıklaması

Eski mimari, merkezi bir F5 yük dengeleyici kümesi ve kimlik doğrulama için Active Directory Domain Services kullanıyordu; bu da tek bir hata noktası yaratıyordu. Ağ bölümü gerçekleştiğinde, Azure iş yükleri merkezi AD sunucusuna karşı JWT belirteçlerini doğrulayamadı ve bu da zincirleme kimlik doğrulama hatalarına neden oldu. Ayrıca, ticaret katındaki yeni 5G kenar hesaplama düğümleri (çalışan NVIDIA Jetson cihazları) yerel olarak piyasa verilerini işlemek için mesh'e katılmaları gerekiyordu, ancak standart Istio yan uygulama modeli cihazların 2GB RAM sınırını aşıyor ve 45 dakika manuel olarak alınması gereken VPN sertifikalarını gerektiriyordu.

Çözüm A: Merkezi politika yönetimi ile yerel bulut transit peering

Bu yaklaşım, yüksek bant genişliği sunan AWS Transit Gateway peering'i ile Azure Virtual WAN ve GCP Cloud Interconnect'i kullanarak tam bir mesh ağ topolojisi oluşturur. Tüm bulutlar arası trafik, Palo Alto veya Fortinet cihazları tarafından yönetilen merkezi kurumsal güvenlik duvarı kümeleri üzerinden yönlendirilir; bu, tanıdık bir güvenlik perimetresi sağlar. Bu yapılandırma, bulut bölgeleri büyüdükçe veya küçüldükçe bağlantıyı sürdürmek için BGP yönlendirme yayılımına dayanır.

Artıları: Yerel entegrasyon yüksek bant genişliği sağlar, 100Gbps'a kadar çıkabilir ve yerel bulut araçları veya Aviatrix denetleyicileri aracılığıyla uyumluluk denetimi için merkezi görünürlük sunar. Bu yaklaşım, mevcut ağ mühendisliği iş akışlarında, MPLS omurgasına aşina olan minimal değişiklikler gerektirir.
Eksileri: Bulutlar arası trafik için veri çıkış maliyetleri GB başına $0.09'u aşmaktadır ve bu da ticaret platformu hacimlerinde aylık $500K'ı aşacak fatura projeksiyonları yaratmaktadır. Mimari, güvenlik duvarı kümelerinde 80-120ms gecikmeler ekleyen darboğazlar meydana getirir ve bu da 50ms altı gereksinimlerini ihlal eder. Statik IP adresleri veya BGP peering yetenekleri olmayan geçici kenar düğümleri için hiçbir uygulanabilir kayıt yolu sunmamaktadır.

Çözüm B: Cilium küme mesh'i ile eBPF veri yolu

Bu mimari, her Kubernetes kümesinde Cilium'u dağıtarak, eBPF'yi çekirdek seviyesinde yük dengeleme ve WireGuard şifrelemesi için kullanır. Cilium ClusterMesh, her bulutta etcd kümeleri arasında Kubernetes Endpoint senkronizasyonu sağlayarak çok bölgeli hizmet keşfini mümkün kılar. Veri yolu, iptables'ı tamamen bypass eder, işlemci yükünü alt milisaniye seviyelerine düşürür ve yan uygulamalar olmadan gözlemlenebilirlik sağlar.

Artıları: eBPF, minimal CPU yüküyle olağanüstü performans sağlar ve katman 4 trafiği için Envoy yan uygulamalarına olan ihtiyacı ortadan kaldırır. Çözüm, şeffaf şifreleme ve ince-granül ağ politikaları yoluyla mükemmel güvenlik sunar.
Eksileri: Cilium, Azure CNI Overlay modu ve mevcut Calico politika uygulamaları ile uyumsuz homojen CNI yapılandırmaları gerektirir. Bulutlar arası BGP peering, bulut ağ ekipleri ile karmaşık bir koordinasyon gerektirir ve ticaret protokolleri için gerekli olan ince gRPC yöntem düzeyinde yönlendirmeyi bilmez. Geçici düğümlere destek sınırlıdır çünkü Cilium, sıklıkla yeniden başlatılan cihazlar için uygun olmayan kalıcı Kubernetes düğüm kimliklerine dayanır.

Çözüm C: SPIFFE ve ortam ağı ile merkeziyetsiz Istio federasyonu

Her bulutun kendi istiod kontrol düzlemini sürdürdüğü bir Istio birincil-ikinci federasyonunu benimseyin. Flux veya ArgoCD kullanarak GitOps boru hattı ile senkronize edin. Bölüm dayanıklılığı için federasyon güven paketlerini S3 bucket'larında depolayarak saklayın. Kenar düğümlerinde, kaynakları korumak için yan uygulamalar yerine Istio ortam ağı ztunnel ajanlarını kullanın. Bölgesel geçitler, bulutlar arasında WireGuard tünelleri kurar, böylece Envoy yan uygulamaları doğrudan iletişim kurabilir ve merkezi hub'lar üzerinden taşınmadan iletişimde bulunabilir.

Artıları: Envoy yan uygulamaları, finansal protokoller için gerekli olan gRPC yönlendirmesi, devre kesme ve tekrar politikaları dahil olmak üzere karmaşık trafik yönetimi sağlar. SPIFFE kimlikleri, sürekli sunuculara değil, S3'te yayınlanan paketlere göre doğrulandıkları için ağ bölümleri sırasında yerel olarak önbelleğe alınır ve hayatta kalır. Ztunnel, her düğüm başına yalnızca 50MB RAM tüketir, bu da NVIDIA Jetson cihazlarının tam olarak katılımı için olanak tanır.
Eksileri: Operasyonel karmaşıklık, ekiplerin üç bağımsız kontrol düzlemini yönetmesi ve EKS, AKS ve GKE üzerinde CRD sürüm uyumluluğunu sağlaması gerektiği için önemli ölçüde artar. İlk başlatma, bulutlar arası S3 erişimi için dikkatli IAM rol yapılandırması gerektirir.

Seçilen çözüm ve gerekçe

Çözüm C, doğrudan Envoy yan uygulama-to-yan uygulama iletişimini WireGuard tünelleri üzerinden sağladığı için sıkı 50ms gecikme gereksinimini benzersiz bir şekilde karşıladığı için seçildi. Ayrıca, merkezi OIDC sağlayıcılarına bağımlı olmadan, bölümler sırasında sıfır güvenlik garantilerini korudu. Mimari, alternatif çözümler A ve B'nin maliyet, gecikme veya kenar kısıtlamaları üzerinde başarısız olduğu kaynak kısıtlı kenar düğümlerini de barındırıyordu.

Sonuç

Uygulama sonrası, bulutlar arası gecikme %99'luk dilimde 38ms olarak stabilize oldu, bu da 50ms SLA'sının oldukça içindeydi. AWS ve Azure arasında planlanmamış bir kesinti sırasında, sistem, önbelleğe alınmış SVID'ler ve eski-ama-güvenli yönlendirme kuralları kullanarak %94'lük işlem hacmini sürdürdü. Kenar düğümü sağlama süresi, otomatik S3 başlatma betikleri aracılığıyla 45 dakikadan 90 saniyeye düştü. Aylık ağ maliyetleri, yerel Transit Gateway peering tahminleriyle karşılaştırıldığında %60 oranında azaldı, bu da aylık yaklaşık $300K tasarruf sağladı.

Adayların sıkça unuttuğu şey

Soru: Bir ağ bölümü sırasında bölgesel SPIRE sunucusu ulaşılamadığında SPIRE iş yükü taklitini nasıl engeller?

Cevap: Her düğümde çalışan SPIRE ajanları, X.509 SVID sertifikaları ve kamu anahtarı güven paketlerinin yerel önbelleklerini korur. Bir iş yükü mTLS kurmaya çalıştığında, eş, SVID'yi canlı bir sunucuya sorgulamak yerine yerel olarak önbelleğe alınmış paketle doğrular, bu da bölünmeler sırasında kimlik doğrulamanın başarıyla gerçekleşmesini sağlar. SVID'ler kısa TTL'lere (genellikle 5 dakika) sahiptir ve iş yükünün belirli özel anahtarına bağlanır; bu, bir saldırganın önbelleğe alınmış bir sertifikayı ele geçirmesi durumunda yeniden oynatma saldırılarını önler. Bölüm sırasında katılan yeni iş yükleri, merkeziye bağımlı olmayan AWS IAM örnek kimlik belgeleri veya TPM EK sertifikaları gibi düğüm düzeyinde doğrulayıcılar kullanarak yerel ajans tarafından tasdik edilir.

Soru: Neden Istio ortam ağı, geleneksel yan uygulama enjekte edilmesine kıyasla geçici kenar düğümleri için kaynak tüketimini azaltır?

Cevap: Geleneksel Istio, her uygulama pod'unda yaklaşık 100MB RAM ve 0.5 vCPU tüketen bir Envoy yan uygulama konteyneri dağıtır. Bu da NVIDIA Jetson gibi kaynak kısıtlı kenar cihazlarını tüketir. Ortam ağı, mTLS sonlandırmasını ve katman 4 yönlendirmeyi tüm o host'taki pod'lar arasında paylaşan bir DaemonSet olarak ztunnel'ı dağıtır, böylece her iş yükü üzerindeki yükü hemen hemen sıfıra düşürür. Ztunnel, çekirdek düzeyinde paket yönlendirmesi için eBPF kullanarak iptables geçiş maliyetlerini ortadan kaldırır. Sık sık mesh'e katılan ve ayrılan geçici kenar düğümleri için, ztunnel bölgesel geçit ile tek bir kalıcı bağlantı havuzu sürdürür; bu da yüzlerce bireysel yan uygulamanın aynı anda başlatılmasına bağlı bağlantı kurma dalgalanmaları ve bellek patlamalarını ortadan kaldırır.

Soru: Çok bulutlu federasyondaki bağımsız Istio kontrol düzlemleri arasındaki yapılandırma kaymalarını nasıl önlersiniz?

Cevap: VirtualService ve AuthorizationPolicy manifestlerini tek kaynak olarak ele alan bir GitOps boru hattı uygulayın; bu da federasyonlu bir Git deposunda saklanır. Her bölgesel kontrol düzlemi, bu depodan yapılandırmaları çeker, bu da AWS CodeCommit çok bölge çoğaltma veya GitLab Geo kullanarak bulutlar arasında kopyalanır. OPA (Open Policy Agent) kabul webhook'larını kullanarak depodan sapma gösteren herhangi bir yerel değişikliği reddeder. Daima CI/CD boru hatlarında Istio yapılandırma analiz araçlarının çalıştırılması, dağıtımdan önce EKS, AKS ve GKE kümeleri arasında CRD versiyon kaymasını tespit etmeyi sağlar; böylece sıkı tutarlılık sağlanır.