İçindekiler

• İçindekiler
  • Kubernetes’de Multi-Tenancy (Çoklu Kiracılık)
  • Multi-Tenancy Modelleri
    • Soft Multi-Tenancy - Shared Kubernetes (Paylaşımlı Kubernetes)
      • Paylaşımlı Kubernetes Cluster’ları İçin İzolasyon Yöntemleri
      • Kaynak Yönetimi
      • Güvenlik Uygulamaları
    • Hard Multi-Tenancy
      • Ayrı Kubernetes Cluster
      • Ayrı Virtual Control Plane
      • Fiziksel İzolasyon
  • Multi-Cluster (Çoklu Cluster) Stratejileri
  • Multi-Tenant Kubernetes’in Faydaları
  • Riskler and Zorluklar
  • Yaygın Hatalar ve Kaçınma Yolları
  • Sonuç
  • Kaynakça

Kubernetes’de Multi-Tenancy (Çoklu Kiracılık)

Multi-tenancy, Kubernetes’te birden fazla tenant’ın (takımlar, departmanlar, müşteriler veya farklı iş yüklerinin) aynı Kubernetes cluster’ı (küme) paylaşması anlamına gelir. Bu yaklaşım, kaynakların daha verimli kullanılmasını ve maliyetlerin optimize edilmesini sağlar. Ancak, tenant’ların birbirinden izole edilmesi, güvenlik sınırlarının korunması ve kaynakların adil bir şekilde dağıtılması büyük önem taşır.

Kubernetes, konteynerize edilmiş iş yüklerini yönetmek için güçlü bir platform olsa da varsayılan olarak multi-tenancy özelliği sunmaz. Bu nedenle çeşitli ek yapılandırmalar ve stratejiler gerekir [1].

Kubernetes, bu ihtiyaçları karşılamak için Namespace, RBAC (Rol Tabanlı Erişim Kontrolü), ResourceQuota (Kaynak Kotası) ve NetworkPolicy (Güvenlik Politikası) gibi araçlar sunar. Bu sayede, farklı tenant’lar aynı altyapıyı kullanırken birbirlerini etkilemeden güvenli ve sorunsuz bir şekilde çalışabilir.

Multi-Tenancy Modelleri

Kubernetes’te multi-tenancy modelleri, tenant’lar arasındaki izolasyon seviyesine göre sınıflandırılabilir. Bu modeller, farklı kullanım senaryolarına uygun şekilde tasarlanmıştır [2].

Soft Multi-Tenancy - Shared Kubernetes (Paylaşımlı Kubernetes)

Birden fazla tenant, mantıksal izolasyon mekanizmaları (Namespace, RBAC, NetworkPolicy, ResourceQuota) kullanılarak aynı cluster’ı paylaşır. Maliyet açısından verimli, yönetim açısından daha kolaydır.

• Aynı şirket içindeki farklı ekipler, aynı cluster’da mantıksal olarak izole edilmiş namespace’lerde çalışabilirler.

Paylaşımlı Kubernetes Cluster’ları İçin İzolasyon Yöntemleri

Paylaşımlı Kubernetes cluster’larında izolasyon, farklı tenant’lar arasında kaynakların güvenli ve etkili bir şekilde ayrılmasını sağlamak için kritik bir konudur. Bazı temel izolasyon mekanizmaları bu konuda öne çıkar:

Namespace İzolasyonu

Kubernetes’te Namespace, tek bir cluster içinde API kaynaklarını mantıksal olarak izole etmek için kullanılan bir mekanizmadır. Multi-Tenant ortamlarda, her tenant için ayrı bir namespace oluşturmak, uygulamalar ve kaynaklar arasında net bir ayrım sağlar. Daha iyi bir izolasyon için her iş yükünün kendi namespace’inde çalıştırılması önerilir. Bu yaklaşım, her iş yükünün bağımsız kimlik ve güvenlik policy’leriyle yönetilmesine olanak tanır.

Namespace izolasyonu, sadece namespace oluşturmakla tamamlanmaz. Güvenli bir multi-tenant yapı için yapılandırılması gereken birçok bileşen bulunmaktadır.

Ağ İzolasyonu

Kubernetes’te varsayılan olarak tüm pod’lar birbirleriyle doğrudan iletişim kurabilir ve ağ trafiği şifrelenmemiştir. Bu durum çeşitli güvenlik risklerine yol açabilir.

