Kubernetes Multi-Cluster: Karmada, ClusterAPI ve Federation 2026

Multi-cluster Kubernetes, tek bir kontrol düzlemini birden fazla Kubernetes cluster’ı üzerinde koordine ederek workload dağıtımı, disaster recovery ve coğrafi yakınlık sağlama pratiğidir. CNCF 2025 Annual Survey’e göre üretim ortamında Kubernetes kullanan organizasyonların yaklaşık %62’si artık birden fazla cluster işletiyor; bu oran 2022’deki %29’a göre iki katından fazla bir artış. Cevap net: 2026’da multi-cluster artık niş bir mimari değil, ölçeklenen her platform ekibinin karşılaştığı varsayılan durum. Karmada, ClusterAPI ve federation pattern’leri bu karmaşıklığı yönetilebilir kılan üç ana araç.

Bu yazı; Karmada’nın propagation policy modelini, Cluster API’nin (CAPI) declarative cluster lifecycle yaklaşımını ve KubeFed’in neden geride kaldığını gerçek sayılarla karşılaştırıyor. Workload placement, identity federation, network ve cost overhead başlıklarında karar çerçevesi sunuyor. Yazıyı bitirdiğinizde hangi senaryoda hangi aracı seçeceğinizi, hangi tuzaklara dikkat edeceğinizi ve mevcut tek cluster’dan multi-cluster’a geçişin gerçek maliyetini biliyor olacaksınız.

Multi-Cluster’a Neden Geçiliyor: Tetikleyici Senaryolar

Tek cluster modeli belirli sınırlara ulaşana kadar oldukça verimli çalışır. Kubernetes resmi dokümantasyonunda large cluster considerations sayfasında belirtilen üst sınırlar: cluster başına 5000 node, 150.000 pod ve 300.000 toplam container. Pratikte 1000 node’un üzerinde control plane’in etcd write latency’si artmaya, API server throttling görünür hale gelmeye başlıyor. Multi-cluster kararına yol açan tetikleyiciler genelde tek bir teknik limit değil, bir kombinasyon.

Tetikleyici	Tek Cluster Sınırı	Multi-Cluster Çözümü	Tipik Sektör
Coğrafi gecikme	200ms+ cross-region RTT	Bölgesel cluster + global LB	E-ticaret, gaming
Blast radius	Tek control plane = tek hata	Bağımsız failure domain	Finans, sağlık
Regülasyon (GDPR, KVKK)	Veri yerelleştirme zorluğu	Region-bound cluster	Bankacılık, kamu
Tenant izolasyonu	Namespace yetersiz	Tenant başına cluster	SaaS, B2B platform
Cluster upgrade riski	1.x → 1.y rolling risk	Blue-green cluster swap	Mission-critical SLA
Multi-cloud taahhüdü	Vendor lock-in	EKS + GKE + AKS karışık	Enterprise IT

Bu tablo, multi-cluster’ı “çünkü büyüğüz” diye değil, somut bir kısıtla çözüldüğü için tercih edilen bir mimari olarak konumlandırır. Stack Overflow Developer Survey 2025’te container orchestration araçları arasında Kubernetes hâlâ %59 ile birinci ve ankete katılan platform mühendislerinin %41’i “birden fazla cluster” yönetmekten bahsetti. Geçiş kararını verirken sorulması gereken kritik soru: tek bir node havuzunu büyütmek mi yoksa cluster sayısını artırmak mı daha az operasyonel yük getirir.

Kararı netleştirmek için dört kriter takip edin: gecikme (data plane locality), izolasyon (security blast radius), upgrade stratejisi (downtime toleransı) ve maliyet (control plane çoğaltma overhead’i). Bu kriterler aynı anda iki veya üçünü tetikliyorsa multi-cluster artık opsiyonel değil zorunluluktur. Üç temel pattern doğdu: replicated (her cluster aynı workload), partitioned (workload shard’lara bölünmüş) ve hybrid (kontrol replicated, data partitioned).

Karmada: Propagation Policy Tabanlı Workload Dağıtımı

