Kubernetes Namespaces: Kaynak Yönetimi ve İzolasyonun Temel Taşı

Modern uygulama geliştirme süreçlerinde, özellikle mikroservis mimarileri ve bulut tabanlı çözümler yaygınlaştıkça, kaynak yönetimi ve izolasyon kritik bir hal almıştır. Peki, onlarca farklı uygulamanın, yüzlerce hatta binlerce konteynerin aynı Kubernetes kümesi üzerinde sorunsuz bir şekilde bir arada çalışmasını nasıl sağlarız? İşte bu noktada Kubernetes Namespaces devreye giriyor. Bu makalede, Namespaces’in ne olduğunu, neden bu kadar önemli olduğunu ve gerçek dünya senaryolarında bize nasıl avantajlar sağladığını adım adım keşfedeceğiz. Eğer Kubernetes ortamınızı daha düzenli, güvenli ve verimli hale getirmek istiyorsanız, doğru yerdesiniz.

Büyük ve karmaşık Kubernetes kümelerinde kaynakların verimli bir şekilde yönetilmesi, geliştiricilerin üretkenliğini artırmanın ve operasyonel maliyetleri düşürmenin anahtarıdır. Bir küme üzerinde farklı ekiplerin, farklı projelerin veya farklı ortamların (geliştirme, test, üretim) aynı anda çalıştığını hayal edin. Eğer tüm bu kaynaklar tek bir alanda toplansa, kısa sürede büyük bir kaos yaşanması kaçınılmazdır. Kaynak adlandırma çakışmaları, yanlışlıkla silinen veya değiştirilen önemli servisler, yetkisiz erişim denemeleri gibi sorunlar hızla ortaya çıkabilir. Bu tür durumlar, sadece operasyonel verimsizliğe yol açmakla kalmaz, aynı zamanda güvenlik açıkları oluşturarak veri bütünlüğünü ve sistem güvenliğini de tehlikeye atar. Bu bağlamda, her bir ekibin veya projenin kendi izole edilmiş alanında çalışabilmesi, hem düzeni sağlar hem de olası hataların veya kötü niyetli saldırıların etkisini sınırlar. İşte bu temel ihtiyaç, Kubernetes Namespaces kavramının doğmasına neden olmuştur.

Düşünün ki, bir yazılım şirketinde hem “ödeme sistemleri” ekibi hem de “kullanıcı arayüzü” ekibi aynı Kubernetes kümesini kullanıyor. Her iki ekip de “API Gateway” adında bir servis dağıtmak isteyebilir. Eğer Namespaces olmasaydı, bu iki servis adlandırma çakışması yaşar ve sadece bir tanesi çalışabilirdi, ya da daha kötüsü, birbirlerinin ayarlarını geçersiz kılabilirdi. Dahası, ödeme sistemleri ekibinin kritik verilerine kullanıcı arayüzü ekibinin erişmesi istenmezken, Namespaces bu erişim kontrolünü de kolaylaştırır. Kısacası, Namespaces, Kubernetes kümenizi mantıksal bölümlere ayırarak, her bir bölümün kendi içinde bağımsız ve düzenli bir şekilde çalışmasını sağlar. Bu sayede, farklı ekipler veya projeler arasında hem işbirliği artar hem de olası çakışmalar minimize edilir. Ayrıca, kaynakların daha kolay takip edilmesine, izlenmesine ve yönetilmesine olanak tanır. Özellikle DevOps pratiklerini uygulayan organizasyonlar için Namespaces, olmazsa olmaz bir araçtır.

Kubernetes Namespaces Nedir ve Ne İşe Yarar? Temel Kavramlar

Kubernetes Namespaces, temel olarak bir Kubernetes kümesi içinde kaynakları (Pod’lar, Servisler, Deployment’lar vb.) mantıksal olarak izole eden ve gruplayan bir mekanizmadır. Bunu, bir dosya sistemindeki klasörlere benzetebiliriz. Tıpkı bir klasörün içinde aynı ada sahip dosyaların bulunabilmesi gibi (örneğin, “belgeler/rapor.docx” ve “projeler/rapor.docx”), farklı Namespaces içinde aynı ada sahip kaynaklar bulunabilir. Bu, adlandırma çakışmalarını önler ve küme kaynaklarını daha düzenli hale getirir. Ancak Namespaces’in işlevi yalnızca adlandırma çakışmalarını önlemekle sınırlı değildir; çok daha geniş kapsamlı avantajlar sunar.

Namespaces, aynı zamanda erişim kontrolü (Role-Based Access Control – RBAC) ve kaynak kotası (Resource Quotas) gibi önemli özelliklerin uygulanması için de bir temel oluşturur. Örneğin, belirli bir ekibin yalnızca kendi Namespace’indeki kaynaklara erişebilmesini veya yalnızca belirli bir miktarda CPU ve bellek kullanabilmesini sağlayabilirsiniz. Bu, multi-tenant (çok kullanıcılı) Kubernetes ortamlarında kritik bir ihtiyaçtır. Her bir “tenant” veya “takım” kendi Namespaces’ine sahip olabilir ve böylece diğerlerinin kaynaklarını etkilemeden kendi uygulamalarını dağıtabilir ve yönetebilir. Böylece, tek bir fiziksel Kubernetes kümesi, mantıksal olarak ayrılmış birçok “sanal küme” gibi davranabilir. Bu yapı, hem güvenlik açısından hem de kaynakların adil dağıtımı açısından büyük faydalar sağlar.