Pod’lar arasındaki ağ trafiğini denetlemek için NetworkPolicy kaynakları kullanılır. Namespace etiketleri veya IP aralıkları kullanılarak pod’lar arasındaki iletişim kısıtlanabilir.

Varsayılan olarak pod’dan pod’a (pod-to-pod) iletişimi engelleyen (deny-all) bir policy oluşturulması önerilir. DNS sorgularına izin vermek için özel bir kural eklenmelidir. Bu policy’nin ardından tenant içi trafiğe izin veren policy’ler oluşturulabilir.

Gelişmiş bir ağ izolasyonu sağlamak, NetworkPolicy kullanımının ötesine geçerek daha ileri düzey çözümler gerektirir.

• CNI (Container Network Interface) Eklentileri: NetworkPolicy kullanımı için CNI eklentisinin desteklemesi gerekir. Gelişmiş ağ izolasyonu için uygun CNI çözümleri tercih edilmelidir. Cilium gibi CNI eklentileri, L4 (TCP/UDP) seviyesinin ötesine geçerek DNS, HTTP, gRPC gibi L7 seviyesinde detaylı kontrol imkânı sunar.

• Pod Güvenlik Standartları (PSS) & Security Context: Tenant’ların izinsiz işlem yapmasını önlemek (Root Container vb.) için güvenlik seviyeleri belirlenmelidir.

Node İzolasyonu

Node izolasyonu, tenant iş yüklerini birbirinden fiziksel olarak ayırmak için kullanılan bir yöntemdir. Node izolasyonu ile, her tenant’a özel bir node grubu (node pool) tahsis edilir, böylece tenant pod’larının farklı tenant’lara ait pod’larla aynı node üzerinde çalışması engellenir.

Bu sayede;

• Aynı node üzerinde birden fazla tenant’ın pod’u olmayacağı için, bir tenant’ın yoğun kaynak kullanımı diğerlerini etkilemez.
• Container’larda oluşabilecek güvenlik sızıntıları başka tenant’ları daha az etkiler.

Kubernetes’te Node izolasyonu, Taints ve Tolerations, Node Affinity ve Node Selectors gibi yöntemlerle sağlanabilir.

Depolama İzolasyonu

Kubernetes, iş yükleri için farklı türlerde kalıcı depolama (Persistent Storage) seçenekleri sunar. Güvenlik ve veri izolasyonu açısından çeşitlli önlemler alınabilir:

• Dinamik Provizyonlama ile her tenant için ayrı depolama kaynakları oluşturulabilir.

• Node kaynaklarını kullanan volume tipleri (hostPath, emptyDir) kullanılmamalıdır, çünkü bu tip volume’ler tenant’lar arasında izolasyon zafiyeti yaratabilir.

• Tenant bazlı StorageClass oluşturulabilir. Her StorageClass için yedekleme stratejileri ve özel policy’ler tanımlanabilir. PVC (PersistentVolumeClaim) nesneleri namespaced (namespace kapsamlı), PV (PersistentVolume) nesneleri ise cluster-wide (cluster kapsamlı) bir kaynaktır. Bu yüzden, tenant bazlı depolama izolasyonu sağlamak için her tenant’ın kendi PVC’leri olmalı ve yalnızca ilgili StorageClass’a bağlanmalıdır. Paylaşımlı bir StorageClass kullanılıyorsa, PV’lerin farklı tenant’lar tarafından yeniden kullanılmasını önlemek için ReclaimPolicy=Delete olarak ayarlanmalıdır.

Kaynak Yönetimi

Multi-tenant bir ortamda, tenant iş yüklerinin kaynak kullanımını yönetmek için ResourceQuota kullanılabilir. Özellikle birden fazla ekibin Kubernetes API’sine erişimi olduğu kullanım senaryolarında, kaynak kotaları sayesinde bir tenant’ın oluşturabileceği API kaynaklarının sayısı (Pod, ConfigMap vb.) sınırlanabilir. Nesne sayısındaki bu sınırlar, adil bir paylaşım sağlar ve “gürültülü komşu” (noisy neighbor) sorunlarının etkisini en aza indirmeye yardımcı olur.

ResourceQuota, namespaced nesnelerdir, namespace bazında uygulanır. Bir namespace’e kota uygulandığında, Kubernetes her bir container için Resource “Requests” ve “Limits” belirtilmesini zorunlu kılar. Limits, bir container’ın tüketebileceği kaynak miktarının üst sınırını belirler. Yapılandırılan sınırları aşmaya çalışan container’lar, kaynak türüne bağlı olarak ya kısıtlanır (CPU throttling) ya da sonlandırılır (OOMKilled) [3].