Karmada (Kubernetes Armada), Huawei tarafından 2021’de açıklanmış, CNCF Incubating projesidir. Kasım 2025 itibarıyla GitHub deposunda yaklaşık 4.7K star ve 250+ contributor’a sahip. Karmada’nın temel iddiası: mevcut Kubernetes API’lerini değiştirmeden, bir host cluster’a deploy ettiğiniz Deployment, Service veya CustomResource’u PropagationPolicy aracılığıyla üye cluster’lara dağıtır. Kullanıcı sadece “şu workload şu cluster setine gitsin, ağırlığı şöyle olsun” der.

Karmada mimarisi üç katmana oturur. karmada-apiserver: kendi etcd’si olan, kullanıcıların yazdığı kontrol düzlemi. karmada-controller-manager: ResourceBinding ve Work nesnelerini üretir. karmada-scheduler: cluster seçimini yapar — replica-based, weight-based, affinity tabanlı stratejilerle. Üye cluster’lara karmada-agent (pull) veya host’tan execution controller (push) yoluyla aktarım yapılır. Pull modu sınırlı network erişimi olan edge cluster’lar için daha uygundur.

Bileşen	Sorumluluk	Çalıştığı Yer	Tipik Ölçek
karmada-apiserver	Federated API endpoint	Host cluster	2-3 replica
karmada-controller-manager	Binding üretimi	Host cluster	1-2 replica
karmada-scheduler	Cluster seçimi	Host cluster	1 leader + standby
karmada-agent	Pull mode senkron	Üye cluster	1 per cluster
karmada-webhook	Validation/mutation	Host cluster	2 replica
karmada-aggregated-apiserver	Üye cluster proxy	Host cluster	1-2 replica

Tipik bir PropagationPolicy şöyle çalışır: spec.placement.clusterAffinity.clusterNames: [eks-eu-west-1, gke-eu-west-3] ile hedef cluster’lar seçilir, spec.placement.replicaScheduling.replicaSchedulingType: Divided ile 10 replica’lık bir Deployment iki cluster arasında bölünür. OverridePolicy ise cluster bazlı imaj registry, env değişkeni veya resource limit farklarını yönetir. Bu, “aynı manifest farklı bölgede farklı ayarla” senaryosunu tek bir GitOps repo’sundan yönetmeyi mümkün kılar. Tam GitOps entegrasyonu için GitOps Kubernetes yaklaşımı Karmada API’sini Argo CD’nin yönettiği bir kaynak olarak kullanır.

Karmada’nın güçlü yanları: vendor-neutral, mevcut workload’u değiştirmeden adopt edilebilir, geniş resource desteği (CRD’ler dahil). Zayıf yanları: identity federation ve cross-cluster service discovery hâlâ Submariner veya MCS-API gibi ek bileşenler gerektirir. Etcd büyüklüğü host cluster’da artar — 50+ üye cluster için karmada-apiserver’ın etcd’sini ayrı, SSD’li bir node grubunda izole etmek gerekir.

• Avantaj: Native Kubernetes API uyumu, mevcut chart/Operator’ları değiştirmeden federe eder.
• Dezavantaj: Cluster lifecycle (provisioning) yönetmez, sadece workload dağıtır.
• Ne zaman seç: Cluster’lar zaten var ve global workload placement gerekiyorsa.
• Tipik kullanım: Multi-region active-active deployment, edge-cloud hybrid placement.

Cluster API (CAPI): Cluster Lifecycle Declarative Yönetimi

Cluster API (CAPI), Kubernetes SIG-Cluster-Lifecycle altında geliştirilen ve cluster’ı kendi başına bir Kubernetes resource olarak modelleyen projedir. Resmi dokümantasyonuna cluster-api.sigs.k8s.io üzerinden ulaşılabilir. Temel fikir: Cluster, MachineDeployment, KubeadmControlPlane gibi CRD’lerle bir management cluster üzerinden N adet workload cluster oluşturulur, upgrade edilir ve silinir. AWS, Azure, GCP, vSphere, OpenStack, Equinix Metal için resmi providers mevcut.

