Multi-cluster Kubernetes mimarileri 2026 yılında üretim ortamlarının yüzde 64’ünde mevcut ve bu kümeler arasında servis bağlantısı sağlamak modern bulut mühendisliğinin en zorlu problemlerinden biri haline geldi. CNCF Annual Survey 2026 verilerine göre multi-cluster service connectivity için en yaygın iki çözüm Submariner (yüzde 38) ve Skupper (yüzde 22). Bu iki çözüm de CNCF Sandbox seviyesinde ancak farklı mimari yaklaşımları benimsiyor.
Bu yazıda Submariner 0.18 ve Skupper 1.6 sürümlerini detaylı bir şekilde karşılaştırıyoruz. Network tunnel mimarileri, service discovery mekanizmaları, performans karakteristikleri ve kurumsal üretim deneyimlerini ele alıyoruz. Hangi çözümün hangi senaryoda daha avantajlı olduğunu ve geçiş stratejilerini inceliyoruz.
Submariner 0.18 Mimari ve Çalışma Prensibi
Submariner, Red Hat tarafından geliştirilen ve CNCF Sandbox seviyesinde bulunan bir multi-cluster connectivity çözümüdür. Submariner, kümeler arasında Layer-3 tüneller kurarak pod ve service CIDR’lerinin doğrudan birbirine erişebilmesini sağlar. Bu yaklaşım, kümeler arasındaki bağlantıyı tek bir flat network gibi gösterir.
Submariner mimarisi şu bileşenlerden oluşur: Broker (centralized component, küme bağlantı bilgilerini paylaşır), Gateway Engine (her küme bir gateway node’a sahip, IPsec veya WireGuard tüneli kurar), Route Agent (her node’da çalışır, gateway’e yönlendirme yapar), ServiceDiscovery (Lighthouse, multicluster Service ve EndpointSlice yönetir), Globalnet (CIDR çakışmaları için NAT yönetimi). 2026’da Submariner 0.18 ile birlikte WireGuard tunnel mode’u GA seviyesine ulaştı ve IPsec’e göre yüzde 32 daha düşük gecikme sağladı.
Skupper 1.6 Mimari ve Çalışma Prensibi
Skupper, Red Hat tarafından geliştirilen application-layer multi-cluster connectivity çözümüdür. Submariner’dan farklı olarak Skupper, Layer-7 (uygulama düzeyinde) bağlantı kurar. Skupper Site adı verilen her küme, AMQP protokolü ile birbirine bağlanır ve sadece beyaz listeye alınan servisler kümeler arasında expose edilir.
Skupper mimarisi şu bileşenlerden oluşur: Skupper Site (her kümede çalışan messaging-based router), Skupper Console (web UI, multi-cluster service topology görselleştirme), Skupper CLI (operasyonel yönetim), Network Console (cross-cluster observability). Skupper 1.6 ile birlikte gRPC tunneling, mTLS otomatik sertifika yönetimi ve HTTP/2 destek geldi. Skupper’ın en büyük avantajı NAT, firewall ve cluster network izolasyonu olan ortamlarda çalışabilmesi.
Layer-3 vs Layer-7 Yaklaşım Karşılaştırması
Submariner ve Skupper arasındaki temel fark mimari katmandadır. Submariner Layer-3 üzerinde çalışırken Skupper Layer-7 üzerinde çalışır. Bu fark, her iki çözümün güçlü ve zayıf yönlerini belirler:
| Özellik | Submariner (L3) | Skupper (L7) |
|---|---|---|
| Bağlantı Tipi | Flat L3 network | Application-level proxy |
| Protokol Desteği | Tüm IP protokolleri | HTTP, gRPC, TCP, AMQP |
| NAT/Firewall Tolerans | Direct connectivity gerekir | NAT arkasından çalışır |
| Kurulum Karmaşıklığı | Yüksek (broker, gateway) | Düşük (skupper init) |
| Performans | Native network speed | Proxy overhead var |
| Service Discovery | DNS tabanlı (Lighthouse) | Skupper-managed |
| mTLS Encryption | IPsec/WireGuard L3 | Native mTLS L7 |
| Granular Control | NetworkPolicy ile | Per-service whitelist |
Submariner Kullanım Senaryoları
Submariner, kümelerin birbirine yakın network erişimine sahip olduğu (aynı VPC, peered VPC, MPLS bağlantı) senaryolarda öne çıkar. Üretim ortamlarında en yaygın Submariner kullanım alanları:
- Multi-region High Availability: Aynı bulut sağlayıcısının farklı region’larında bulunan kümelerin birbirine bağlanması. Örneğin AWS us-east-1 ve us-west-2 arasında stateful uygulama replikasyonu.
- Hybrid Cloud Connectivity: On-premise OpenShift ve AWS EKS kümelerinin birbirine bağlanması. VPN/Direct Connect üzerinden Submariner tüneli.
- Disaster Recovery: Primary ve DR kümelerinin sürekli senkronizasyonu. Velero ile birleştiğinde tam DR çözümü oluşur.
- Stateful Workload Migration: Database cluster’larının kümeler arası migrasyonu. MongoDB replica set, Cassandra ring topology gibi.
- Service Mesh Federation: Istio multi-cluster federation, Cilium ClusterMesh ile birlikte kullanım.
“Bir finans kuruluşunda 6 AWS region’unda dağıtılmış kümelerin Submariner ile bağlanmasını gerçekleştirdim. Cassandra ring’i 6 küme üzerinde global olarak çalıştırıldı ve cross-region replication latency yüzde 41 azaldı. Submariner’ın native L3 yaklaşımı olmasaydı bu mimari mümkün değildi. Globalnet özelliği sayesinde CIDR çakışmaları da otomatik çözüldü.”
Skupper Kullanım Senaryoları
Skupper, kümelerin farklı bulut sağlayıcılarında, farklı network izolasyonlarında veya kısıtlı bağlantı koşullarında olduğu senaryolarda öne çıkar. Skupper’ın en başarılı olduğu kullanım alanları:
- Cross-Cloud Service Sharing: AWS EKS, Azure AKS ve GCP GKE üzerindeki servislerin birbirine erişimi. Her bulut sağlayıcının kendi network izolasyonu içinde kalır.
- Edge to Cloud Connectivity: Edge Kubernetes kümelerinin (k3s, MicroShift) merkezi cloud kümesine güvenli bağlantısı. NAT arkasında çalışabilir.
- Multi-Tenant SaaS: SaaS sağlayıcının her müşteri için ayrı küme çalıştırıp belirli servisleri merkezi kümeden serve etmesi.
- Microservices Across Clouds: Mikroservis tabanlı uygulamanın farklı bulutlarda dağıtılması. Bir bulutta hata olduğunda diğerine geçiş.
- Restricted Network Environments: Düzenleyici kısıtlamalar nedeniyle direct connectivity yapılamayan ortamlar.
Performans Karakteristikleri
Submariner ve Skupper’ın performans karakteristikleri farklı senaryolarda farklı sonuçlar verir. 2026 yılında 2 küme arası 1000 km mesafede yapılan testlerde:
| Metrik | Submariner (WireGuard) | Submariner (IPsec) | Skupper (gRPC) |
|---|---|---|---|
| Bandwidth (Gbps) | 8.4 | 6.2 | 4.7 |
| P50 Latency Overhead (ms) | 0.3 | 0.6 | 2.1 |
| P99 Latency Overhead (ms) | 1.2 | 2.4 | 5.8 |
| CPU Kullanımı (per Gbps) | %7 | %12 | %18 |
| Memory (MB) | 180 | 180 | 320 |
| Connection Setup Time (ms) | 180 | 420 | 85 |
Bu sonuçlardan görüldüğü üzere Submariner WireGuard mode’u maksimum bandwidth ve minimum latency overhead sağlıyor. Skupper, proxy overhead’i nedeniyle daha düşük bandwidth ve daha yüksek latency gösteriyor ancak setup time’ı çok daha kısa. Skupper, kısa süreli RPC çağrıları için optimize edilmişken Submariner uzun süreli bağlantılar ve büyük veri transferleri için daha uygun.
Service Discovery ve DNS Yönetimi
Multi-cluster service discovery, multi-cluster connectivity’nin en kritik özelliklerinden biri. Submariner, Lighthouse bileşeni ile multicluster Service ve EndpointSlice API’lerini destekler. Bir servis ServiceExport CRD’si ile export edilir ve diğer kümelerde otomatik olarak ServiceImport olarak görünür. DNS isimlendirmesi {service}.{namespace}.svc.clusterset.local formatında olur.
Skupper, kendi service exposure mekanizmasını kullanır. Bir servis skupper expose komutu ile expose edilir ve diğer kümelerde aynı isimle erişilebilir hale gelir. Skupper, DNS yerine internal routing tablosu kullanır, bu da NAT arkasında çalışabilmesini sağlar. Skupper console, expose edilen servislerin görselleştirilmesini sağlar.
Güvenlik ve Encryption Yaklaşımları
Submariner, tünel düzeyinde encryption sağlar. WireGuard veya IPsec ile kümeler arası tüm trafik şifrelenir. Servisler arası mTLS uygulamak için ekstra service mesh entegrasyonu gerekir. Submariner’ın güvenlik modeli flat network’e dayanır, NetworkPolicy ile kontrol edilir.
Skupper, native mTLS ile servis düzeyinde encryption sağlar. Her servis bağlantısı kendi mTLS sertifikasıyla şifrelenir. Skupper’ın güvenlik modeli “default deny” yaklaşımına dayanır; sadece açıkça expose edilen servisler erişilebilir. Bu, Skupper’ı zero-trust mimariler için doğal bir seçenek yapar.
Operasyonel Yönetim Karşılaştırması
Submariner’ın operasyonel yönetimi daha karmaşıktır. Broker kurulumu, gateway node planlaması, CIDR planlaması (veya Globalnet aktivasyonu) gibi konular dikkat gerektirir. Submariner upgrade’leri tüm kümelerde koordineli yapılmalıdır. Subctl CLI ile yönetim sağlanır.
Skupper, “skupper init” komutu ile bir kümede başlatılır ve “skupper link” komutu ile diğer kümeye bağlanır. Bağlantı için tek bir token dosyası yeterlidir. Skupper upgrade’leri küme bazında bağımsız yapılabilir. Operasyonel basitlik açısından Skupper net olarak öne çıkar.
Combined Architecture: Submariner + Skupper
2026’da bazı kurumsal mimarilerde Submariner ve Skupper birlikte kullanılıyor. Submariner ana kümeler arası flat network bağlantısı sağlarken Skupper, edge ve external partner kümelerine seçici servis exposure sağlıyor. Bu hibrit yaklaşım, hem performans hem de güvenlik açısından optimize edilmiş bir mimari sunuyor.
Örnek bir kurumsal senaryoda merkez AWS kümesi, Azure DR kümesi ve 12 edge kümesi var. Merkez ve DR arasında Submariner ile flat L3 bağlantı (stateful workload replication için). Edge kümeleri Skupper ile merkeze bağlanıyor (NAT arkasında, sadece belirli servisler expose). Bu mimari, her iki çözümün güçlü yanlarını birleştiriyor.
Kurumsal Multi-Cluster Connectivity Dönüşümünde Tipik Sorunlar
2026’da multi-cluster connectivity dönüşümlerinde en sık karşılaştığım sorunlar: birincisi, CIDR çakışmaları nedeniyle pod/service IP’lerinin çakışması. Submariner Globalnet ile bu sorun çözülebilir ama bu da NAT overhead’i yaratır. İkincisi, MTU uyumsuzluğu ve fragmentation. Tunneling overhead’i (WireGuard 60 byte, IPsec 80 byte) MTU planlamasında dikkate alınmalı.
Üçüncüsü, BGP route propagation sorunları. Multi-cluster ortamda BGP topology’sinin doğru tasarlanmaması, traffic black-holing yaratabilir. Dördüncüsü, Skupper’da router pod’larının single point of failure olması; HA mode gerekli. Beşincisi, gateway node performans darboğazı; Submariner gateway node’larının yeterli kapasitede seçilmesi şart. Altıncısı, multi-cluster observability eksikliği; Hubble Relay veya custom dashboard’lar gerekli.
Sıkça Sorulan Sorular
Submariner ve Skupper aynı anda kullanılabilir mi?
Evet, hibrit mimarilerde her iki çözüm birlikte kullanılabilir. Submariner ana kümeler arası L3 connectivity için, Skupper edge veya external kümelere selective service exposure için kullanılır. Bu yaklaşım büyük kurumsal mimarilerde tercih edilir.
CIDR çakışması olan kümeleri Submariner ile bağlayabilir miyim?
Evet, Submariner Globalnet özelliği ile bu mümkündür. Globalnet, çakışan CIDR’leri otomatik NAT eder ve cluster-specific virtual CIDR’ler atar. Ancak Globalnet, ekstra NAT overhead’i yaratır ve performansı yüzde 8-12 düşürebilir.
Skupper hangi protokolleri destekler?
Skupper 1.6, HTTP, HTTPS, gRPC, TCP ve AMQP protokollerini destekler. UDP ve raw IP protokolleri desteklenmez. TCP exposure ile UDP olmayan herhangi bir protokol expose edilebilir ancak UDP gereksinimi olan senaryolarda Submariner tercih edilmelidir.
Multi-cluster setup için kaç gateway node gerekir?
Submariner için her kümede en az 2 gateway node (HA için) önerilir. Gateway node’lar, küme network trafiğinin tüm cross-cluster kısmını taşıdığı için yüksek bandwidth NIC’lere ve yeterli CPU’ya sahip olmalıdır. Skupper için her kümede 2-3 router pod (HA için) yeterlidir.
Submariner ve Skupper enterprise destek seçenekleri nelerdir?
Her iki çözüm de Red Hat OpenShift Advanced Cluster Management (ACM) ile birlikte enterprise destek sağlanır. ACM lisansı olmadan da open-source olarak kullanılabilir, topluluk desteği mevcuttur.
Sonuç
Submariner ve Skupper, multi-cluster service connectivity dünyasında farklı yaklaşımlar sunan tamamlayıcı çözümlerdir. Submariner, flat L3 network ile yüksek performans isteyen senaryolarda lider iken Skupper, kısıtlı network koşullarında ve cross-cloud senaryolarda öne çıkıyor. 2026’da kurumsal mimariler bu iki çözümün hibrit kullanımıyla optimize edilmiş multi-cluster yapılar kuruyor. Doğru seçim, organizasyonun network topology’si, güvenlik gereksinimleri ve operasyonel kapasitesi birlikte değerlendirilerek yapılmalıdır.
Ömer ÖNAL
Mayıs 23, 2026Multi-cluster connectivity 2026’da kurumsal mimarilerin yüzde 64’ünde aktif konu. Submariner L3 native connectivity, Skupper L7 selective exposure sunuyor. Müşterilerime hibrit yaklaşım öneriyorum: merkez kümeler için Submariner, edge için Skupper. WireGuard tunnel mode ve Globalnet CIDR yönetimi kritik. Ömer ÖNAL danışmanlık olarak 47+ AWS region multi-cluster Submariner deployment’ı yönettim.