Resource Requests, container’ın ihtiyaç duyduğu minimum kaynak miktarıdır. Bu miktar garanti edilir. Her container’a talep edilen miktar garanti edilir.

Kaynak kotalarının etkili bir şekilde yönetilebilmesi için uygulamaların gerçek kaynak kullanımının izlenmesi ve buna uygun limit değerlerinin belirlenmesi kritik öneme sahiptir; aksi halde ya kaynak israfı ya da performans sorunları yaşanabilir.

Güvenlik Uygulamaları

Multi-tenant Kubernetes ortamlarında güvenliği sağlamak, hem tenant’ların hem de cluster’ın bütünlüğünü korumak için kritiktir. Bu tür ortamlarda uygulanabilecek en iyi güvenlik pratiklerini ele alırsak;

• Rol Tabanlı Erişim Kontrolü (Role-Based Access Control): RBAC, tenant’lara yönelik detaylı (fine-grained) izinlerin tanımlanmasını sağlar. Her tenant’a yalnızca ihtiyaç duyduğu kaynaklara erişim vererek, gereksiz yetkilendirmelerin önüne geçilir. Bu durum, hem güvenliği artırır hem de tenant’lar arası yetki çakışmalarını önler.

• Pod Güvenlik Standartları: PSS, Pod seviyesinde güvenlik policy’lerinin uygulanması, iş yüklerinin güvenli bir şekilde çalışmasını garanti eder. Bu standartlar sayesinde, privileged (ayrıcalıklı) container’ların çalışması engellenebilir veya belirli güvenlik gereksinimleri zorunlu hale getirilebilir [4].

• Secret Yönetimi: Her tenant’a özgü hassas verilerin (API Key, TLS Key vb.) güvenli bir şekilde yönetilmesi büyük önem taşır. Bu amaçla Vault, Sealed Secrets gibi araçlar kullanılabilir.

• Audit Logging (Denetim Kaydı): Erişimlerin izlenmesi ve kaydedilmesi sorun giderme süreçlerini kolaylaştırmak için kritik bir adımdır. Audit log’ları sayesinde, hangi tenant’ın ne zaman ve hangi kaynağa eriştiği takip edilebilir.

• Kyverno veya OPA (Open Policy Agent): Güvenlik policy’lerini tanımlamak ve uygulamak için kullanılır. Örneğin, belirli pod’ların yalnızca onaylı imajları kullanmasını zorunlu kılabilir.

Şekil 1’de farklı takımlar için örnek multi-tenancy kullanımları gösterilmiştir.

Hard Multi-Tenancy

Hard multi-tenancy, Kubernetes ortamlarında tenant’lar arasında maksimum izolasyon gerektiren senaryolar için tasarlanmıştır. Her tenant için ayrı bir cluster verilmesi veya virtual control plane kullanımı yaygındır.

Ayrı Kubernetes Cluster

Her tenant’a özel ayrı bir cluster verildiği tenant modelidir. Tenant’lar cluster-wide kaynakların (CRD vb.) farklı sürümlerine sahip olabilirler ve Kubernetes ana bileşenlerinin en yüksek düzeyde güvenlik ve izolasyonu sağlanır. Bir tenant cluster’ı (workload/işyükü cluster’ı) bir tenant’a atanır ve tenant’lar cluster kaynakları üzerinde tam kontrole sahip olur.

Bu cluster’lar, fiziksel olarak tamamen farklı sunuculara kurulabileceği gibi (Fiziksel İzolasyon), aynı fiziksel sunucu üzerinde sanallaştırma teknolojileri kullanılarak da ayrıştırılabilir. Bu yaklaşım, donanım kaynaklarının daha verimli kullanılmasına olanak tanırken, tenant’lar arasında mantıksal izolasyon sağlar.

Tenant cluster’ları, Cluster API (CAPI) gibi projelerle sağlanabilir. Burada bir “Management Cluster”, birden fazla tenant cluster’ını sağlamak için kullanılır. Management Cluster, CAPI bileşenlerini barındırır ve her tenant cluster’ının yaşam döngüsünü kontrol eder.

Merkezi bir platform ekibi kurularak, güvenlik ve izleme gibi ek hizmetlerin yönetiminden ve cluster yaşam döngüsünden (güncelleme, yükseltme, ölçekleme) sorumlu olması hedeflenebilir.