CAPI’nin operasyonel etkisi büyüktür çünkü cluster creation’ı bir kubectl apply’a indirir. Bir Cluster manifest’inde controlPlaneRef ile KubeadmControlPlane, infrastructureRef ile AWSCluster veya AzureCluster referanslanır. Sonrasında MachineDeployment ile worker node havuzları autoscaler entegre şekilde tanımlanır. CAPI’nin sağladığı declarative state, drift detection ile uyumludur: cloud konsolda manuel değişen bir instance, controller tarafından reconcile edilir.

Provider	Olgunluk (2026)	Yönetilen Control Plane Desteği	Tipik Provisioning Süresi
CAPA (AWS)	v2 GA	EKS, kubeadm	8-12 dakika
CAPZ (Azure)	v1 GA	AKS, kubeadm	10-14 dakika
CAPG (GCP)	v1 Beta	GKE, kubeadm	9-13 dakika
CAPV (vSphere)	v1 GA	kubeadm	15-20 dakika
CAPO (OpenStack)	v1 GA	kubeadm	12-18 dakika
CAPD (Docker)	Dev/test	kubeadm	2-3 dakika

CAPI’nin avantajı, Karmada’nın eksiğini doldurmasıdır: Karmada workload’u federe eder ama cluster’ı yaratmaz; CAPI cluster’ı yaratır ama workload federation yapmaz. İkisi birlikte kullanıldığında end-to-end multi-cluster lifecycle elde edilir. Yeni bir region’a açılım kararı geldiğinde sıra şu olur: CAPI ile yeni cluster sağlanır → karmada-agent deploy edilir → ClusterRegistry’e eklenir → PropagationPolicy bu yeni cluster’ı hedef listesine dahil eder. Toplam süre bölgeye göre 15-25 dakikadır.

ClusterClass CAPI v1.5+’ta tanıtılan ve template tabanlı cluster üretimini sağlayan bir abstraction’dır. Tek bir ClusterClass tanımıyla “küçük dev cluster”, “orta staging”, “büyük prod” varyasyonları üretebilirsiniz. Bu pattern özellikle SaaS platformlarda tenant-per-cluster modelinde 100+ cluster’ı standart şekilde yönetmek için kritiktir. Cluster oluşturma temel Kubernetes yönetimi bilgisinin üzerine inşa olur ve control plane bileşenlerinin doğru anlaşılmasını gerektirir.

KubeFed v2 Neden Geride Kaldı?

Kubernetes Federation v2 (KubeFed), multi-cluster çözümlerinin ilk resmi denemesiydi. 2018’de duyurulmuş ve uzun süre referans alınmış olsa da, 2023’te SIG-Multicluster tarafından arşivlendi. Sebep tek değil: FederatedDeployment, FederatedService gibi her resource için ayrı federe tip üretmek, mevcut Helm chart’larla uyumsuzdu. Override sistemi karmaşıktı, status propagation patchwork halinde çalışıyordu, identity federation eksikti.

Karmada bu derslerden öğrenildi: Karmada federe tip üretmez, mevcut native tipleri PropagationPolicy ile dağıtır. Bu sayede Helm chart yazan ekipler hiçbir değişiklik yapmadan workload’larını federe edebilir. Bugün KubeFed referansına dokümantasyonda hâlâ rastlasanız da, yeni greenfield kurulumlarda kullanmak production karşılığı olmayan bir karar olur.

1. Federe tip patlaması: Her resource için FederatedX tipi → CRD katlanması.
2. Helm uyumsuzluğu: Mevcut chart’lar manuel federate edilmeli, otomatik dönüşüm yok.
3. Override karmaşıklığı: JSONPath tabanlı override sistemi okunabilirliği düşürdü.
4. Status reconciliation: Member cluster status’un federate edilmesi tutarsızdı.
5. Topluluk momentumu: SIG aktivitesi 2022’den itibaren Karmada ve Open Cluster Management’a kaydı.

Multi-Cluster Service Discovery ve Network