Kubernetes kurulumunda varsayılan olarak birkaç Namespace gelir:

• default: Kaynaklar için varsayılan Namespace’tir. Eğer bir Namespace belirtmezseniz, kaynaklarınız buraya dağıtılır. Küçük projeler veya başlangıç aşamasında kullanışlı olabilir, ancak üretim ortamlarında farklı Namespaces kullanmak genellikle daha iyi bir pratiktir.
• kube-system: Kubernetes kümesinin kendisi tarafından kullanılan sistem kaynaklarını (kontrol düzlemi bileşenleri, DNS servisleri gibi) içerir. Bu Namespace’teki kaynakları genellikle değiştirmemeniz önerilir.
• kube-public: Genel olarak erişilebilir ve okunabilir kaynakları içerir. Örneğin, küme bilgilerini içeren bir ConfigMap bu Namespace’te yer alabilir.
• kube-node-lease: Küme bileşenlerinin node’lar arasındaki “kalp atışı” iletişimini hızlandırmak için kullanılan lease objelerini içerir.

Bu temel Namespaces dışında, kendi ihtiyaçlarınıza göre yeni Namespaces oluşturmak, Kubernetes deneyiminizi önemli ölçüde geliştirecektir. İster geliştirme, test, üretim ortamlarını ayırmak isteyin, ister farklı departmanlar için ayrı çalışma alanları oluşturun, Namespaces size bu esnekliği sunar. Kaynaklarınızı daha iyi organize etmek, erişim güvenliğini sağlamak ve maliyetleri kontrol altında tutmak için Namespaces kilit bir rol oynar.

Namespace Oluşturma ve Yönetme: Adım Adım Uygulamalı Rehber

Kubernetes Namespaces oluşturmak ve yönetmek oldukça basittir. kubectl komut satırı aracı bu işlemler için temel arayüzümüzdür. İster hızlı bir komutla yeni bir Namespace oluşturalım, ister YAML dosyalarıyla daha deklaratif bir yaklaşım sergileyelim, her iki yöntem de kolayca uygulanabilir.

1. Yeni Bir Namespace Oluşturma

Yeni bir Namespace oluşturmanın en hızlı yolu kubectl create namespace komutunu kullanmaktır:

kubectl create namespace gelistirme

Bu komut, "gelistirme" adında yeni bir Namespace oluşturacaktır. Çıktıda genellikle "namespace/gelistirme created" mesajını görürsünüz.

Alternatif olarak, daha deklaratif bir yöntem olan YAML dosyasını kullanabiliriz. Bu yaklaşım, konfigürasyonu versiyon kontrol sistemlerinde (Git gibi) saklamak için daha uygundur. Bir dosya oluşturalım, örneğin gelistirme-namespace.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: gelistirme
  labels:
    environment: dev
    project: myapp

Bu dosyayı kaydedip aşağıdaki komutla uygulayabiliriz:

kubectl apply -f gelistirme-namespace.yaml

Bu yöntem, Namespace'e ek etiketler (labels) eklememize olanak tanır, bu da daha sonra kaynakları filtrelemek veya otomatize etmek için faydalı olabilir.

2. Varolan Namespaces'i Görüntüleme

Kümenizdeki tüm Namespaces'leri görmek için aşağıdaki komutu kullanabilirsiniz:

kubectl get namespaces

Bu komut, kümenizdeki tüm Namespaces'leri ve onların durumlarını (örneğin, Active veya Terminating) listeler. Çıktıda genellikle default, kube-system gibi varsayılan Namespaces'lerin yanı sıra sizin oluşturduğunuz Namespaces'i de görürsünüz.

3. Bir Namespace'i Tanımlama ve Detaylarını Görme

Belirli bir Namespace hakkında daha fazla bilgi edinmek isterseniz, describe komutunu kullanabilirsiniz:

kubectl describe namespace gelistirme

Bu komut, Namespace'in durumu, etiketleri, olayları ve ona uygulanan ResourceQuota veya LimitRange gibi kaynak kısıtlamaları hakkında ayrıntılı bilgiler sağlar. Bu detaylar, özellikle sorun giderme veya kaynak yönetimi yaparken oldukça değerlidir.

4. Farklı Namespaces Arasında Geçiş Yapma

Normalde, Kubernetes kaynaklarını (Pod'lar, Deployment'lar vb.) listelerken veya oluştururken, --namespace veya -n bayrağını kullanarak hangi Namespace'te işlem yapacağımızı belirtmemiz gerekir. Örneğin:

kubectl get pods -n gelistirme
kubectl create deployment myapp --image=nginx -n gelistirme

Ancak, sürekli olarak -n yazmak zaman alıcı olabilir. Bu durumlarda, kubectl config set-context komutu ile varsayılan Namespace'i değiştirebilirsiniz. Daha da kolaylaştırmak için, kubectx ve kubens gibi üçüncü taraf araçlar (krew eklentileri olarak da mevcuttur) şiddetle tavsiye edilir. Örneğin, kubens ile kolayca Namespace değiştirebilirsiniz:

kubens gelistirme

