Kubernetes'te multi-tenant küme tasarımı: kiracı modeli ve izolasyon katmanları

Çok kiracılılık nedir, ne zaman gerekir?

Çok kiracılılık (multi-tenancy), bir Kubernetes kümesinin birden fazla kullanıcı grubu ya da iş yükü sahibi tarafından paylaşılmasıdır. Resmî belgeler başlıca kullanım senaryolarını tanımlar. Birincisi, kuruluş içindeki birden çok ekibin tek kümeyi paylaşması: ekipler arasında bir ölçüde güven vardır, amaç kazara etkileşimi ve kaynak kapışmasını önlemektir. İkincisi, bir hizmet sağlayıcının her müşteri için iş yükünün ayrı bir örneğini çalıştırması: müşteriler kümeye doğrudan erişmez ve izolasyon çok daha güçlü olmalıdır.

Belgeler izolasyonu "sert" ve "yumuşak" olarak bir yelpazede ele alır. Aynı organizasyonun ekipleri arasında yumuşak izolasyon çoğu zaman yeterlidir; birbirini tanımayan müşterilerin kodu aynı düğümde çalışıyorsa daha güçlü önlemler gerekir. Bu yüzden tasarımın ilk sorusu "kiracı kim ve ona ne kadar güveniyoruz?" olur.

Neden paylaşılan küme? Her ekibe ayrı küme vermek yönetim yükünü, bulut maliyetini ve yama sürecini çoğaltır. Paylaşılan küme kaynakları verimli kullanır ama izolasyon tasarımını platform ekibine yükler.

Model seçimi: namespace mi, sanal kontrol düzlemi mi, ayrı küme mi?

Belgelerde yaygın uygulamalar olarak her kiracı için bir namespace ve her kiracı için sanal bir kontrol düzlemi öne çıkar. Bir diğer seçenek, kiracıya tümüyle ayrı küme vermektir.

Karar ölçütleri: • Güven düzeyi: ekipler aynı kuruluştansa namespace modeli genelde yeterlidir; dışarıdan müşteriler için sanal kontrol düzlemi ya da ayrı küme düşünülür. • Küme düzeyi kaynak ihtiyacı: kiracı kendi CRD'lerini, admission kurallarını ya da küme düzeyi nesnelerini yönetecekse namespace yetmez; sanal kontrol düzlemi bu bağımsızlığı sağlar. • Operasyonel yük: ayrı küme en güçlü izolasyon ve en yüksek işletme maliyetidir; namespace modeli en ucuz ama en çok yapılandırma gerektirendir. • Mevzuat ve uyum: bazı veriler fiziksel ayrım gerektirebilir. • Paylaşılan hizmetler: ortak izleme, günlükleme ve ağ çözümleri kiracılara nasıl sunulacak?

Çoğu kurumsal platform, ekipler için namespace modeliyle başlar ve ihtiyaç doğdukça güçlü izolasyon gerektiren iş yüklerini ayrı düğüm havuzlarına ya da ayrı kümelere taşır.

Namespace tasarımı ve isimlendirme standardı

Namespace, kiracı sınırının temel birimidir. Belgelere göre nesne adlarının namespace'ler arasında çakışabilmesini sağlar ve RBAC rolleri ile ağ politikaları gibi politikaların kapsamını belirler.

Tasarım kararları: • Kiracı başına tek namespace mi, ortam başına ayrı namespace mi (geliştirme, test, üretim)? Çok kullanılan düzen, ekip ve ortam kombinasyonu başına ayrı namespace'tir. • İsimlendirme: ekip, uygulama ve ortamı belirten tutarlı bir kalıp belirleyin; kalıbı otomasyon üretsin, elle açılan namespace'ler standart dışına çıkar. • Etiketleme: sahip ekip, maliyet merkezi ve ortam etiketleri raporlama ve politika seçiminde kullanılır. • Sistem namespace'leri: platform bileşenleri kiracıdan ayrı tutulur ve kiracıların erişimine kapatılır.