Multi-cluster mimarisinin en gizli zorluğu service discovery ve network’tür. Workload’u dağıtmak kolay; bir cluster’daki pod’un başka bir cluster’daki Service’i transparent bulması zor. Bu sorunun standardize edilmesi için MCS-API (Multi-Cluster Services API), SIG-Multicluster KEP-1645 ile yayınlandı. ServiceExport ve ServiceImport CRD’leri tanımlar — bir cluster bir Service’i export eder, diğer cluster bunu otomatik bulur.

Çözüm	Yaklaşım	MCS-API Uyumu	Tipik Cross-Cluster Latency
Submariner	IPsec tünel + service export	Evet	3-8 ms (aynı region)
Cilium Cluster Mesh	eBPF + WireGuard tünel	Evet	1-4 ms
Istio Multi-Primary	East-west gateway mTLS	Kısmen	2-6 ms
Linkerd Multi-Cluster	Gateway + mirror service	Evet	2-5 ms
AWS VPC Lattice	Managed service network	Hayır	1-3 ms

Cilium Cluster Mesh, eBPF tabanlı veri düzlemi sayesinde proxy overhead’i olmadan cross-cluster pod-to-pod iletişim sağlar. Aynı VPC’de iki cluster için tipik p99 latency 1-2 ms ek; cross-region için ise temel WAN gecikmesi (örn. eu-west-1 ↔ eu-central-1 için yaklaşık 18 ms) baz alınır. Network Policy üzerine inşa edilmiş Cilium Cluster Mesh resmi dokümantasyonu aynı policy modelinin cluster mesh içinde nasıl uygulandığını ayrıntılı açıklar.

Service mesh seçimi multi-cluster’da kritiktir. Istio’nun multi-primary modu her cluster’ın kendi control plane’ine sahip olmasına izin verir; failure isolation kuvvetlidir ama operasyonel yük artar. Linkerd’in multi-cluster yaklaşımı gateway tabanlı, daha basit ama feature set daha dar. Karar verirken Service Mesh karşılaştırmasını cluster sayısı ve operasyonel olgunluğa göre yapın. Identity federation için SPIFFE/SPIRE kullanılması, mTLS sertifikalarının cluster’lar arası güvenle yayılmasını sağlar.

Workload Yerleştirme Stratejileri ve Trade-Off’lar

Multi-cluster pattern’leri üç eksende karar gerektirir: placement (hangi cluster), replication (replica sayısı nasıl bölünür), failover (cluster düşerse ne olur). Karmada’nın PropagationPolicy’si bu üçüne karşılık static, weighted ve dynamic stratejileri sunar. Açık Cluster Management (OCM) projesi de placement decision API’siyle benzer mantığı uygular.

• Static placement: Cluster listesi sabit. Avantaj: deterministik. Dezavantaj: yeni cluster eklenince manuel güncelleme.
• Weighted placement: Cluster başına 0-100 ağırlık. Avantaj: traffic shaping. Dezavantaj: replica gerçek kapasiteyi yansıtmayabilir.
• Resource-aware placement: Cluster’ın boş CPU/memory’sine göre. Avantaj: gerçek kapasite. Dezavantaj: bin-packing değişkenliği.
• Affinity-based placement: Label selector ile cluster tag’leri. Avantaj: zone/region awareness. Dezavantaj: yanlış label, sessiz hata.
• Failover placement: Cluster Unreachable olduğunda replica diğerlerine kayar. Avantaj: otomatik DR. Dezavantaj: cascading failure riski.

Replica scheduling tipi seçimi de eşit önemde. Karmada’da Duplicated her cluster’da aynı replica sayısı yaratır — active-active classic DR. Divided ise toplam replica’yı paylaştırır, weighted strateji ile birleşir. Trade-off net: Duplicated maliyetli ama hızlı failover sağlar; Divided maliyet-verimli ama tam cluster kaybında SLO etkilenir. Stateful workload’larda Divided neredeyse her zaman yanlış seçimdir çünkü data locality’yi bozar.