Bu komut, mevcut terminal oturumunuz için varsayılan Namespace'i "gelistirme" olarak ayarlar, böylece her komutta -n bayrağını belirtmenize gerek kalmaz. Bu, günlük geliştirme ve operasyonel iş akışlarını önemli ölçüde hızlandırır.

5. Bir Namespace'i Silme

Bir Namespace'i ve içindeki tüm kaynakları silmek için aşağıdaki komutu kullanabilirsiniz:

kubectl delete namespace gelistirme

Bu komut, dikkatli kullanılmalıdır, çünkü Namespace ile birlikte içindeki tüm Pod'lar, Servisler, Deployment'lar, ConfigMap'ler, Secret'lar ve diğer tüm kaynaklar geri dönülemez bir şekilde silinir. Genellikle Namespace'in silinmesi biraz zaman alabilir, çünkü Kubernetes önce içindeki tüm kaynakları sonlandırır. Bu işlemler sırasında Namespace'in durumu "Terminating" olarak görünür.

Namespace yönetimi, Kubernetes'in temel ve en güçlü özelliklerinden biridir. Bu adımları izleyerek, kümenizi daha düzenli, izole edilmiş ve yönetilebilir hale getirebilirsiniz. Özellikle büyük ölçekli ve çok kullanıcılı ortamlarda, Namespaces'in doğru kullanımı, operasyonel yükü azaltır ve genel sistem stabilitesini artırır.

Kaynakları Namespaces Arasında Dağıtma ve İzole Etme Nasıl Yapılır?

Kubernetes Namespaces'in temel amacı, kaynakları izole etmek ve gruplandırmaktır. Bir Namespace oluşturduktan sonra, uygulamalarınızı ve servislerinizi bu Namespace'e nasıl dağıtacağınızı bilmeniz önemlidir. Bu süreç, uygulamanızın diğer Namespace'lerdeki kaynaklarla çakışmamasını ve yalnızca yetkilendirilmiş erişime sahip olmasını sağlar.

1. Kaynakları Belirli Bir Namespace'e Dağıtma

Kubernetes objelerini bir Namespace'e dağıtmanın en yaygın yolu, YAML tanım dosyasında metadata.namespace alanını belirtmektir. Örneğin, "gelistirme" Namespace'ine bir Nginx Pod'u dağıtmak istediğimizi varsayalım. İşte nginx-pod.yaml dosyamız:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-dev
  namespace: gelistirme # Pod'u bu Namespace'e dağıt
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

Bu dosyayı uyguladığımızda, Pod doğrudan "gelistirme" Namespace'ine yerleşecektir:

kubectl apply -f nginx-pod.yaml

Pod'un doğru Namespace'te çalıştığını doğrulamak için:

kubectl get pods -n gelistirme

Eğer -n gelistirme bayrağını kullanmazsanız ve mevcut bağlamınız varsayılan Namespace'te ise, bu Pod'u göremezsiniz. Bu, Namespaces'in izolasyon yeteneğinin basit bir göstergesidir.

Benzer şekilde, bir Deployment, Service, ConfigMap veya Secret gibi diğer tüm Namespace kapsamlı kaynakları da aynı şekilde belirli bir Namespace'e dağıtabilirsiniz. Örneğin, bir Service için:

apiVersion: v1
kind: Service
metadata:
  name: my-service-dev
  namespace: gelistirme # Servisi bu Namespace'e dağıt
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Uygulama:

kubectl apply -f my-service-dev.yaml

2. Namespaces Arası İzolasyonun Anlamı

Namespaces, kaynaklar arasında güçlü bir mantıksal izolasyon sağlar. Bu, şu anlama gelir:

• Adlandırma Çakışmaları Yok: "gelistirme" Namespace'indeki "nginx-pod-dev" ile "uretim" Namespace'indeki "nginx-pod-dev" tamamen farklı varlıklardır ve birbirleriyle çakışmazlar.
• Varsayılan Görünmezlik: Bir Namespace'teki Pod'lar veya diğer kaynaklar, varsayılan olarak başka bir Namespace'teki kaynakları doğrudan "göremez" veya onlara erişemez. Bu, özellikle hizmet keşfi için önemlidir. Örneğin, "gelistirme"deki bir Pod, sadece "my-service-dev" adıyla "uretim"deki bir servise erişmeye çalışırsa başarısız olur.
• Güvenlik Sınırları: Bu izolasyon, RBAC (Rol Tabanlı Erişim Kontrolü) ile birleştiğinde güçlü güvenlik sınırları oluşturur. Bir kullanıcının veya hizmet hesabının yalnızca belirli bir Namespace'teki kaynakları yönetmesine izin verebilirsiniz, bu da yetkisiz erişimi önler.

3. Namespaces Arası İletişim (İstisnalar)

İzolasyon temel prensip olsa da, bazen Namespaces arasında iletişime ihtiyaç duyulabilir. Kubernetes DNS, bu konuda bize yardımcı olur. Bir Namespace'teki Pod, başka bir Namespace'teki bir servise tam nitelikli alan adı (FQDN) kullanarak erişebilir. FQDN formatı genellikle şöyledir:

..svc.cluster.local