Namespace oluşturmayı kiracı devreye alma sürecinin parçası yapın: tek bir şablon ya da otomasyon, namespace'i kota, rol bağlama ve ağ politikasıyla birlikte oluştursun. Elle kurulan namespace'te bir politikanın unutulması, izolasyondaki en sık deliktir.

RBAC: kim neyi yapabilir?

RBAC (rol tabanlı erişim denetimi), kullanıcıların ve servis hesaplarının hangi nesneler üzerinde hangi işlemleri yapabileceğini belirler. Çok kiracılı tasarımda amaç, her kiracının yalnız kendi namespace'iyle ilgili yetkilere sahip olmasıdır. Belgeler erişim denetimlerini, kullanıcıları ve servis hesaplarını bir namespace ile sınırlamak için kullanır.

Uygulama şu sırayla yürür: • Kimlik kaynağını belirleyin: kurumsal kimlik sağlayıcısındaki gruplar Kubernetes gruplarına eşlenir. Kişi bazlı bağlama yerine grup bazlı bağlama tercih edin; kişi ekip değiştirdiğinde yalnız grup üyeliği güncellenir. • Rol seçin: hazır edit ve view ClusterRole'leri çoğu ekip için başlangıçtır; daha dar yetki gerekiyorsa özel Role yazın. • Rolü yalnız ilgili namespace'e bağlayın (RoleBinding). • Küme genelinde yetki (ClusterRoleBinding) vermeyi platform ekibiyle sınırlı tutun.

Örnek komut biçimi (grup ve namespace adları kurgusaldır):

kubectl create rolebinding ekip-a-duzenleyen --clusterrole=edit --group=ekip-a --namespace=ekip-a

Sık hata: kiracıya küme genelinde okuma yetkisi vermek. Bu, diğer kiracıların nesne adlarını ve yapılandırmalarını görmesine neden olabilir. Yetki denetimini düzenli olarak gözden geçirin ve kullanılmayan bağlamaları kaldırın.

Kaynak kotaları: adil paylaşım

Kota koymazsanız bir kiracının hatalı iş yükü bütün küme kapasitesini tüketebilir. Resmî belgeye göre ResourceQuota, bir namespace içindeki toplam kaynak tüketimini sınırlar ve namespace başına uygulanır; namespace'te kota yoksa o namespace için sınır da yoktur.

Kota şu türlerde kurulur: • Hesaplama kotası: namespace'teki toplam requests.cpu, requests.memory, limits.cpu ve limits.memory değerlerini sınırlar. • Nesne sayısı kotası: pod, servis, yük dengeleyici türü servis gibi nesnelerin sayısını sınırlar.

Davranışın bilinmesi gereken yönleri: kotayı aşan oluşturma ya da güncelleme isteği reddedilir ve hata mesajı hangi kısıtın aşıldığını söyler. Kota değişimi mevcut kaynakları etkilemez. Namespace'te cpu veya memory için kota varsa her yeni pod'un ilgili requests ya da limits değerini belirtmesi gerekir; belirtmezse kabul reddedilebilir. Çözüm olarak LimitRange ile varsayılan istek ve limit atanır. Deployment gibi nesneler oluşup pod'lar oluşamayabilir; bu durumda kubectl describe ile namespace'in kota durumuna bakılır.

Kota tanımının silinmemesi ya da değiştirilmemesi için kiracının bu nesneler üzerindeki yetkisi RBAC ile kısıtlanır; aksi halde kiracı kendi kotasını kaldırabilir. Kontrol komutu: kubectl describe resourcequota --namespace=ekip-a

Ağ izolasyonu: NetworkPolicy ile varsayılan reddet