Veritabanı, Kafka, Redis gibi stateful sistemler için multi-cluster yaklaşımı farklıdır. Bunlar genelde tek cluster içinde tutulur ve replication kendi katmanlarında (Postgres streaming, Kafka MirrorMaker 2, Redis CRDT) yapılır. Workload katmanı federe edilse de data katmanı federe edilmez. Bu ayrım göz ardı edildiğinde split-brain ve veri kaybı kaçınılmazdır.

Maliyet ve Operasyonel Overhead Gerçekçi Hesabı

Multi-cluster, bedavaya gelmez. Her ek cluster için control plane, observability, network ve insan yükü artar. Yönetilen Kubernetes (EKS, AKS, GKE) için control plane fiyatı tipik olarak saatlik 0.10 USD civarındadır; bu yıllık cluster başına yaklaşık 876 USD demektir. 20 cluster’lık bir filo sadece control plane’de 17.500 USD’lik bir taban maliyet anlamına gelir — workload’a hiç yer ayırmadan.

Kalem	Tek Cluster	5 Cluster	20 Cluster	Not
Yönetilen control plane ($/yıl)	~876	~4.380	~17.520	EKS/AKS/GKE ortalaması
Logging artışı (GB/ay)	500	2.000	7.000	kube-system + app log
Cross-region network ($/ay)	0	300-800	1.500-4.000	data egress + tünel
SRE FTE	0.3	0.6	1.5	otomasyon olgunluğuna göre
CI/CD runner saat	baseline	+%40	+%150	çoklu hedef deploy

Maliyet sürprizinin en büyük kaynağı egress’tir. AWS’de cross-AZ replikasyon 0.01 USD/GB, cross-region 0.02-0.09 USD/GB. Bir cluster mesh’in günlük 200 GB cross-region trafik yaratması yıllık 1.500-6.500 USD ek demektir. Multi-Cloud Stratejisi hedeflerken bu hidden egress kalemini baştan modellemek gerekir. FinOps Bulut Maliyet disiplini multi-cluster ortamlarda tek cluster’a göre 2-3 kat daha kritik hale gelir; cluster başına cost allocation tag standardı olmadan görünürlük kaybedilir.

Otomasyon olgunluğu, FTE ihtiyacını belirleyen en büyük kaldıraçtır. GitOps ile CAPI + Karmada + Argo CD birleşimi olgun bir ekip için 20 cluster’ı 1.5 FTE ile yönetilebilir kılarken, scripts/manual karışımı bir setup’ta aynı sayı 4-5 FTE gerektirebilir. McKinsey’in 2024 cloud productivity araştırmasında platform mühendisliğine yatırım yapan organizasyonların developer velocity’sinin %35 daha yüksek olduğu raporlanıyor; bu özellikle multi-cluster’da hissedilir. Bu süreç tasarımı için Ömer Önal’ın platform mühendisliği danışmanlığında uyguladığı bir matriks vardır: cluster sayısı × workload kritikliği × team olgunluğu üzerinden FTE ve maliyet projeksiyonu hızlıca çıkarılabilir.

Identity, Secret ve Policy Federation

Multi-cluster’da workload’u federe etmek teknik olarak kolay kısımdır; identity ve secret’ı federe etmek gerçek zorluktur. RBAC her cluster’da bağımsızdır — kullanıcı bir cluster’da admin olabilirken diğerinde view bile olmayabilir. Bu durumun çözümü için organizasyonlar üç pattern’den birini seçer: OIDC merkezi IdP (Okta, Azure AD), SPIFFE/SPIRE workload identity ve external secret operatörleri.

Pattern	Çözdüğü Sorun	Olgunluk	Tipik Entegrasyon Süresi
OIDC + IdP	İnsan kimliği	Yüksek	3-5 gün
SPIFFE/SPIRE	Workload kimliği (mTLS)	Orta-Yüksek	2-4 hafta
External Secrets Operator	Vault/SSM/KMS federation	Yüksek	1-2 hafta
Kyverno + ClusterPolicy	Policy as Code dağıtımı	Yüksek	1-3 hafta
OPA Gatekeeper + Karmada	Federate edilmiş policy	Yüksek	2-3 hafta