Örneğin, "gelistirme" Namespace'indeki bir Pod, "uretim" Namespace'indeki "my-backend-service" adlı bir servise erişmek için my-backend-service.uretim.svc.cluster.local adresini kullanabilir. Daha kısa olarak, eğer Pod'lar aynı kümede ise my-backend-service.uretim şeklinde de erişebilirler. Ancak bu iletişimin güvenlik duvarları (Network Policies) ile kontrol altında tutulması gerektiğini unutmamak önemlidir.

Network Policies, Namespaces arasında kimin kiminle konuşabileceğini tanımlamanıza olanak tanır. Örneğin, "gelistirme" Namespace'indeki Pod'ların "uretim" Namespace'indeki herhangi bir servisle iletişim kurmasını tamamen engelleyebilir veya yalnızca belirli portlar üzerinden belirli servislerle iletişime izin verebilirsiniz. Bu, güvenlik katmanınızı daha da güçlendirir.

Kaynakları doğru Namespaces'e dağıtmak ve onların izolasyon özelliklerinden yararlanmak, Kubernetes kümenizi daha yönetilebilir, güvenli ve ölçeklenebilir hale getirmenin kritik bir adımıdır. Bu düzenli yaklaşım, özellikle büyük ekiplerde ve karmaşık uygulama yığınlarında geliştirme ve operasyonel süreçleri basitleştirir.

Namespaces ile Erişim Kontrolü ve Güvenlik: Rol Tabanlı Erişim Kontrolü (RBAC) Entegrasyonu

Kubernetes Namespaces, yalnızca kaynakları mantıksal olarak bölmekle kalmaz, aynı zamanda erişim kontrolü ve güvenlik sağlamak için güçlü bir temel sunar. Özellikle çok kullanıcılı ortamlarda, hangi kullanıcının veya hizmet hesabının hangi kaynaklara ve hangi Namespace'te erişebileceğini belirlemek hayati önem taşır. İşte bu noktada Kubernetes'in Rol Tabanlı Erişim Kontrolü (RBAC) mekanizması devreye girer ve Namespaces ile mükemmel bir uyum içinde çalışır.

RBAC ve Namespaces: Kim Nereye Erişebilir?

RBAC, Kubernetes'te kullanıcıların veya hizmet hesaplarının hangi eylemleri gerçekleştirebileceğini tanımlamanızı sağlar. Temelde üç ana RBAC objesi bulunur:

1. Role: Belirli bir Namespace içinde izinleri tanımlar. Örneğin, bir Role "gelistirme" Namespace'indeki Pod'ları okuma (get, list, watch) ve oluşturma (create) yetkisi verebilir.
2. ClusterRole: Küme genelinde izinleri tanımlar. Bu Roller Namespace'e özgü değildir ve tüm Namespaces'lerde veya küme seviyesindeki kaynaklarda (Node'lar gibi) geçerli olur.
3. RoleBinding: Bir Role'ü bir kullanıcıya, gruba veya hizmet hesabına bağlar ve izinleri o Namespace içinde uygular.
4. ClusterRoleBinding: Bir ClusterRole'ü bir kullanıcıya, gruba veya hizmet hesabına bağlar ve izinleri tüm küme genelinde uygular.

Namespaces, RBAC'ın kapsamını belirlemede kilit bir rol oynar. Bir Role ve RoleBinding tanımlayarak, bir ekibin veya bireyin yalnızca kendi atanan Namespace'indeki kaynaklara erişebilmesini ve diğer Namespaces'teki kaynaklara müdahale edememesini sağlayabilirsiniz.

Pratik Senaryo: Geliştirme Ekibine Sadece Kendi Namespaces'ine Erişim Verme

Diyelim ki bir "gelistirme" ekibimiz var ve bu ekibin yalnızca "gelistirme" Namespace'indeki Pod'ları, Deployment'ları ve Servisleri yönetmesini istiyoruz. Diğer Namespaces'lerdeki (örneğin, "uretim") kaynaklara erişmelerini veya bunları değiştirmelerini engellemek istiyoruz. İşte bunu nasıl yapacağımız:

Adım 1: Bir Role Tanımlama

"gelistirme" Namespace'indeki Pod'lar, Deployment'lar ve Servisler üzerinde temel yönetim izinlerini veren bir Role tanımlayalım. Bu, yalnızca "gelistirme" Namespace'inde geçerli olacaktır.

# gelistirme-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: gelistirme-yonetici-rolu
  namespace: gelistirme # Bu Role sadece 'gelistirme' Namespace'inde geçerli olacak
rules:
- apiGroups: ["", "apps", "extensions"] # Çekirdek API (Pod, Service) ve Uygulama API'leri (Deployment)
  resources: ["pods", "deployments", "services", "configmaps", "secrets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] # İzin verilen eylemler

Bu Role'ü uygulayalım:

kubectl apply -f gelistirme-role.yaml

Adım 2: Bir RoleBinding Oluşturma

Şimdi bu Role'ü belirli bir kullanıcıya veya hizmet hesabına bağlamamız gerekiyor. Diyelim ki, "dev-user" adında bir kullanıcımız var (Kubernetes'te kullanıcılar genellikle dışarıdan kimlik doğrulama sistemleri aracılığıyla yönetilir, ancak test amaçlı olarak direkt bağlanabiliriz veya bir ServiceAccount kullanabiliriz). Bir ServiceAccount oluşturalım ve ona bu Role'ü bağlayalım.

# dev-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: dev-service-account
  namespace: gelistirme
---
# gelistirme-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gelistirme-yonetici-baglama
  namespace: gelistirme # RoleBinding de 'gelistirme' Namespace'inde geçerli olacak
subjects:
- kind: ServiceAccount
  name: dev-service-account # Bağlanacak ServiceAccount
  namespace: gelistirme
roleRef:
  kind: Role
  name: gelistirme-yonetici-rolu # Bağlanacak Role
  apiGroup: rbac.authorization.k8s.io

Bu ServiceAccount'ı ve RoleBinding'i uygulayalım:

kubectl apply -f dev-sa.yaml
kubectl apply -f gelistirme-rolebinding.yaml

Artık "dev-service-account" adlı ServiceAccount, yalnızca "gelistirme" Namespace'indeki belirtilen kaynaklar üzerinde yönetim yetkisine sahip olacak. Bu, "dev-service-account" ile çalışan bir Pod'un "uretim" Namespace'indeki bir kaynağı silmeye çalıştığında bir yetkilendirme hatası (Error from server (Forbidden)) alacağı anlamına gelir. Bu sayede, yanlışlıkla yapılan veya kötü niyetli eylemlerin etkileri belirli bir Namespace ile sınırlanmış olur.

Kubernetes Namespaces ile RBAC'ın entegrasyonu, küme güvenliğini katmanlı bir yapıda ele almayı mümkün kılar. Her bir Namespace'i adeta bağımsız bir güvenlik bölgesi olarak düşünerek, ekiplerin ve uygulamaların sadece ihtiyaç duydukları kaynaklara erişmesini sağlayabilir, böylece genel güvenlik duruşunuzu önemli ölçüde güçlendirebilirsiniz. Bu yaklaşım, büyük ölçekli ve hassas veri barındıran Kubernetes ortamlarında vazgeçilmezdir.

Kaynak Kotaları (Resource Quotas) ve Limit Ranges ile Namespace Kaynak Yönetimi

Kubernetes Namespaces, kaynakları mantıksal olarak izole etmek için harika bir yol sunar, ancak bu izolasyonun ötesinde, her bir Namespace'in ne kadar kaynak (CPU, bellek, depolama vb.) tüketebileceğini de sınırlamanız gerekebilir. Aksi takdirde, tek bir ekip veya uygulama, kümedeki tüm kaynakları tüketerek diğer uygulamaların performansını olumsuz etkileyebilir veya kümenin çökmesine neden olabilir. İşte bu senaryoda Resource Quotas (Kaynak Kotaları) ve Limit Ranges devreye girer.

Bu iki özellik, Namespaces ile birlikte kullanıldığında, küme kaynaklarının daha adil ve verimli bir şekilde dağıtılmasını, maliyetlerin kontrol altında tutulmasını ve küme stabilitesinin sağlanmasını mümkün kılar. Her bir Namespace'e özel kaynak sınırları tanımlayarak, bir "kötü komşu"nun (noisy neighbor) diğerlerinin işini aksatmasını engellersiniz.

Resource Quotas: Namespace Bazında Kaynak Sınırları

Resource Quotas, belirli bir Namespace'in tüketebileceği toplam kaynak miktarını veya o Namespace içinde oluşturulabilecek obje sayısını sınırlamak için kullanılır. Bu, kaynak israfını önler ve ekiplerin kendilerine ayrılan sınırlar içinde kalmasını sağlar. Resource Quota, oluşturulduğunda hemen devreye girer ve tanımlı limitlere uyulmasını zorunlu kılar.

Bir ResourceQuota ile şunları sınırlayabilirsiniz:

• Hesaplanabilir Kaynaklar (Computable Resources): CPU (requests.cpu, limits.cpu) ve bellek (requests.memory, limits.memory).
• Depolama Kaynakları (Storage Resources): Persistent Volume Claim (PVC) boyutu (requests.storage).
• Objelerin Sayısı (Count of Objects): Pod'lar, Servisler, Deployment'lar, ConfigMap'ler, Secret'lar, Persistent Volume Claim'ler vb. gibi belirli Kubernetes objelerinin toplam sayısı. Örneğin, bir Namespace'te en fazla 10 Pod ve 5 Deployment olabilir.

Örnek Bir ResourceQuota Tanımı:

Diyelim ki "gelistirme" Namespace'i için aşağıdaki kısıtlamaları uygulamak istiyoruz:

• Toplamda en fazla 2 CPU çekirdeği isteği (request) ve 4 CPU çekirdeği sınırı (limit)
• Toplamda en fazla 4Gi bellek isteği ve 8Gi bellek sınırı
• En fazla 20 Pod ve 5 Servis oluşturulabilir

# gelistirme-quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: gelistirme-kaynak-kotasi
  namespace: gelistirme # Bu kota 'gelistirme' Namespace'ine uygulanacak
spec:
  hard:
    requests.cpu: "2"
    requests.memory: "4Gi"
    limits.cpu: "4"
    limits.memory: "8Gi"
    pods: "20"
    services: "5"

Bu kotayı uygulamak için:

kubectl apply -f gelistirme-quota.yaml

Artık "gelistirme" Namespace'indeki Pod'lar, belirtilen CPU ve bellek sınırlarını aşamayacak ve belirtilen objelerin sayısından fazlasını oluşturamayacaklardır. Bir ekip, bu limitleri aşmaya çalıştığında, Kubernetes Pod'u veya diğer objeyi oluşturmayı reddedecek ve bir hata mesajı dönecektir.

Limit Ranges: Pod/Konteyner Bazında Varsayılan ve Maksimum Değerler

Resource Quotas, Namespace genelinde toplam tüketimi sınırlarken, Limit Ranges ise bir Namespace içindeki tekil Pod'lar veya konteynerler için varsayılan (default) ve maksimum (max) kaynak değerlerini tanımlar. Bu, geliştiricilerin her zaman CPU ve bellek limitlerini belirtmesini sağlamak için faydalıdır, aksi takdirde kaynak isteği belirtilmeyen Pod'lar kümede kaynak israfına yol açabilir.

Limit Range ile şunları ayarlayabilirsiniz:

• Bir konteyner için minimum ve maksimum CPU/bellek isteği (request) ve sınırı (limit).
• Eğer bir Pod veya konteyner kendi kaynak isteğini/sınırını belirtmezse uygulanacak varsayılan CPU/bellek değerleri.

Örnek Bir LimitRange Tanımı:

Şimdi de "gelistirme" Namespace'indeki her bir Pod'un konteynerleri için varsayılan ve maksimum değerleri belirleyelim:

# gelistirme-limitrange.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: gelistirme-limit-araligi
  namespace: gelistirme # Bu limit aralığı 'gelistirme' Namespace'ine uygulanacak
spec:
  limits:
  - default: # Eğer belirtilmezse uygulanacak varsayılanlar
      cpu: 500m
      memory: 512Mi
    defaultRequest: # Eğer belirtilmezse uygulanacak varsayılan istekler
      cpu: 200m
      memory: 256Mi
    max: # Konteyner için maksimum sınırlar
      cpu: 1
      memory: 1Gi
    type: Container

Bu limit aralığını uygulamak için:

kubectl apply -f gelistirme-limitrange.yaml

Bu LimitRange sayesinde, "gelistirme" Namespace'inde oluşturulan her yeni konteyner (kendi kaynak isteğini/sınırını belirtmese bile) otomatik olarak belirli varsayılan değerlere sahip olacak ve hiçbir konteyner belirlenen maksimum değerleri aşamayacaktır. Bu, Resource Quota ile birlikte çalışarak Namespace içindeki kaynak yönetimini çok daha sağlam hale getirir.

Kubernetes Namespaces, Resource Quotas ve Limit Ranges'in birleşimi, küme yöneticilerine kaynaklar üzerinde eşsiz bir kontrol sağlar. Bu sayede, farklı ekipler veya uygulamalar küme kaynaklarını adil bir şekilde paylaşırken, performans sorunları ve güvenlik açıkları minimize edilmiş olur. Her bir Namespace'e özel bu politikaları uygulamak, Kubernetes ortamınızın hem istikrarlı hem de ölçeklenebilir kalmasını güvence altına alır.

Vaka Analizi: Büyük Bir Kuruluşta Geliştirme, Test ve Üretim Ortamlarının Namespaces ile Ayrılması

Birçok büyük ve orta ölçekli kuruluş, yazılım geliştirme süreçlerinde birden fazla ortam (geliştirme, test, hazırlık, üretim) kullanır. Bu ortamların her biri, kendi içinde izole edilmiş bir yapıya sahip olmalıdır. Bir tanesi üzerinde yapılan bir hata veya performans düşüşü, diğerlerini etkilememelidir. Geleneksel olarak bu, ayrı fiziksel veya sanal sunucular kurarak, dolayısıyla yüksek maliyet ve operasyonel karmaşıklıkla sağlanırdı. Ancak Kubernetes Namespaces, bu soruna zarif ve verimli bir çözüm sunar.

Senaryo: Finans Sektöründe Bir Uygulama Ekibi

Hayal edelim ki, "Fintrac" adında, bankacılık ve finans sektörüne hizmet veren büyük bir kuruluşuz. Kuruluşumuz, "Kredi Değerlendirme Sistemi" adında kritik bir mikroservis tabanlı uygulama geliştiriyor. Bu uygulama, geliştirme (dev), test (test) ve üretim (prod) ortamlarında çalışacak. Her ortamın kendine özgü gereksinimleri var:

• Geliştirme (Dev): Geliştiriciler kod yazıp, hızlı iterasyonlar yapıyor. Yeni özellikler test ediliyor, hatalar ayıklanıyor. Kaynak kullanımı esnek olmalı.
• Test (Test): Uygulama, kalibrasyon ve entegrasyon testlerinden geçiyor. Performans ve kararlılık testleri yapılıyor. Gerçekçi verilere yakın test verileri kullanılıyor.
• Üretim (Prod): Canlı kullanıcılar tarafından kullanılan ortam. Yüksek erişilebilirlik, güvenlik ve performans kritik. Herhangi bir kesinti kabul edilemez.

Namespaces Öncesi Karşılaşılan Zorluklar:

• Kaynak Çakışmaları: Her ortam için ayrı bir sanal küme kurulmadığında, aynı isimdeki servisler (örneğin "veri-tabanı-servisi") farklı ortamlar için çakışma yaşayabilir.
• Erişim Kontrolü Zorlukları: Geliştiricilerin üretim ortamına yanlışlıkla erişmesini engellemek veya test mühendislerinin geliştirme ortamındaki değişiklikleri etkilemesini önlemek karmaşıktır.
• Kaynak İsrafı: Ayrı sanal makineler veya kümeler kurmak, donanım kaynaklarının gereksiz yere çoğalmasına ve yüksek maliyetlere yol açar.
• Güvenlik Açıkları: Ortamlar arası izolasyon eksikliği, bir ortamdaki güvenlik zafiyetinin diğerlerini etkilemesine neden olabilir.

Namespaces ile Çözüm: Ortam Başına Bir Namespace

Fintrac, bu sorunları çözmek için Kubernetes kümesini Namespaces kullanarak üç ana mantıksal bölüme ayırmaya karar verir:

1. kredi-dev: Geliştirme ortamı için.
2. kredi-test: Test ortamı için.
3. kredi-prod: Üretim ortamı için.

Uygulama Adımları ve Faydaları:

1. Namespace Oluşturma: Her ortam için özel bir Namespace oluşturulur.

   
   kubectl create namespace kredi-dev
   kubectl create namespace kredi-test
   kubectl create namespace kredi-prod
           

2. Kaynak Dağıtımı: Kredi Değerlendirme Sistemi'nin tüm mikroservisleri (API Gateway, Hesaplama Servisi, Veritabanı vb.), ilgili ortam Namespaces'ine dağıtılır. Örneğin, geliştirme ekibi kendi kodunu kredi-dev Namespace'ine dağıtırken, test ekibi testlerini kredi-test üzerinde yapar.

   
   # credit-service-deployment.yaml (kredi-dev için)
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: credit-service
     namespace: kredi-dev # Sadece bu Namespace'te
   spec:
     # ...
           

   Fayda: Aynı adlı servisler (örneğin credit-service), farklı Namespaces'lerde çakışmadan var olabilir. Geliştiriciler kendi ortamlarında rahatça denemeler yapabilirken, bu denemeler diğer ortamları etkilemez.

3. Erişim Kontrolü (RBAC): Her ekibe, yalnızca kendi ortam Namespaces'inde işlem yapma yetkisi verilir. Örneğin:
   • Geliştirme ekibi üyeleri, kredi-dev Namespace'i üzerinde tam yetkiye sahiptir.
   • Test ekibi üyeleri, kredi-test Namespace'inde Pod'ları yeniden başlatma ve logları okuma yetkisine sahiptir, ancak üretim ortamına erişemezler.
   • Üretim operasyon ekibi, kredi-prod Namespace'inde yüksek yetkiye sahipken, diğer Namespaces'lere sınırlı erişimleri vardır.

   
   # kredi-dev-role.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: dev-full-access
     namespace: kredi-dev
   rules:
     # ... tam erişim kuralları ...
   ---
   # kredi-dev-rolebinding.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: bind-dev-full-access
     namespace: kredi-dev
   subjects:
   - kind: User # veya ServiceAccount/Group
     name: dev-team-lead
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: Role
     name: dev-full-access
     apiGroup: rbac.authorization.k8s.io
           

   Fayda: Yanlışlıkla veya yetkisiz erişimden kaynaklanan güvenlik riskleri ve operasyonel hatalar büyük ölçüde azalır. Her ekip kendi sorumluluk alanında çalışır.

4. Kaynak Kotaları (Resource Quotas) ve Limit Ranges: Her ortama, ihtiyacına uygun kaynak kotaları ve limit aralıkları uygulanır.
   • kredi-dev: Daha esnek kotalar, geliştiricilerin farklı konfigürasyonlar denemesine izin verir.
   • kredi-test: Belirli performans testleri için ayrılmış sabit kaynaklar.
   • kredi-prod: Kesin ve optimize edilmiş kotalar ile en yüksek öncelik.

   
   # kredi-prod-quota.yaml
   apiVersion: v1
   kind: ResourceQuota
   metadata:
     name: prod-quota
     namespace: kredi-prod
   spec:
     hard:
       requests.cpu: "8"
       limits.cpu: "16"
       requests.memory: "16Gi"
       limits.memory: "32Gi"
       pods: "50"
           

   Fayda: Bir ortamdaki kaynak tüketimi, diğer ortamları etkilemez. Geliştirme ortamındaki bir hata, üretim ortamının kaynaklarını tüketmez. Kaynaklar adil bir şekilde dağıtılır ve maliyetler kontrol altında tutulur.

5. Ağ Politikaları (Network Policies): Ortamlar arası iletişimi sıkı bir şekilde kontrol etmek için Network Policies kullanılır. Örneğin, kredi-dev Namespace'indeki Pod'ların kredi-prod Namespace'indeki veritabanı ile direkt iletişim kurması engellenir.

   Fayda: Ek bir güvenlik katmanı sağlar ve ortamlar arası istenmeyen veri akışını önler.

Sonuç: Namespaces ile Esnek, Güvenli ve Verimli Ortam Yönetimi

Fintrac örneği, Kubernetes Namespaces'in büyük bir kuruluşta geliştirme, test ve üretim ortamlarını nasıl etkin bir şekilde ayırabileceğini açıkça göstermektedir. Bu yaklaşım:

• Operasyonel karmaşıklığı azaltır.
• Güvenliği artırır.
• Kaynakların daha verimli kullanılmasını sağlar.
• Ekiplerin kendi sorumluluk alanlarında daha bağımsız ve üretken olmalarına olanak tanır.

Tek bir Kubernetes kümesi üzerinde birden fazla mantıksal ortam oluşturarak, hem maliyetleri düşürmek hem de süreçleri modernize etmek mümkün hale gelir. Namespaces, Kubernetes'in çok kullanıcılı ve çok ortamlı senaryolardaki gücünü ortaya koyan temel bir yapıdır.

Sonuç: Kubernetes Namespaces ile Daha Düzenli ve Güvenli Bir Ortam Mümkün mü?

Bu makale boyunca, Kubernetes Namespaces'in ne olduğunu, neden bu kadar kritik bir rol oynadığını ve gerçek dünya senaryolarında bize ne gibi avantajlar sağladığını detaylı bir şekilde inceledik. Gördük ki, Namespaces sadece bir adlandırma kolaylığı sağlamakla kalmıyor, aynı zamanda Kubernetes kümelerinde kaynak izolasyonu, erişim kontrolü, güvenlik ve verimli yönetim için vazgeçilmez bir temel oluşturuyor. Büyük ve karmaşık ortamlardan, küçük geliştirme ekiplerinin ihtiyaçlarına kadar geniş bir yelpazede, Namespaces'in sağladığı faydalar yadsınamaz.

İster yeni bir uygulama geliştiriyor olun, ister mevcut altyapınızı Kubernetes'e taşıyor olun, Namespaces'i doğru bir şekilde kullanmak, operasyonel yükü önemli ölçüde azaltacak, ekipler arasındaki işbirliğini artıracak ve genel sistem güvenliğini güçlendirecektir. Farklı ortamlar için ayrı Namespaces oluşturmak, her ekibe kendi "kum havuzunu" sağlamak ve kaynakları adil bir şekilde dağıtmak, Kubernetes ekosisteminin en iyi pratikleri arasında yer alır. Unutmayın ki, düzenli ve güvenli bir Kubernetes ortamı, başarılı uygulama dağıtımlarının ve sürdürülebilir bir DevOps kültürünün temelini oluşturur. Bu nedenle, Namespaces'i sadece bir özellik olarak değil, Kubernetes stratejinizin merkezi bir parçası olarak benimsemeniz, uzun vadede size büyük kazançlar sağlayacaktır.

Sıkça Sorulan Sorular (SSS)

Kubernetes Namespaces hakkında aklınıza takılabilecek bazı yaygın sorular ve cevapları:

1. Bir Namespace'teki Pod, başka bir Namespace'teki Pod ile iletişim kurabilir mi?

Evet, Namespaces arası iletişim mümkündür ancak varsayılan olarak izole edilmişlerdir. Bir Pod, farklı bir Namespace'teki bir servise FQDN (Tam Nitelikli Alan Adı) kullanarak erişebilir. Örneğin: ..svc.cluster.local. Ancak, güvenlik için bu iletişimin Network Policies (Ağ Politikaları) ile kontrol altında tutulması şiddetle önerilir.

2. Bir Namespace'i silersem ne olur?

Bir Namespace'i sildiğinizde, o Namespace içindeki tüm kaynaklar (Pod'lar, Deployment'lar, Servisler, ConfigMap'ler, Secret'lar, vb.) geri dönülemez bir şekilde silinir. Bu işlem geri alınamaz, bu yüzden dikkatli olunmalıdır. Silme işlemi, Namespace'in büyüklüğüne ve içindeki kaynakların sayısına bağlı olarak biraz zaman alabilir.

3. Her uygulama kendi Namespace'ine mi sahip olmalı?

Her uygulamanın kendi özel Namespace'ine sahip olması en iyi pratiklerden biridir, özellikle birden fazla uygulamanız veya mikroservis grubunuz varsa. Bu, adlandırma çakışmalarını önler, kaynakları daha kolay yönetmenizi sağlar, erişim kontrolünü basitleştirir ve bir uygulamanın diğerini etkilemesini engeller. Geliştirme, test ve üretim ortamlarını ayırmak için de ayrı Namespaces kullanmak yaygın bir yaklaşımdır.

4. Namespaces bir güvenlik sınırı mıdır?

Evet, Namespaces güçlü bir mantıksal güvenlik sınırı sağlar. RBAC (Rol Tabanlı Erişim Kontrolü) ile birleştirildiğinde, kullanıcıların veya hizmet hesaplarının yalnızca belirli bir Namespace'teki kaynaklara erişmesini veya bunları yönetmesini sağlayabilirsiniz. Ancak Namespaces tek başına fiziksel izolasyon sağlamaz; ek güvenlik katmanları (örneğin Network Policies) ile desteklenmelidirler.

5. "default" Namespace'i ne işe yarar?

default Namespace'i, Kubernetes kümesi kurulduğunda otomatik olarak oluşturulan ve bir Namespace belirtilmediğinde tüm kaynakların varsayılan olarak dağıtıldığı Namespace'tir. Küçük ölçekli projeler veya hızlı denemeler için kullanışlı olabilir. Ancak, üretim ortamlarında veya çok kullanıcılı kümelerde, kaynakları daha iyi organize etmek ve izole etmek için kendi özel Namespaces'lerinizi oluşturmanız ve kullanmanız önerilir.