Ayrı Virtual Control Plane

Virtual Control Plane, Kubernetes’te multi-tenancy için namespace tabanlı modelin ötesine geçen yenilikçi bir yaklaşımdır. Bu modelde her tenant’a özel bir Kubernetes control plane tahsis edilir. Böylelikle her bir tenant kendi API Server, controller manager ve etcd bileşenlerine sahip olur [6].

Tenant’lar, kendi cluster’ını istediği gibi namespace’lere bölebilir, CRD’ler (Custom Resource Definitions - Özel Kaynak Tanımları) veya operatör kurulumu yapabilir. Böylece her tenant, ana cluster’daki diğer iş yüklerinden bağımsız, kendine ait sanal bir Kubernetes altyapısında tam kontrol sahibi olur.

Worker node’lar ise tüm tenant’lar arasında paylaşımlı olup bir super-cluster tarafından koordine edilirken, tenant’lar bu node’lara doğrudan erişemez.

Fiziksel İzolasyon

Tenant’lar arasında tam izolasyon sağlanır. Özellikle yüksek güvenlik gerektiren durumlarda, her tenant için ayrı donanım kullanılabilir. Böylelikle bir tenant’ın kaynak kullanımı diğerlerini etkilemez. Her cluster için ayrı fiziksel sunucunun tercih edilecek olması nedeniyle maliyetli ve yönetimi karmaşık bir izolasyon modelidir. Kaynak paylaşımı olmadığı için de ölçeklenebilirlik daha sınırlıdır.

• Finans, sağlık ve kamu hizmetleri gibi yüksek güvenlik gerektiren sektörlerde tercih edilebilir.

Şekil 2’de multi-tenancy modelleri kıyaslanmıştır.

Multi-Cluster (Çoklu Cluster) Stratejileri

Çoklu cluster yönetimini merkezi bir şekilde koordine etmek için Open Cluster Management (OCM) gibi araçlar kullanılabilir. OCM, birden fazla Kubernetes cluster’ını tek bir kontrol düzleminden yönetmeyi sağlar; policy’lerin, iş yüklerinin ve yapılandırmaların cluster’lar arasında tutarlı bir şekilde uygulanmasına olanak tanır [7].

Tüm cluster’ların performansını ve durumunu izlemek da kritik bir ihtiyaçtır. Prometheus ile metriklerin toplanması, Loki ile log’ların birleştirilmesi ve verilerin Grafana ile merkezi bir dashboard üzerinden analiz edilmesi sağlanabilir.

Multi-Tenant Kubernetes’in Faydaları

Multi-tenant Kubernetes mimarileri, organizasyonlar için önemli avantajlar sunar. Bu yaklaşım, aynı Kubernetes cluster’ı içinde birden fazla ekip, proje veya müşterinin kaynakları izole bir şekilde paylaşmasına imkân tanır. Kaynak paylaşımı sayesinde maliyet verimliliği, bu mimarinin en belirgin faydasıdır denilebilir. Tüm tenant’lar için ayrı kubernetes cluster kurmak yerine, tek bir cluster içinde kaynaklar daha verimli kullanılabilir. (Duruma göre dedike cluster daha doğru bir tercih de olabilir.) Atıl kapasite otomatik olarak ihtiyacı olan tenant’lara tahsis edilebilir, böylece toplam donanım gereksinimi azalır ve bulut altyapı maliyetleri düşer. Tek bir cluster’ın yönetimi, birden fazla cluster’a kıyasla elbette daha basittir. Cluster adminler, update, patch ve maintenance işlemlerini merkezi bir şekilde gerçekleştirebilir. Bu da, operasyonel yükü azaltıp ekibin daha farklı görevlere odaklanmasını sağlayacaktır.

Multi-tenant Kubernetes, büyüyen ekipler veya müşteriler için esnek ölçeklenebilirlik sağlar. Yeni tenant’lar, yeni cluster’lar oluşturmaya gerek kalmadan hızla sisteme entegre edilebilir.

Ek olarak, merkezi bir altyapı ile CI/CD (Continuous Integration/Continuous Delivery) süreçleri de önemli ölçüde basitleşecektir. Tüm tenant’lar için standart dağıtım süreçleri ve ortak araçlar kullanılabilir, bu da kod yaşam döngüsünü (Dev -> Prod) daha sorunsuz hale getirir ve DevOps ekiplerinin iş yükünü azaltır.