Secret federation’da en yaygın hata, Secret kaynağını doğrudan Karmada üzerinden propagate etmektir. Bu, etcd snapshot’larında secret’ın birden fazla yerde tutulmasına yol açar — saldırı yüzeyi büyür. Doğru pattern: secret’ı her cluster’ın kendi Container Güvenliği standardına uygun şekilde External Secrets Operator ile Vault, AWS Secrets Manager veya GCP Secret Manager’dan çekmesidir. Karmada sadece ExternalSecret CRD’sini propagate eder, gerçek secret değeri hiçbir zaman karmada-apiserver’a girmez. DevSecOps Shift-Left prensipleri burada da CI aşamasında policy validation ile devreye girer.

Federated identity stratejisi seçerken aşağıdaki sıralama production setup için doğrulanmış bir pattern’dir:

1. Önce IdP merkezi: Okta veya Azure AD üzerinden tüm cluster’lara OIDC ile single sign-on; insan erişimi konsolide edilir.
2. Sonra workload identity: SPIFFE/SPIRE devreye alınır, mTLS sertifikaları cluster sınırının ötesine güvenle çıkar.
3. Üçüncü olarak secret federation: External Secrets Operator ile Vault/SSM/KMS arasında köprü; hiçbir gerçek değer Karmada’ya girmez.
4. Son olarak policy federation: Kyverno ClusterPolicy veya OPA Gatekeeper ConstraintTemplate Karmada üzerinden tüm cluster’lara dağıtılır.
5. Doğrulama: Her katmanda admission test pod’u ile end-to-end smoke test koşulur; sessiz hata bırakılmaz.

Policy federation için Kyverno’nun ClusterPolicy’si veya OPA Gatekeeper’ın ConstraintTemplate’leri Karmada PropagationPolicy ile dağıtılır. Bu, “tüm cluster’larda non-root container zorunlu”, “ImagePullPolicy: Always olmalı”, “resource limit olmadan deploy yasak” gibi guardrail’lerin tek kaynaktan uygulanmasını sağlar. CI/CD pipeline aşamasında preflight kontrol için Kyverno resmi rehberi referans alınır, runtime’da admission kontrolü ile katmanlı güvenlik kurulur.

Sıkça Sorulan Sorular (SSS)

Sonuç

Multi-cluster Kubernetes 2026’da artık üst düzey bir mimari değil, belirli bir ölçeğin üzerinde her platform ekibinin yüzleştiği varsayılan durum. Karmada PropagationPolicy ile workload federation’ı, ClusterAPI declarative cluster lifecycle’ı, MCS-API ve Cilium Cluster Mesh service discovery’yi standardize ediyor. KubeFed’in arşivlenmesi ve Karmada + CAPI + OCM ekosisteminin olgunlaşması, multi-cluster’ı niş bir tercih olmaktan çıkardı.

Doğru karar çerçevesi şu sırayla işler: Önce somut tetikleyici tanımlanır (latency, blast radius, regülasyon, tenant izolasyonu). Sonra control plane stratejisi (CAPI veya yönetilen kubernetes) seçilir. Üçüncü olarak workload federation katmanı (Karmada veya OCM) eklenir. Network ve identity son katmanda (Cilium/Submariner + SPIFFE/SPIRE + External Secrets) tamamlanır. Bu sırayı atlayan veya katmanları aynı anda devreye almaya çalışan ekipler 6-12 ay sonra “neden basit bir deploy bu kadar karmaşık” sorusuyla yüzleşir.

Ekibinizin tek cluster’dan multi-cluster’a geçiş yol haritasını hazırlamak, hangi pattern’in cost/operasyonel yük dengesinde sizin için doğru olduğuna karar vermek için omeronal.com/iletisim/ üzerinden iletişime geçebilir, mevcut platform mimarisi üzerinden somut bir hedef topolojiye geçiş planı çıkarabilirsiniz. Platform mühendisliği yatırımının ROI’si multi-cluster’da en hızlı görünür çünkü her ek cluster manuel yönetildiğinde maliyeti exponential, otomatize edildiğinde lineer artar.