Kubernetes'te Namespace Stratejisi: Multi-Tenant Küme Yönetimi

Kubernetes’e geçen her ekip aynı soruyla karşılaşır: namespace’leri nasıl organize etmeliyiz? Cevap basit görünür — ama production’da gördüğümüz sorunların büyük çoğunluğu buradan çıkar.

Neden önemli?

Namespace izolasyonu, Kubernetes güvenlik modelinin temelidir. Doğru yapılandırılmamış bir namespace yapısı şu sorunlara yol açar:

• Ekipler birbirinin kaynaklarına müdahale eder
• Bir servisin runaway pod’ları tüm kümenin belleğini tüketir
• RBAC kuralları zamanla yönetilemez hale gelir
• Yanlış namespace’e production deploy yapılır

Naming convention: team-environment

En yaygın ve sürdürülebilir pattern <team>-<env> formatıdır:

# Teknosa'da kullandığımız yapı
namespaces:
  - frontend-dev
  - frontend-uat
  - frontend-prod
  - backend-dev
  - backend-uat
  - backend-prod
  - platform-prod   # cross-cutting servisler (monitoring, ingress)

Bu yapının avantajı: kubectl get pods -n backend-prod komutu ne istediğinizi net söyler. default, app, production gibi isimler iki ay sonra muğlaklaşır.

ResourceQuota ile kaynak izolasyonu

Namespace oluşturduktan sonra ResourceQuota tanımlamasını atlama. Bir ekibin deployment’ı OOM kill’e girip tüm node’u çökertebilir.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: backend-prod
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi
    pods: "50"
    services: "20"

LimitRange ile de pod başına varsayılan limit belirleyin — böylece requests yazmayan deployment’lar otomatik olarak makul bir değer alır:

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: backend-prod
spec:
  limits:
  - type: Container
    default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 100m
      memory: 128Mi

RBAC: Namespace başına minimum yetki

Klasik hata: cluster-admin yetkisi vermek. Her ekibin yalnızca kendi namespace’lerinde yetki olması gerekir.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: frontend-team-edit
  namespace: frontend-prod
subjects:
- kind: Group
  name: frontend-team   # OIDC / SSO group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

edit ClusterRole standart olarak deployment, service, configmap yönetimine izin verir ama RBAC kurallarını değiştirmeye izin vermez. Production için yeterli başlangıç noktası.

Network Policy ile trafik izolasyonu

Varsayılan olarak Kubernetes’te tüm pod’lar birbirine erişebilir. Namespace izolasyonu ağ seviyesinde otomatik izolasyon sağlamaz — Network Policy şarttır.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: backend-prod
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: backend-prod
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: platform-prod   # monitoring erişimi

RKE2 ortamında production/dr ayrımı

Teknosa’da 4 ortam vardı: dev / uat / prod / dr. Her ortam için ayrı namespace grubunu tek bir RKE2 kümesi üzerinde yönetiyorduk. Kritik fark: prod ve dr namespace’leri ayrı bir node pool’a nodeSelector + taint/toleration ile sabitliyorduk — dev deployment’larının production node’larına gitme ihtimali sıfırlanıyordu.

# Production pod spec
nodeSelector:
  kubeatlas.io/tier: production
tolerations:
- key: "kubeatlas.io/tier"
  operator: "Equal"
  value: "production"
  effect: "NoSchedule"

Sonuç

Namespace stratejisi bir kez doğru kurulursa operasyonel yükü ciddi ölçüde azaltır. Özetle:

• team-environment naming convention kullan
• Her namespace’e ResourceQuota ve LimitRange tanımla
• RBAC’ı cluster-admin değil namespace düzeyinde yönet
• Network Policy olmadan izolasyon tamamlanmış değildir
• Production workload’larını node taints ile ayır

Mevcut kümenizin namespace organizasyonunu değerlendirmek istiyorsanız 30 dakikalık ücretsiz bir teknik inceleme planlayabiliriz.