Bu faydaları bir araya getirdiğimizde, multi-tenant Kubernetes mimarisi, Cloud Native (Bulut Yerel) uygulamalar için verimli, yönetilebilir ve ölçeklenebilir bir temel oluşturur.

Riskler and Zorluklar

Multi-tenant Kubernetes mimarisi birçok avantaj sunsa da, bu yaklaşımın beraberinde getirdiği önemli riskler ve zorluklar da bulunmaktadır;

• Yetersiz İzolasyon Kaynaklı Güvenlik İhlalleri: Multi-tenant ortamlarda en büyük endişelerden biri güvenlik ihlalleridir. Kubernetes, tenant’lar arasında izolasyon sağlamak için çeşitli özellikler sunsa da, yapılandırma hataları ciddi güvenlik açıklarına yol açabilir. Bu, özellikle farklı güvenlik gereksinimlerine sahip tenant’ların aynı cluster’o paylaştığı durumlarda kritik bir sorundur. Örneğin, network policy’ler olmadan, bir pod diğer namespace’lerdeki pod’larla doğrudan iletişim kurabilir. Ya da bir tenant, privileged (ayrıcalıklı) bir container çalıştırıp node üzerinden diğer tenant’ların verilerine erişebilir. Bu tür senaryolar, tüm cluster’ın güvenliğini tehlikeye atar ve veri ihlallerine yol açabilir.

• Kaynak Rekabeti ve Performans Sorunları: Bir diğer önemli zorluk, sınırlı kaynaklardır. Kubernetes, kaynakları ayırmak için Requests ve Limits gibi özellikler sunar, ancak bu özellikler de her şeyin her zaman mükemmel çalışması için yeterli değildir. Bir tenant’ın aşırı kullanımı diğer tenant’ların performansını etkileyebilir (Gürültülü Komşu Problemi). “Gürültülü Komşu” etkisi, Multi-tenant ortamların yaygın sorunlarından biridir. Bu sorun, yalnızca CPU ve memory gibi kaynaklarla sınırlı değildir; network bant genişliği, disk I/O, cache ve diğer paylaşılan sistem kaynaklarını da etkiler. Cluster’da bulunan iki tenant’tan biri yoğun hesaplama gerektiren analitik işlemleri çalıştırırken, diğeri düşük gecikme süresi gerektiren bir web uygulaması çalıştırıyorsa, analitik iş yükünün ani kaynak kullanımı artışı, web uygulamasının yanıt sürelerinde beklenmedik latency (gecikme) yaratabilir.

• Erişim Kontrolü ve Policy Yönetimindeki Karmaşıklık: Multi-tenant bir Kubernetes ortamında erişim kontrolü ve policy yönetimi, tek tenantlı ortamlara göre çok daha karmaşıktır. Her tenant için doğru izinleri, rol tabanlı erişim kontrolünü (RBAC), Network policy’leri ve kaynak kotalarını yapılandırmak ve bunu sürdürmek, yönetim yükünü önemli ölçüde artırır. Bu karmaşıklık, özellikle tenant sayısı arttıkça hızla büyür. Tenant’ların farklı erişim gereksinimleri olabilir; örneğin bazıları sadece deployment yapabilmeli, bazıları daha geniş (cluster-wide) admin izinlerine sahip olmalıdır. Ayrıca, tenant’lar farklı düzeylerde izolasyon ve güvenlik policy’leri gerektirebilir. Tüm bu gereksinimleri dengeli bir şekilde yönetmek, kapsamlı Policy framework’ler ve otomatikleştirilmiş yönetim araçları gerektirir.

• Esneklik Kısıtlamaları: Kubernetes’in güçlü özelliklerinden biri olan operatörler, multi tenant sistemlerde tam anlamıyla kullanılamayabilir. Çünkü CRD’ler cluster genelinde çalışır ve bu, tenant’lar arasında çakışmalara yol açabilir. Birçok operatör tenant bazlı instance oluşturma imkânı sunar. Ancak bu imkânı sunmayan operatörlerin kullanımı sorun yaratabilir.

• Yeni Tenant’ların Dahil Edilmesi: Yeni tenant’ların sisteme hızlı ve sorunsuz bir şekilde entegre edilmesi önemli bir gerekliliktir. GitOps, bu süreci otomatikleştirmek için güçlü bir yaklaşımdır. ArgoCD ile her tenant için namespace oluşturma, RBAC ayarları ve kaynak kotaları gibi işlemler bir Git deposu üzerinden tanımlanabilir ve otomatik olarak uygulanabilir. Bu, manuel müdahaleyi azaltır ve hata riskini en aza indirir.