Kubernetes'te varsayılan olarak pod'lar yalıtılmamıştır; belgeye göre hiçbir NetworkPolicy bir pod'u seçmiyorsa o pod'a gelen ve ondan çıkan tüm bağlantılara izin verilir. Yani çok kiracılı kümede bir ekibin pod'u başka ekibin pod'una varsayılan olarak ulaşabilir. Bunu kapatmak için kiracı namespace'ine varsayılan reddet politikası eklenir, ardından gereken trafiğe tek tek izin verilir.

Varsayılan gelen trafiği reddet politikasının biçimi (apiVersion satırı atlanmıştır, sürümü belgeden alın):

kind: NetworkPolicy metadata: name: default-deny-ingress namespace: ekip-a spec: podSelector: {} policyTypes: - Ingress

Boş podSelector namespace'teki tüm pod'ları seçer; politika türü Ingress olduğu için o namespace'e gelen bağlantılar kapanır. Giden trafik için aynı kalıp Egress türüyle kurulur. Sonrasında ortak hizmetlere (örneğin DNS, izleme) ve kendi namespace içi trafiğe izin veren kurallar eklenir. Birden çok politika birleşimsel çalıştığı için izinler toplanır; sıra önemli değildir.

Kritik uyarı: NetworkPolicy yalnız ağ eklentisi (CNI) bu özelliği destekliyorsa etkilidir; destek yoksa politika nesnesi oluşur ama hiçbir etkisi olmaz. Bir de, from içinde podSelector ve namespaceSelector aynı öğede ise VE, ayrı öğelerde ise VEYA anlamı taşır; bu fark yanlış genişlik yaratan sık hatadır.

Veri düzlemi izolasyonu, gözlemlenebilirlik ve kiracı devreye alma

Namespace düzeyindeki önlemler kontrol düzlemini ayırır; düğümü paylaşan kod hâlâ aynı çekirdeği kullanır. Belgeler veri düzlemi izolasyonu başlığı altında ağ, depolama, konteyner sandbox'ı ve düğüm izolasyonunu sayar. Güçlü ayrım gerektiren iş yükleri için ayrı düğüm havuzu, taint ve toleration ile yerleşim kontrolü ve sandbox çalıştırma ortamları düşünülür. Depolamada kiracıya özgü depolama sınıfları ve erişim sınırları kullanılır.

İş yükü güvenliği için pod'ların ayrıcalıklı çalışmasını, ana makine ağına ve dizinlerine erişmesini engelleyen politika kapıları (admission kontrolü) devreye alınır. Kiracı manifestosunun bu kurallara uymaması, daha oluşturma aşamasında reddedilir.

Gözlemlenebilirlikte her kiracının yalnız kendi günlüklerini ve ölçümlerini görmesi hedeflenir. Namespace etiketleriyle kiracı bazlı kaynak kullanımı raporlanır; bu rapor hem maliyet paylaşımına hem kapasite planlamaya girdi sağlar.

Kiracı devreye alma, tüm bunları tekrarlanabilir bir akışa bağlar: talep, onay, otomasyonla namespace, rol bağlama, kota, ağ politikası, izleme erişimi ve dokümantasyon. Bu akış ne kadar otomatikse, kiracıdan kiracıya yapılandırma farkı o kadar azalır.

Bu becerinin Mindset programındaki yeri

Kubernetes Çok Kiracılı Küme Tasarımı programı, tek kümede birden çok ekibi barındıran platform mühendislerine, DevOps ve güvenlik ekiplerine yöneliktir. Modül başlıkları çok kiracılılık modelleri ve karar kriterleri, namespace tasarımı, RBAC ve kurumsal kimlik entegrasyonu, kaynak kotaları, ağ izolasyonu, iş yükü güvenliği ve politika kapıları, gözlemlenebilirlik ve kiracı raporlaması ile platform işletimi ve kiracı devreye almayı kapsar. Bu sayfadaki tasarım sırasını kendi küme mimarisi üzerinde çalışmak isteyen platform ekipleri için uygun bir çerçevedir.