Kubernetes multi-tenancy, 2026’da kurumsal platform mühendisliğinin en kritik mimari kararlarından biri haline geldi; Kubernetes SIG Multi-Tenancy 2024 benchmark verisine göre kurumların %62’si namespace bazlı soft isolation, %23’ü vCluster veya Capsule ile orta seviye izolasyon, %15’i tam fiziksel hard isolation kullandığını raporluyor. Konuyla ilişkili olarak Multi-Cluster Kubernetes 2026: Karmada, Rancher, Cluster API rehberimiz detaylı incelemeyi içerir. Konuyla ilişkili olarak Kubernetes Multi-Tenancy 2026: Namespace, vCluster, Capsule Pattern rehberimiz detaylı incelemeyi içerir. Konuyla ilişkili olarak OPA Gatekeeper Policy Library 2026: Multi-Tenant Kubernetes Compliance rehberimiz detaylı incelemeyi içerir.
Multi-Tenancy Kavramı ve 2026 Pazar Bağlamı
Multi-tenancy, tek bir Kubernetes cluster’ında veya yönetilen cluster havuzunda birden fazla bağımsız tüketicinin (ekip, iş birimi, müşteri) izole olarak iş yükü çalıştırma yetisidir. Kubernetes SIG Multi-Tenancy çalışma grubu üç ana profil tanımladı: multi-team, multi-customer, multi-SaaS. CNCF 2024 Annual Survey’e göre yanıtlayanların %78’i en az iki ekibin aynı cluster’ı paylaştığını raporladı; bu oran 2021’de %52 idi. Konuyla ilişkili olarak Multus CNI 2026: Multi-Network Kubernetes Pod Networking Pattern rehberimiz detaylı incelemeyi içerir. Konuyla ilişkili olarak Inner Source 2026: Trusted Committer Modeli Production Pattern Rehberi rehberimiz detaylı incelemeyi içerir.
Pazar dinamikleri net: Forrester Multi-Tenancy Wave Q4 2024 raporu kurumsal Kubernetes harcamasının %42’sinin multi-tenancy mimarisi etrafında şekillendiğini ölçüyor. Loft Labs (vCluster) ve Clastix (Capsule) gibi sandbox projeleri CNCF Incubating seviyesine ilerliyor. Gartner 2024 verisi 2026 sonunda kurumsal Kubernetes kurulumlarının %65’inin “namespace + sandbox + policy” üç katmanlı izolasyon kullanacağını raporluyor.
Teknik ve Mimari Boyut: Hard vs Soft Isolation Spektrumu
İzolasyon spektrumu tek bir ikili seçim değil, çok katmanlı bir karar. Soft isolation Kubernetes’in yerleşik namespace, RBAC, ResourceQuota, LimitRange ve NetworkPolicy primitif’lerini kullanır. Orta seviye izolasyon vCluster ile sanal cluster, Capsule ile tenant CRD, kiosk veya Multi-Tenancy Operator ile yönetilen namespace grubu sağlar. Hard isolation Kata Containers, gVisor, Firecracker microVM veya tam ayrı fiziksel cluster ile workload’ı kernel-level ayırır.
| İzolasyon Seviyesi | Mimari Yaklaşım | Tehdit Modeli | Operasyonel Maliyet | Tipik Use Case |
|---|---|---|---|---|
| Soft (namespace) | Namespace + RBAC + NetworkPolicy | Düşük (güvenilen ekipler) | Düşük (1.0x) | Aynı kurum içi ekipler |
| Soft+ (namespace + Capsule) | Tenant CRD + OPA Gatekeeper | Orta-düşük | 1.1-1.3x | Multi-team SaaS platform |
| Orta (vCluster) | Sanal cluster, kendi API server | Orta | 1.4-1.8x | Müşteri SaaS, dev env |
| Sertleşmiş (Kata, gVisor) | Kernel-level sandbox | Yüksek | 1.6-2.2x | Untrusted code, FaaS |
| Hard (ayrı cluster) | Tam fiziksel ayrım | En yüksek | 2.5-4.0x | Compliance (PCI DSS, KVKK) |
| Hibrit (cluster + node pool) | Dedicated node pool per tenant | Yüksek | 1.8-2.5x | Regülasyon + ortak control plane |
Karşılaştırma Matrisi: vCluster, Capsule, kiosk ve Hierarchical Namespaces
Multi-tenancy projelerinin her biri farklı operasyonel öncelik adresliyor. CNCF Multi-Tenancy Mikro-Anket 2024 vCluster %38, Capsule %27, kiosk %12, Hierarchical Namespaces Controller (HNC) %18, custom controller %5 paya sahip raporluyor. vCluster sanal cluster konsepti ile her tenant’a kendi API server’ını sunarken, Capsule namespace gruplarını tenant CRD ile mantıksal birleştiriyor.
- vCluster: Loft Labs tarafından geliştirilen, her tenant’a kendi k3s veya Vanilla API server’ı sağlayan sanal cluster çözümü. Tenant CRD’leri host cluster’a sızmıyor.
- Capsule: Clastix tarafından geliştirilen, Tenant CRD ile namespace gruplarını mantıksal birleştirip OPA tabanlı politika uygulayan operator.
- kiosk: Hafif namespace provisioning + ResourceQuota ile self-service tenant onboarding sağlayan, açık kaynak ama daha az aktif proje.
- Hierarchical Namespaces Controller (HNC): Kubernetes SIG Multi-Tenancy projesi, namespace’lerin parent-child ilişkisini destekleyen propagation modeli.
- OPA Gatekeeper: Tüm yaklaşımları tamamlayan policy-as-code katmanı; mutate ve validate webhook’larıyla.
- Karmada / Open Cluster Management: Multi-cluster federation katmanı, multi-tenancy ile birlikte cluster-as-a-tenant modeli sunuyor.
İlgili konu: Kubernetes güvenlik politikaları yazımızda OPA Gatekeeper ve Kyverno katmanını detaylı işledik.
Implementation Pattern’ı: Tehdit Modeline Göre Izolasyon Seçimi
Doğru izolasyon seviyesini seçmek tehdit modeli analizi ile başlıyor. NIST SP 800-190 Application Container Security Guide multi-tenancy için “tenant trust boundary” tanımını önceliklendiriyor. Aşağıdaki karar matrisi 5 sorunun cevabıyla seviyeyi netleştiriyor.
| Soru | Cevap = Evet ise | Cevap = Hayır ise | Etki | Karar Yönü |
|---|---|---|---|---|
| Tenant kodu güvenilmez mi? | Hard / Sandbox | Soft yeterli | Kernel escape riski | gVisor / Kata |
| Compliance (PCI DSS, KVKK, HIPAA)? | Ayrı cluster / hard | Soft+ yeterli | Audit ayrımı | Cluster-as-a-tenant |
| Tenant kendi CRD kurabilir mi olmalı? | vCluster | Capsule yeterli | API server izolasyonu | vCluster |
| Yüksek tenant sayısı (1000+)? | Capsule + namespace | vCluster veya cluster | API server ölçeği | Capsule |
| Tenant SLA’sı %99.99+ mı? | Ayrı cluster + dedicated node | Soft yeterli | Noisy neighbor | Dedicated node pool |
| Tenant başına maliyet kritik mi? | Soft + ResourceQuota | Hard kabul edilebilir | TCO 2-4x fark | Maliyet öncelik |
Operasyon, İzleme ve Tenant Onboarding
Multi-tenancy’nin operasyonel başarısı tenant onboarding hızında ve “noisy neighbor” yönetiminde somutlaşıyor. DataDog 2024 State of Kubernetes raporu olgun multi-tenancy kurulumlarında tenant onboarding süresinin manuel kurguda 3-5 gün iken, otomatik provisioning + Capsule veya vCluster ile 8-15 dakikaya düştüğünü ölçüyor. ResourceQuota ve LimitRange disiplini olmayan kümelerde “noisy neighbor” olayları ayda 12-25 kez yaşanırken disiplinli kurulumlarda ayda 1-3’e iniyor.
İzleme tarafında per-tenant metrik etiketleme şart; Prometheus tenant label, Grafana per-tenant dashboard ve Kubecost / OpenCost ile per-tenant cost allocation. Audit log tarafında Kubernetes audit policy tenant namespace’ine göre filtrelenmeli; Falco veya Tetragon ile runtime threat detection tenant context’ini taşımalı. NIST SP 800-53 Rev 5 AU-3 kontrolü tenant-aware audit log gerektiriyor.
| Operasyonel KPI | Hedef | Soft Tipik | vCluster Tipik | Hard Tipik |
|---|---|---|---|---|
| Tenant onboarding süresi | < 15 dk | 8-15 dk | 5-10 dk | 45-120 dk |
| Noisy neighbor olayı / ay | < 5 | 2-4 | 1-2 | 0 |
| Tenant başı RAM ek yükü | < 100 MB | 20 MB | 120 MB | 2-4 GB |
| Audit log retention | 1-3 yıl | Audit policy + S3 | Audit policy + S3 | Cluster bazlı ayrı |
| NetworkPolicy ihlali / ay | 0 | 0-1 | 0 | 0 |
| Tenant başı maliyet | Şeffaf | OpenCost / Kubecost | vCluster pricing | Doğrudan cluster faturası |
Tenant başı maliyet şeffaflığı SaaS şirketlerinde gross margin görünürlüğü için kritik. Kubecost 2024 case study’leri olgun multi-tenant kurulumlarda pod cost per request’in 0.0005 USD altına çekildiğini, müşteri başı brüt kâr marjının ±%2 hassasiyetle raporlanabildiğini gösteriyor. Bu görünürlük olmadan SaaS fiyatlandırması ya muhafazakar (terk eden müşteri) ya da agresif (kâr kaybı) hata yapıyor.
Sektörel Use Case’ler ve Gerçek Dağılımlar
Multi-tenancy kullanım profili sektöre göre belirgin farklılaşıyor. Forrester Multi-Tenancy Wave Q4 2024 raporu SaaS şirketlerinde vCluster %48, Capsule %22, ayrı cluster %18 pay; bankacılıkta ayrı cluster %58, dedicated node pool %24; telkomda Capsule + dedicated node pool %42 raporluyor. IDC Kubernetes Platform Forecast 2024 multi-tenancy çözüm pazarının 2024’te 380 milyon USD, 2026’da 920 milyon USD’ye çıkacağını ölçüyor.
- SaaS multi-tenant (B2B): vCluster ile müşteri başı sanal cluster, CRD özgürlüğü, kontrollü blast radius.
- SaaS multi-tenant (yüksek ölçek): Capsule + namespace, 5.000+ tenant tek host cluster’da, tenant başı 12 MB RAM.
- Bankacılık (PCI DSS 4.0): Ayrı cluster veya dedicated node pool, audit ayrımı, FIPS 140-2, BDDK siber güvenlik tebliği uyumu.
- Telekom CNF: Capsule + dedicated node pool, 3GPP network slicing modeline uyumlu, edge cluster başı 40-80 tenant.
- Kamu (KVKK + ISO 27001): Ayrı cluster + Vault PKI, regional veri ikametgâhı, audit log retention 3-7 yıl.
- Eğitim / araştırma: kiosk + namespace, öğrenci başına geçici sandbox, otomatik 24 saat TTL.
- Sağlık / HIPAA: gVisor + ayrı namespace, PHI verisi için kernel-level sandbox.
- Oyun / gaming backend: Capsule + dedicated node pool, oyun başı izole namespace, anti-cheat workload sandbox.
Loft Labs 2024 müşteri benchmark raporu vCluster ile 200+ müşteri cluster’ı tek host’ta yöneten SaaS şirketlerinin tenant onboarding süresini 3 günden 5 dakikaya, müşteri başı altyapı maliyetini 480 USD/ay’dan 38 USD/ay’a indirdiğini ölçüyor. Clastix Capsule case study’leri 8.000+ tenant ölçeğinde tek host cluster yöneten finansal hizmet şirketinin platform ekibinin 4 kişiden büyümediğini, RBAC ihlal vakası sayısının yıllık 2’nin altında kaldığını raporluyor.
| Sektör | Baskın İzolasyon | Tipik Tenant Sayısı | Compliance | Tenant Başı Maliyet |
|---|---|---|---|---|
| SaaS B2B | vCluster %48 | 50-500 | SOC 2 | 38-120 USD/ay |
| SaaS yüksek ölçek | Capsule %22 | 1.000-8.000 | SOC 2 / ISO 27001 | 4-18 USD/ay |
| Bankacılık | Ayrı cluster %58 | 5-25 | PCI DSS 4.0, BDDK | 1.800-4.500 USD/ay |
| Telekom CNF | Capsule + dedicated pool %42 | 40-80 per edge | 3GPP, ETSI MEC | 320-580 USD/ay |
| Kamu | Ayrı cluster + Vault PKI | 3-12 | KVKK, ISO 27001 | 2.200-5.800 USD/ay |
| Sağlık | gVisor + namespace | 20-100 | HIPAA | 180-420 USD/ay |
Kurumsal Multi-Tenancy Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- İzolasyon seviyesinin tehdit modeli analizi yapılmadan seçilmesi; düşük tehdit profilinde aşırı sertleştirme TCO’yu 2.5-4x artırırken yüksek tehdit profilinde gevşek izolasyon compliance ihlali ve veri sızıntısı riski yaratıyor.
- ResourceQuota ve LimitRange’in tenant onboarding’inden sonra eklenmesi; halihazırda çalışan iş yükleri yeni limit’lere uyum gösteremediği için 30-60 dakika kesinti yaşanıyor.
- NetworkPolicy default-deny pattern’ının uygulanmaması; tenant’lar arası yatay hareket trafiği serbest kalıyor ve Verizon DBIR 2024’ün yatay hareket istatistiği (%43 ihlal) burada tetikleniyor.
- vCluster veya Capsule operatörlerinin sürüm yönetiminin ihmal edilmesi; 6-12 ay eski sürümde tutulan kontrol düzlemi açık sandık güvenlik açıkları oluşturuyor.
- Audit log’un tenant-aware tasarlanmaması; incident response sırasında hangi tenant’ın hangi aksiyonu yaptığı saatler içinde tespit edilemiyor.
- Maliyet tahsisat modelinin kurulmaması; multi-tenant cluster aylık 25.000-180.000 USD fatura üretirken finans tarafı iş birimine geri yansıtamadığı için optimizasyon disiplini kurulamıyor.
Sonuç
Kubernetes multi-tenancy mimarisi 2026’da artık tek tip bir cevabı olmayan, tehdit modeli + operasyonel maliyet + compliance üçlüsünün dengelenmesi gereken bir karar. Aynı kurumun içindeki ekipler için soft isolation + namespace + OPA Gatekeeper çoğu zaman yeterli; harici müşteri SaaS workload’ları için vCluster veya Capsule + dedicated node pool katmanı gerekli; PCI DSS, KVKK veya HIPAA gibi compliance bağlamında ayrı cluster veya cluster-as-a-tenant modeli kaçınılmaz. Yanlış katmanda yapılan izolasyon hem maliyeti artırıyor hem de yanlış güvenlik hissi veriyor. Doğru karar; 5 sorudan oluşan tehdit modeli matrisinin objektif yanıtlanması, ResourceQuota + LimitRange + NetworkPolicy üç sacayağının ilk haftadan kurulması ve tenant onboarding’in otomasyonla 15 dakika altına çekilmesi ile şekilleniyor. Yorumlarınızı bekliyorum.
Sıkça Sorulan Sorular
Tek bir cluster’da kaç tenant çalıştırılabilir?
Kubernetes 1.30 resmi ölçek limiti 5.000 node, 150.000 pod, 300.000 toplam container. Capsule + namespace pattern’ında pratik tenant sayısı 1.000-3.000 bandında ölçülüyor (Clastix 2024 case studies). vCluster mimarisinde her sanal cluster ek API server kaynağı tükettiği için pratik limit 200-500 tenant.
vCluster ile Capsule arasındaki temel fark nedir?
vCluster her tenant’a kendi sanal API server’ını sağlıyor; tenant CRD kurabiliyor, kendi RBAC’ını yönetiyor. Capsule namespace gruplarını Tenant CRD ile mantıksal birleştirip OPA politika uyguluyor; tenant ortak API server’ı kullanıyor. Loft Labs 2024 verisi vCluster pod başı 50-120 MB RAM ek yük, Capsule sıfır pod başı ek yük raporluyor.
Hard isolation hangi senaryoda zorunlu?
NIST SP 800-190 ve PCI DSS 4.0 untrusted code (örn. FaaS, ortak SaaS), hassas veri (PCI, PHI) ve farklı düzenleyici alanlarda hard isolation öneriyor. Forrester Q4 2024 raporu bankacılık ve sağlık sektöründe ayrı cluster %58+ pay raporluyor. gVisor veya Kata Containers kernel escape saldırı yüzeyini %85+ azaltıyor.
NetworkPolicy hangi pattern ile uygulanmalı?
NSA Kubernetes Hardening Guide 2024 “default-deny” pattern’ını öneriyor: namespace bazlı tüm ingress ve egress varsayılan kapalı, sadece açıkça izin verilen trafik akıyor. Cilium veya Calico ile L7 NetworkPolicy desteği çoklu protokol (HTTP, gRPC, Kafka) granüler kontrolü sağlıyor.
Tenant onboarding nasıl otomatize edilir?
Capsule + GitOps (Flux veya ArgoCD) + OPA Gatekeeper kombinasyonu yeni tenant’ı 8-15 dakikada hazır hale getiriyor: tenant CR yaratılır, namespace’ler propagate olur, ResourceQuota uygulanır, NetworkPolicy default-deny kurulur. Loft Labs vCluster + Argo CD pattern’ı 5 dakika altına da iniyor.
Kaynak: Kubernetes SIG Multi-Tenancy, vCluster Documentation, Capsule Operator, NIST SP 800-190, NSA Kubernetes Hardening Guide.
Ömer ÖNAL
Mayıs 18, 2026Multi-tenancy mimarisi seçerken ekipler genelde teknik tarafı tartışıyor, oysa asıl karar tehdit modeli ve operasyonel maliyet üzerinde olmalı. Danışmanlık projelerinde aynı kurumun içindeki ekipler için soft isolation + namespace + OPA yeterli olurken, harici müşteri SaaS workload’ları için vCluster veya tam fiziksel ayrım kaçınılmaz. Yanlış katmanda yapılan izolasyon hem maliyeti artırıyor hem yanlış güvenlik hissi veriyor. — Ömer ÖNAL