Tenant’lar Kubernetes API’lerini veya kullanıcı arayüzünü (UI) kullanarak kendi namespace’lerini, iş yüklerini ve kaynak taleplerini yönetebilir. Bu şekilde bir self-service imkânı sunmak da tercih edilebilir.

Yaygın Hatalar ve Kaçınma Yolları

Sıkça karşılaşılan hatalar, doğru planlama ve uygulamalarla önlenebilir.

• Çakışan RBAC İzinleri: Tenant’lara gereğinden fazla yetki verilmesi, güvenlik açıklarına yol açabilir. En az yetki (least-privilege) prensibinin benimsenmesi ve RBAC rollerinin düzenli olarak denetlenmesi gerekir.

• Yetersiz İzolasyon: Tenant’lar arasında veri sızıntısı veya performans sorunlarına neden olabilir. Namespace, NetworkPolicy, PSS gibi mekanizmaların bir arada kullanılması önemlidir.

• Kötü Kaynak Planlaması: Kaynakların yanlış tahsis edilmesi orta ve uzun vadede sorunlar ortaya çıkaracaktır. Başlangıçta fazla kaynak ayırıp, ardından monitoring verileriyle optimize etme yaklaşımı denenebilir.

• Monitoring: Tenant’ların performansını ve sorunlarını görememek, yönetim zorluklarına yol açacaktır. Her tenant için ayrı metrikler ve log’lar toplayan bir gözlemlenebilirlik sistemi kurmak önemlidir. Grafana ile her tenant’a özel Grafana dashboard’lar oluşturulabilir.

Sonuç

Multi-tenant Kubernetes ortamları, kaynak verimliliği, maliyet optimizasyonu ve operasyonel basitlik gibi önemli avantajlar sunarken, güvenlik, izolasyon ve kaynak yönetimi gibi konularda dikkatli bir planlama gerektirir.

Namespace, RBAC, Network Policies ve Resource Quotas gibi Kubernetes’in sunduğu entegre araçlar, tenant’lar arasında etkili bir ayrım ve adil bir paylaşım sağlama konusunda güçlü bir temel oluşturur.

Ancak, bu yapının başarısı, doğru izolasyon modellerinin seçilmesi, güvenlik pratiklerinin hayata geçirilmesi ve sürekli izleme ile yönetim süreçlerinin otomasyonuna bağlıdır. İster soft multi-tenancy ile esnek bir paylaşım, ister hard multi-tenancy ile katı bir izolasyon hedeflensin, organizasyonların ihtiyaçlarına uygun stratejiler geliştirerek Kubernetes’in gücünden tam anlamıyla faydalanmak mümkündür.

Bu yaklaşımla, Cloud Native dünyasında hem ölçeklenebilir hem de güvenli bir altyapı inşa edilebilir.

Kaynakça

1. Andrew Martin, Michael Hausenblas, Hacking Kubernetes (1rd ed.).” O’Reilly Media, 2022.
2. Kubernetes.io, “Three Tenancy Models for Kubernetes”, URL: https://kubernetes.io/blog/2021/04/15/three-tenancy-models-for-kubernetes/ (Erişim zamanı: Mart 28, 2025).
3. Kubernetes.io, “Managing Resources for Containers”, URL: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits (Erişim zamanı: Mart 28, 2025).
4. Kubernetes.io, “Pod Security Standards”, URL: https://kubernetes.io/docs/concepts/security/pod-security-standards/ (Erişim zamanı: Mart 28, 2025).
5. Kubernetes.io, “Multi-Tenancy Concepts”, URL: https://kubernetes.io/docs/concepts/security/multi-tenancy/ (Erişim zamanı: Mart 28, 2025).
6. vCluster, “Get Started with vCluster”, URL: https://www.vcluster.com/docs/get-started (Erişim zamanı: Mart 28, 2025).
7. Open Cluster Management, “OCM Architecture”, URL: https://open-cluster-management.io/docs/concepts/architecture/ (Erişim zamanı: Mart 28, 2025).

Yazımızın teknik gözden geçirmesi için Ayşegül Özkaya Eren’e, editör desteği için ise Nehir BAYAR KİBAR ve Kübra Ertürk’e teşekkür ederiz.