Kubernetes Kaynak Kotası: Çok Kiracılı Ortamlarda Adil Dağıtım

Kubernetes kümelerinde kaynak yönetimi, özellikle birden fazla ekibin veya uygulamanın aynı altyapıyı paylaştığı çok kiracılı ortamlarda kritik bir konudur. Bu karmaşık senaryolarda kaynakların adil ve verimli bir şekilde dağıtılması, hem maliyet kontrolü hem de uygulama istikrarı açısından büyük önem taşır. Peki, bir uygulamanın diğerini ezmesini nasıl engeller, kaynak israfını nasıl önleriz? İşte bu noktada Kubernetes Kaynak Kotaları devreye giriyor.

Modern yazılım geliştirme yaklaşımları, genellikle mikro servis mimarileri ve kapsayıcılaştırma teknolojileri etrafında şekillenir. Kubernetes, bu kapsayıcı iş yüklerini yönetmek için sektör standardı haline gelmiştir. Ancak, birden fazla ekip veya müşteri aynı Kubernetes kümesini paylaştığında, kaynakların adil bir şekilde dağıtılması ve “gürültülü komşu” sorunlarının önlenmesi zorunlu hale gelir.

Bir geliştirme ekibinin yanlışlıkla veya bilinçli olarak kümenin tüm CPU veya bellek kaynaklarını tüketmesi, diğer kritik uygulamaların performansını olumsuz etkileyebilir, hatta hizmet dışı kalmasına neden olabilir. Bu durum, yalnızca operasyonel sorunlara yol açmakla kalmaz, aynı zamanda maliyetleri de gereksiz yere artırır. İşte bu senaryoları engellemek için Kubernetes, “Kaynak Kotaları” (Resource Quotas) mekanizmasını sunar.

Kaynak Kotası, belirli bir Kubernetes isim alanı (namespace) içinde tüketilebilecek toplam kaynak miktarını sınırlamanızı sağlayan bir araçtır. Bu kotalar, CPU, bellek gibi işlem kaynaklarından, pod sayısı, servis sayısı gibi nesne sayısına ve hatta PersistentVolumeClaim (PVC) sayısına kadar geniş bir yelpazeyi kapsar. Bu mekanizma sayesinde, her bir ekibin veya uygulamanın kendi “adil payına” sahip olması garantilenir ve küme genelinde istikrarlı bir performans ortamı sağlanır. Kotalar, sadece toplam tüketimi değil, aynı zamanda her bir pod’un talep edebileceği minimum (requests) ve maksimum (limits) kaynakları da kontrol eden LimitRange objeleriyle birlikte kullanıldığında çok daha etkili hale gelir.

Kaynak kotaları, çok kiracılı ortamlarda hem hizmet kalitesini korumak hem de maliyetleri optimize etmek için vazgeçilmez bir araçtır. Ayrıca, geliştiricileri kaynakları daha verimli kullanmaya teşvik eder ve uygulamalarını daha optimize bir şekilde tasarlamalarına yardımcı olur. Kısacası, Kubernetes Kaynak Kotaları, küme yöneticilerinin ve geliştiricilerin elini güçlendiren, daha öngörülebilir ve kontrol edilebilir bir altyapı sunan kritik bir bileşendir.

Kubernetes Kaynak Kotaları Nasıl Çalışır? Mekanizma ve Türleri

Kubernetes Kaynak Kotaları, küme içindeki kaynakların tüketimini kontrol etmek için güçlü bir mekanizma sunar. Bu kotalar, bir Ad Alanı (Namespace) bazında uygulanır ve bu ad alanı içindeki tüm kaynaklar üzerinde etkili olur. Başka bir deyişle, bir kota uygulandığında, o ad alanındaki tüm podlar, servisler veya PersistentVolumeClaim’ler, tanımlanmış limitler dahilinde kalmak zorundadır.

Bir Kaynak Kotası oluşturduğunuzda, Kubernetes API Sunucusu (API Server), o ad alanına yönelik tüm oluşturma ve güncelleme isteklerini bu kotalara göre doğrular. Eğer bir işlem (örneğin, yeni bir pod oluşturma) tanımlanmış kotayı aşacaksa, istek reddedilir ve kullanıcıya ilgili hata mesajı gönderilir. Bu sayede, kaynakların belirlenen sınırlar içinde kalması sağlanır ve bir ad alanının diğerlerini “boğması” engellenir.

Kubernetes, farklı türlerde kaynak kotası uygulamalarına izin verir. Bunları temel olarak üç ana kategoriye ayırabiliriz:

1. Hesaplama Kaynak Kotaları (Compute Resource Quotas): Bu tür kotalar, CPU ve bellek gibi temel işlem kaynaklarını sınırlar. Hem requests (garantilenen minimum kaynak) hem de limits (izin verilen maksimum kaynak) için ayrı ayrı tanımlanabilir. Örneğin, bir ad alanının toplamda ne kadar CPU veya bellek talep edebileceğini veya kullanabileceğini belirleyebilirsiniz.
   • requests.cpu: Ad alanı içindeki tüm pod’ların talep ettiği toplam CPU miktarının üst sınırı.
   • limits.cpu: Ad alanı içindeki tüm pod’ların kullanabileceği toplam CPU miktarının üst sınırı.
   • requests.memory: Ad alanı içindeki tüm pod’ların talep ettiği toplam bellek miktarının üst sınırı.
   • limits.memory: Ad alanı içindeki tüm pod’ların kullanabileceği toplam bellek miktarının üst sınırı.
2. Nesne Sayısı Kotaları (Count Quotas): Bu kotalar, belirli Kubernetes kaynak nesnelerinin (objelerinin) ad alanı içinde oluşturulabilecek maksimum sayısını sınırlar. Bu, bir ad alanının çok sayıda gereksiz veya yanlış yapılandırılmış kaynakla doldurulmasını önlemek için faydalıdır.
   • pods: Ad alanı içindeki maksimum pod sayısı.
   • services: Ad alanı içindeki maksimum servis sayısı.
   • configmaps: Ad alanı içindeki maksimum ConfigMap sayısı.
   • replicationcontrollers: Ad alanı içindeki maksimum ReplicationController sayısı.
   • secrets: Ad alanı içindeki maksimum Secret sayısı.
   • persistentvolumeclaims: Ad alanı içindeki maksimum PersistentVolumeClaim (PVC) sayısı.
3. Depolama Kaynak Kotaları (Storage Resource Quotas): Bu kotalar, ad alanı içindeki PersistentVolumeClaim’lerin (PVC’ler) kullanabileceği toplam depolama miktarını ve hatta depolama sınıfına göre de limit koymanıza olanak tanır. Bu, depolama maliyetlerini kontrol etmek ve diskin tükenmesini engellemek için kritik öneme sahiptir.
   • requests.storage: Ad alanı içindeki tüm PVC’lerin talep ettiği toplam depolama miktarının üst sınırı.
   • persistentvolumeclaims.storageclass.storage.k8s.io/[storage-class-name]: Belirli bir depolama sınıfına ait PVC’lerin talep ettiği toplam depolama miktarı.

Kaynak Kotaları, tek başına etkili olmakla birlikte, genellikle LimitRange kaynakları ile birlikte kullanılır. LimitRange, ad alanı içindeki *her bir* pod veya kapsayıcı için varsayılan ve maksimum/minimum kaynak taleplerini ve limitlerini belirler. Kaynak Kotası, ad alanının *toplam* tüketimini sınırlarken, LimitRange *tekil* kaynakların davranışını kontrol eder. Bu iki mekanizma birlikte çalışarak, bir Kubernetes kümesinde son derece hassas ve adil bir kaynak dağıtımı sağlar.

Özetle, Kubernetes Kaynak Kotaları, kümenizin istikrarını ve verimliliğini korumak için vazgeçilmez bir araçtır. Kaynakları adil bir şekilde bölüştürerek, her ekibin belirlenen sınırlar içinde çalışmasını sağlar ve “gürültülü komşu” sendromunu ortadan kaldırır. Bu da daha öngörülebilir performans, daha düşük operasyonel maliyetler ve genel olarak daha sağlıklı bir Kubernetes ortamı anlamına gelir.

Kaynak Kotası Uygulama Adımları: Kapsamlı Bir Uygulamalı Örnek

Kaynak kotalarını Kubernetes kümenizde uygulamak, birkaç basit adımdan oluşur ancak dikkatli planlama gerektirir. Bu bölümde, adım adım bir Kaynak Kotası’nın nasıl tanımlanacağını, uygulanacağını ve izleneceğini örneklerle inceleyeceğiz. Amacımız, yeni bir “geliştirme” isim alanı için belirli kaynak kotaları tanımlayarak, bu ad alanının kümenin diğer bölümlerini olumsuz etkilemesini önlemek olacaktır.

Adım 1: İsim Alanı Oluşturma

Öncelikle, kaynak kotalarını uygulayacağımız bir isim alanına ihtiyacımız var. Eğer zaten bir isim alanınız yoksa, aşağıdaki YAML dosyasını kullanarak bir tane oluşturabilirsiniz:

apiVersion: v1
kind: Namespace
metadata:
  name: dev-projesi

Bu dosyayı dev-projesi-ns.yaml olarak kaydedin ve aşağıdaki komutla uygulayın:

kubectl apply -f dev-projesi-ns.yaml

Bu komut, dev-projesi adında yeni bir isim alanı oluşturacaktır. Bu, ekiplerin ve projelerin kaynaklarını izole etmenin ilk adımıdır.

Adım 2: Kaynak Kotası Tanımlama

Şimdi, dev-projesi isim alanı için kaynak kotalarını tanımlayalım. Bu örnekte, ad alanı içinde toplamda 2 CPU, 2 GiB bellek, 10 pod ve 5 servis oluşturulmasına izin vereceğiz. Ayrıca, 50 GiB'ye kadar depolama alanı talep edilebileceğini de belirleyeceğiz.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev-projesi
spec:
  hard:
    pods: "10"
    services: "5"
    requests.cpu: "2"
    requests.memory: "2Gi"
    limits.cpu: "4"
    limits.memory: "4Gi"
    requests.storage: "50Gi"
    persistentvolumeclaims: "3"

Bu YAML dosyasını dev-quota.yaml olarak kaydedin. Yukarıdaki tanımda:

• pods: "10": Ad alanı içinde en fazla 10 pod bulunabilir.
• services: "5": Ad alanı içinde en fazla 5 servis oluşturulabilir.
• requests.cpu: "2": Tüm pod'ların toplam CPU talep miktarı 2 çekirdeği geçemez.
• requests.memory: "2Gi": Tüm pod'ların toplam bellek talep miktarı 2 GiB'ı geçemez.
• limits.cpu: "4": Tüm pod'ların toplam CPU limit miktarı 4 çekirdeği geçemez.
• limits.memory: "4Gi": Tüm pod'ların toplam bellek limit miktarı 4 GiB'ı geçemez.
• requests.storage: "50Gi": Tüm PersistentVolumeClaim'lerin toplam depolama talep miktarı 50 GiB'ı geçemez.
• persistentvolumeclaims: "3": Ad alanı içinde en fazla 3 adet PersistentVolumeClaim oluşturulabilir.

Adım 3: Kaynak Kotasını Uygulama

Tanımladığınız kotayı kümenize uygulamak için aşağıdaki komutu kullanın:

kubectl apply -f dev-quota.yaml

Artık dev-projesi isim alanı bu kotalara tabidir.

Adım 4: Kotanın Durumunu Kontrol Etme

Oluşturulan kotanın mevcut durumunu ve ne kadarının kullanıldığını görmek için describe komutunu kullanabilirsiniz:

kubectl describe resourcequota dev-quota -n dev-projesi

Çıktı aşağıdaki gibi olacaktır (kullanımınıza göre farklılık gösterebilir):

Name:           dev-quota
Namespace:      dev-projesi
Resource        Used    Hard
--------        ----    ----
limits.cpu      0       4
limits.memory   0       4Gi
persistentvolumeclaims  0       3
pods            0       10
requests.cpu    0       2
requests.memory 0       2Gi
requests.storage        0       50Gi
services        0       5

Used sütunu, ad alanında kullanılan kaynak miktarını, Hard sütunu ise tanımlanan maksimum limiti gösterir. Şu anda 0 çünkü henüz bu ad alanına hiçbir pod veya kaynak dağıtmadık.

Adım 5: Kota Kısıtlamasını Deneme (Pod Oluşturma)

Şimdi bir pod oluşturalım ve kotanın nasıl çalıştığını görelim. Önce kotaya uygun bir pod oluşturalım:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod-1
  namespace: dev-projesi
spec:
  containers:
  - name: my-container
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "250m"
      limits:
        memory: "512Mi"
        cpu: "500m"

Bu pod'u test-pod-1.yaml olarak kaydedin ve uygulayın:

kubectl apply -f test-pod-1.yaml

Bu pod sorunsuz bir şekilde oluşturulacaktır. Şimdi kotanın durumunu tekrar kontrol edin:

kubectl describe resourcequota dev-quota -n dev-projesi

Çıktıda Used değerlerinin arttığını göreceksiniz:

Name:           dev-quota
Namespace:      dev-projesi
Resource        Used    Hard
--------        ----    ----
limits.cpu      500m    4
limits.memory   512Mi   4Gi
persistentvolumeclaims  0       3
pods            1       10
requests.cpu    250m    2
requests.memory 256Mi   2Gi
requests.storage        0       50Gi
services        0       5

Şimdi kotayı aşmaya çalışan bir pod oluşturalım. Örneğin, toplam CPU isteğini 2 çekirdeği aşacak şekilde bir pod deneyelim:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod-2-exceeding
  namespace: dev-projesi
spec:
  containers:
  - name: my-container
    image: busybox
    command: ["sh", "-c", "echo Hello Kubernetes! && sleep 3600"]
    resources:
      requests:
        memory: "1.8Gi" # Kalan 2Gi - 256Mi = 1.75Gi. Bu, 1.8Gi talep ettiği için kotayı aşacak.
        cpu: "1.9" # Kalan 2 CPU - 250m = 1.75 CPU. Bu, 1.9 talep ettiği için kotayı aşacak.
      limits:
        memory: "2Gi"
        cpu: "2"

Bu YAML dosyasını test-pod-2-exceeding.yaml olarak kaydedin ve uygulamayı deneyin:

kubectl apply -f test-pod-2-exceeding.yaml

Beklediğimiz gibi, bu komut hata verecektir. Çıktı, aşağıdakine benzer bir mesaj içerecektir:

Error from server (Forbidden): pods "test-pod-2-exceeding" is forbidden: exceeded quota: dev-quota, requested: requests.cpu=1900m, requests.memory=1800Mi, total: requests.cpu=2150m, requests.memory=2056Mi, used: requests.cpu=250m, requests.memory=256Mi, limited: requests.cpu=2, requests.memory=2Gi

Bu hata mesajı, belirlediğimiz CPU ve bellek requests kotalarının aşıldığını açıkça gösterir. Böylece, Kaynak Kotası'nın başarıyla çalıştığını ve ad alanı içindeki kaynak tüketimini etkin bir şekilde sınırladığını görmüş olduk.

Bu uygulamalı örnek, Kaynak Kotaları'nı nasıl tanımlayacağınızı, uygulayacağınızı ve doğrulayacağınızı temel düzeyde göstermektedir. Bu yöntemleri kullanarak, çok kiracılı Kubernetes kümelerinizde kaynakların adil ve kontrollü bir şekilde dağıtımını sağlayabilirsiniz.

Gerçek Dünya Senaryosu: Geliştirme ve Üretim Ortamları Arasında Kaynak Dağıtımı

Büyük şirketlerde, genellikle aynı Kubernetes kümesi üzerinde farklı ortamlar (geliştirme, test, hazırlık ve üretim) bulunur. Bu ortamların her birinin kendine özgü kaynak ihtiyaçları ve öncelikleri vardır. Geliştirme ortamları genellikle daha esnek ve kaynak açısından daha az kısıtlı olabilirken, üretim ortamları istikrar ve performans açısından yüksek garantilere ihtiyaç duyar. Kaynak Kotaları, bu farklı ihtiyaçları karşılamak ve kaynak çakışmalarını önlemek için ideal bir çözümdür.

Diyelim ki bir teknoloji şirketi olan "GlobalTech", tek bir büyük Kubernetes kümesini kullanıyor. Bu kümede dev, staging ve prod olmak üzere üç ana isim alanı bulunuyor. GlobalTech'in yöneticileri, geliştirme ekibinin yanlışlıkla üretim ortamının kaynaklarını tüketmesini, hazırlık ortamının ise yeterli test kaynağına sahip olmasını sağlamak istiyorlar. İşte bu durumda Kaynak Kotaları devreye giriyor:

1. dev (Geliştirme Ortamı) için Kotalar:

   Geliştirme ortamı, yeni özelliklerin test edildiği, hata ayıklama yapılan ve genellikle kaynak taleplerinin değişken olduğu bir yerdir. Burada aşırı sıkı kotalar geliştirmeyi yavaşlatabilir, ancak tamamen kontrolsüz bırakmak da kaynak israfına yol açabilir. Bu nedenle, daha esnek ama yine de sınırlayıcı bir yaklaşım benimsenir.

   
   apiVersion: v1
   kind: ResourceQuota
   metadata:
     name: dev-quota-globaltech
     namespace: dev
   spec:
     hard:
       pods: "30"
       requests.cpu: "8"
       requests.memory: "16Gi"
       limits.cpu: "12"
       limits.memory: "24Gi"
       requests.storage: "100Gi"
       persistentvolumeclaims: "10"
   

   Bu kota, geliştirme ekibine makul bir hareket alanı tanırken, kümenin genel kaynak havuzunu aşırı derecede zorlamalarını engeller.

2. staging (Hazırlık Ortamı) için Kotalar:

   Hazırlık ortamı, genellikle üretim ortamının bir kopyasıdır ve dağıtımdan önceki son testlerin yapıldığı yerdir. Bu nedenle, buradaki kaynaklar, üretim ortamının performansını taklit edebilecek kadar yeterli olmalıdır, ancak yine de bir üretim ortamı kadar geniş olmayabilir.

   
   apiVersion: v1
   kind: ResourceQuota
   metadata:
     name: staging-quota-globaltech
     namespace: staging
   spec:
     hard:
       pods: "20"
       requests.cpu: "12"
       requests.memory: "24Gi"
       limits.cpu: "16"
       limits.memory: "32Gi"
       requests.storage: "150Gi"
       persistentvolumeclaims: "5"
   

   Hazırlık ortamının kotaları, geliştirme ortamından daha yüksek, üretim ortamından ise biraz daha düşük olarak belirlenmiştir, böylece gerçekçi yük testleri yapılabilir.

3. prod (Üretim Ortamı) için Kotalar:

   Üretim ortamı, şirketin ana gelir kaynaklarını ve müşteri hizmetlerini barındırdığı için en yüksek önceliğe sahiptir. Buradaki kaynaklar, uygulamaların sürekli olarak yüksek performans ve kullanılabilirlikle çalışmasını sağlamak üzere ayrılmıştır. Bu ortam için genellikle daha cömert kotalar veya özel bir küme/düğümler ayrılır, ancak aynı küme içinde ise yine de bir üst sınır belirlemek faydalıdır.

   
   apiVersion: v1
   kind: ResourceQuota
   metadata:
     name: prod-quota-globaltech
     namespace: prod
   spec:
     hard:
       pods: "50"
       requests.cpu: "24"
       requests.memory: "48Gi"
       limits.cpu: "32"
       limits.memory: "64Gi"
       requests.storage: "500Gi"
       persistentvolumeclaims: "15"
   

   Üretim ortamı için ayrılan kotalar, en yüksek kaynak gereksinimlerini karşılayacak şekilde ayarlanır. Bu sayede, diğer ortamların kaynak problemleri, üretimdeki uygulamaları etkilemez.

Bu senaryo, Kaynak Kotaları'nın farklı iş yükleri ve önceliklere sahip ortamlarda nasıl etkin bir şekilde kullanılabileceğini göstermektedir. Her ortamın kendi özel ihtiyaçlarına göre kotalar belirleyerek, GlobalTech, küme kaynaklarını adil, güvenli ve verimli bir şekilde yönetebilmektedir. Bu yaklaşım, hem geliştirici verimliliğini artırır hem de kritik üretim hizmetlerinin istikrarını garanti altına alır.

İleri Düzey Kullanım İpuçları ve En İyi Uygulamalar

Kubernetes Kaynak Kotaları, basit bir yapılandırmadan çok daha fazlasını sunar. Deneyimli kullanıcılar için, bu güçlü aracı daha da verimli hale getirecek bazı ileri düzey ipuçları ve en iyi uygulamalar bulunmaktadır. Kaynakları daha etkin yönetmek ve olası sorunların önüne geçmek adına bu stratejileri göz önünde bulundurmak önemlidir.

Resource Quota ve LimitRange'i Birlikte Kullanma

Kaynak Kotaları, bir isim alanındaki toplam kaynak tüketimini sınırlar. Ancak, bu isim alanı içindeki her bir Pod'un veya kapsayıcının ne kadar kaynak talep edebileceğini veya kullanabileceğini kontrol etmez. İşte bu noktada LimitRange devreye girer. LimitRange, bir isim alanında oluşturulan tüm Pod'lar için varsayılan kaynak isteklerini (requests) ve limitlerini (limits) zorlar ve ayrıca her bir kapsayıcının alabileceği minimum ve maksimum kaynakları da belirler.

Neden Birlikte Kullanmalısınız?

• Granüler Kontrol: Resource Quota isim alanı düzeyinde "büyük resmi" yönetirken, LimitRange her bir bireysel Pod'un "mikro" düzeydeki davranışını kontrol eder. Bu sayede, bir uygulamanın kotayı aşmadan dahi tek bir Pod'da aşırı kaynak kullanmasının önüne geçebilirsiniz.
• Varsayılan Değerler: LimitRange, geliştiricilerin her Pod tanımına kaynak istekleri ve limitleri eklemesini zorunlu kılar veya otomatik olarak varsayılan değerler atar. Bu, hatalı yapılandırmaları önler.
• Tutarlılık: Kümedeki tüm Pod'ların belirli standartlara uygun kaynak talep etmesini ve kullanmasını sağlar, bu da küme genelinde daha iyi planlama ve kaynak dağıtımı anlamına gelir.

Örnek bir LimitRange tanımı:

apiVersion: v1
kind: LimitRange
metadata:
  name: default-container-limits
  namespace: dev-projesi
spec:
  limits:
  - default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 250m
      memory: 256Mi
    max:
      cpu: 1
      memory: 1Gi
    type: Container

Bu LimitRange, dev-projesi isim alanındaki tüm kapsayıcılara varsayılan 250m CPU isteği ve 256Mi bellek isteği atar. Ayrıca, her kapsayıcı için maksimum 1 CPU ve 1 GiB bellek limiti belirler.

PersistentVolumeClaim (PVC) Kotalarını Yönetme

Depolama kaynakları da, özellikle bulut ortamlarında, önemli bir maliyet faktörü olabilir. Kaynak Kotaları, depolama alanı taleplerini de kontrol etmenizi sağlar. requests.storage ile toplam depolama miktarını, persistentvolumeclaims ile de PVC sayısını sınırlayabilirsiniz. Daha da önemlisi, belirli StorageClass'lara göre kota belirleyebilirsiniz:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-quota
  namespace: prod-data
spec:
  hard:
    requests.storage: "2Ti"
    persistentvolumeclaims: "20"
    storageclasses.storage.k8s.io/premium-ssd: "500Gi" # Sadece premium-ssd sınıfı için 500Gi limit
    persistentvolumeclaims.storageclasses.storage.k8s.io/premium-ssd: "5" # premium-ssd sınıfından en fazla 5 PVC

Bu, farklı depolama katmanlarının maliyet ve performans dengesini yönetmenize yardımcı olur.

Kotaları İzleme ve Uyarı Sistemleri

Kotaları tanımlamak iyi bir başlangıçtır, ancak bunları aktif olarak izlemek ve sınırların aşılması durumunda uyarı almak çok daha kritiktir. Prometheus ve Grafana gibi izleme araçları, Kaynak Kotaları'nın kullanım metriklerini toplamak ve görselleştirmek için mükemmeldir. Kubernetes API'si, Kaynak Kotası kullanımını Used ve Hard alanları aracılığıyla gösterir. Bu verileri düzenli olarak sorgulayarak veya bir izleme sistemi entegre ederek:

• Kotanın ne kadarının kullanıldığını gerçek zamanlı olarak görebilirsiniz.
• Kotalar dolmaya yaklaştığında proaktif uyarılar alabilirsiniz (örneğin, %80'ine ulaşıldığında).
• Hangi isim alanlarının kaynaklara en çok ihtiyaç duyduğunu belirleyerek gelecekteki kapasite planlamasını yapabilirsiniz.

Kota Boyutlandırma Stratejileri

Kotaları belirlerken "tek beden herkese uyar" yaklaşımından kaçınılmalıdır. Her takımın veya uygulamanın farklı ihtiyaçları vardır. Başarılı bir kota stratejisi için:

• Geçmiş Verileri Analiz Edin: Mevcut veya geçmiş kaynak kullanım verilerini (eğer varsa) analiz ederek gerçekçi temel çizgiler belirleyin.
• Geliştiricilerle İletişim Kurun: Her ekibin kendi ihtiyaçlarını ve beklentilerini anlamak için onlarla konuşun. Kotaların neden uygulandığını ve nasıl optimize edebileceklerini açıklayın.
• İteratif Yaklaşım: Kotaları başlangıçta biraz daha cömert belirleyip, zamanla kullanımı gözlemleyerek kademeli olarak sıkılaştırın. Anında çok katı kotalar, geliştirici direnci yaratabilir.
• Uygulama Yaşam Döngüsünü Göz Önünde Bulundurun: Geliştirme ortamları için daha esnek, üretim ortamları için daha garanti odaklı kotalar tanımlayın.

Bu ileri düzey ipuçları ve en iyi uygulamalar, Kubernetes Kaynak Kotaları'ndan maksimum fayda sağlamanıza yardımcı olacaktır. Doğru uygulandığında, kotalar sadece kaynak tüketimini kontrol etmekle kalmaz, aynı zamanda küme genelinde daha iyi bir yönetim disiplini ve operasyonel verimlilik sağlar.

Vaka Analizi: Büyük Bir Kuruluşta Kaynak İsrafını Önleme ve Maliyet Optimizasyonu

Büyük ölçekli kuruluşlar, teknolojik altyapılarını yönetirken genellikle karmaşık zorluklarla karşılaşırlar. Özellikle birden fazla iş biriminin ve yüzlerce geliştiricinin aynı Kubernetes kümelerini paylaştığı durumlarda, kaynak israfı ve öngörülemeyen maliyet artışları yaygın bir problem haline gelebilir. "FinansGlobal" adında küresel bir bankacılık ve finans kuruluşu, bu sorunlarla yüzleşen tipik bir örnekti.

Problemler:

• Kaynak Çatışmaları: Farklı geliştirme ekipleri (kredi, yatırım, mobil bankacılık vb.) aynı Kubernetes kümesinde çalışıyordu. Bir ekibin yüksek kaynak tüketen testleri, diğer kritik uygulamaların performansını düşürüyor, hatta bazı hizmetlerin kesintiye uğramasına neden oluyordu.
• Maliyet Artışları: Kaynak kullanımı kontrolsüz olduğu için, küme yöneticileri sürekli olarak yeni düğümler eklemek zorunda kalıyordu. Bu durum, aylık bulut faturasının beklenenden çok daha yüksek gelmesine yol açıyordu. Boşta duran veya verimsiz kullanılan kaynaklar ciddi bir maliyet kalemine dönüşmüştü.
• Öngörülemezlik: Hangi uygulamanın ne kadar kaynak tüketeceği belirsizdi, bu da kapasite planlamasını imkansız hale getiriyordu. Geliştirme ve test süreçleri sık sık kaynak yetersizliği nedeniyle sekteye uğruyordu.
• Güvenlik Riskleri: Kaynakların kontrolsüz dağıtımı, bir ad alanındaki sorunların tüm kümeye yayılma riskini taşıyordu.

Uygulanan Çözüm: Kubernetes Kaynak Kotaları ve LimitRange

FinansGlobal'ın DevOps ekibi, bu sorunları çözmek için Kubernetes Kaynak Kotaları ve LimitRange kombinasyonunu stratejik olarak uygulamaya karar verdi. Amaç, her iş birimi için ayrı ad alanları oluşturmak ve bu ad alanlarına özel, adil ve öngörülebilir kaynak limitleri getirmekti.

1. Ad Alanı Ayırma: Her bir iş birimi ve ortam (Dev, QA, Prod) için ayrı Kubernetes ad alanları tanımlandı. Örneğin, kredi-dev, kredi-prod, yatirim-dev, yatirim-prod gibi.
2. Kapsamlı Kaynak Kotası Tanımlamaları: Her ad alanı için özel Kaynak Kotaları tanımlandı. Bu kotalar şunları içeriyordu:
   • CPU ve Bellek: Her ad alanı için toplam CPU ve bellek requests ve limits değerleri belirlendi. Üretim ad alanlarına daha yüksek garantili kaynaklar (requests) ayrılırken, geliştirme ad alanlarına daha esnek ama yine de sınırlı kotalar uygulandı.
   • Nesne Sayıları: Her ad alanında oluşturulabilecek maksimum Pod, Servis ve ConfigMap sayısı sınırlanarak gereksiz kaynak şişkinliği önlendi.
   • Depolama Kotaları: Özellikle veri yoğun uygulamalar için, her ad alanına atanabilecek toplam depolama miktarı ve PVC sayısı sınırlandırıldı. Farklı StorageClass'lar için de özel kotalar uygulandı (örneğin, "premium-ssd" için daha sıkı limitler).
3. LimitRange Uygulaması: Her ad alanında, her bir Pod'un talep edebileceği ve kullanabileceği minimum/maksimum kaynakları belirleyen LimitRange objeleri de uygulandı. Bu, geliştiricilerin her Pod'a makul kaynak istekleri ve limitleri atamasını zorunlu kıldı, böylece küçük Pod'lar dahi aşırı kaynak tüketmiyordu.
4. İzleme ve Uyarı Sistemleri: Prometheus ve Grafana kullanılarak Kaynak Kotaları'nın anlık kullanımı izlendi. Kotalar %80 doluluğa ulaştığında otomatik uyarılar gönderilerek, ekiplerin proaktif olarak kaynaklarını optimize etmeleri veya ek kaynak talebinde bulunmaları sağlandı.

Elde Edilen Sonuçlar:

Bu stratejinin uygulanmasıyla FinansGlobal, önemli faydalar elde etti:

• Maliyet Optimizasyonu: En büyük kazanım, bulut maliyetlerinde gözle görülür bir düşüş oldu. Kaynak israfı azaldı ve gereksiz düğüm eklemelerinin önüne geçildi. Aylık fatura %20 oranında azaldı.
• Artan İstikrar ve Güvenilirlik: Üretim ortamlarındaki uygulamaların performansı ve istikrarı önemli ölçüde arttı. Kaynak çatışmaları minimuma indi ve hizmet kesintileri azaldı.
• Öngörülebilir Kapasite Planlaması: Kaynak kullanımı daha öngörülebilir hale geldiği için, DevOps ekibi gelecekteki kapasite ihtiyaçlarını daha doğru bir şekilde planlayabildi.
• Geliştirici Sorumluluğu: Kotalar, geliştiricileri uygulamalarını daha kaynak dostu bir şekilde tasarlamaya ve optimize etmeye teşvik etti. Artık her ekip, kendi kaynak bütçesi dahilinde çalışmak zorundaydı.
• İş Birimleri Arası Adil Dağıtım: Her iş biriminin, tanımlanmış adil kaynak payına sahip olduğu ve diğerlerinin kaynaklarını "çalmasının" engellendiği bir ortam oluştu.

FinansGlobal'ın deneyimi, Kubernetes Kaynak Kotaları'nın sadece teknik bir araç olmadığını, aynı zamanda büyük ölçekli kuruluşlarda operasyonel verimliliği, maliyet kontrolünü ve iş birimleri arası adil kaynak dağıtımını sağlayan stratejik bir yönetim aracı olduğunu kanıtlamaktadır. Bu sayede şirket, daha çevik, maliyet etkin ve istikrarlı bir altyapıya sahip olmuştur.

Sonuç: Kaynak Kotaları ile Kontrollü ve Verimli Kubernetes Ortamları

Kubernetes, modern uygulama dağıtım ve yönetimi için eşsiz bir platform sunar. Ancak, bu gücün kontrolsüz kullanımı, özellikle çok kiracılı ortamlarda ciddi maliyetlere, performans sorunlarına ve operasyonel karmaşıklıklara yol açabilir. İşte tam da bu noktada Kubernetes Kaynak Kotaları, küme yöneticilerinin ve geliştiricilerin elini güçlendiren kritik bir mekanizma olarak öne çıkar.

Bu makale boyunca, Kaynak Kotaları'nın ne olduğunu, neden bu kadar önemli olduğunu, nasıl çalıştığını ve gerçek dünya senaryolarında nasıl uygulanabileceğini detaylı bir şekilde inceledik. Temel kavramlardan başlayarak, adım adım uygulamalı örneklere, ileri düzey ipuçlarına ve kapsamlı vaka analizlerine kadar, Kaynak Kotaları'nın bir Kubernetes kümesinde adil, öngörülebilir ve maliyet etkin bir kaynak dağıtımı sağlamanın anahtarı olduğunu gördük.

Kaynak Kotaları'nı doğru bir şekilde uygulamak, "gürültülü komşu" sorunlarını ortadan kaldırır, kaynak israfını önler ve bulut maliyetlerini optimize eder. Ayrıca, geliştiricileri daha kaynak duyarlı uygulamalar tasarlamaya teşvik ederken, üretim ortamlarının istikrarını ve güvenilirliğini garanti altına alır. LimitRange ile birleştiğinde ise, tekil Pod'lardan küme geneline kadar her seviyede kaynak kullanımı üzerinde hassas bir kontrol imkanı sunar.

Unutmamak gerekir ki, Kaynak Kotaları'nı tanımlamak sadece başlangıçtır. Sürekli izleme, esnek boyutlandırma stratejileri ve geliştirici ekipleriyle açık iletişim, bu mekanizmanın uzun vadeli başarısı için hayati öneme sahiptir. Kubernetes'in sunduğu bu güçlü özellikten faydalanarak, daha yönetilebilir, performanslı ve sürdürülebilir bir bulut yerel altyapı oluşturabilirsiniz.

Sıkça Sorulan Sorular (SSS)

S: Bir Pod, Kaynak Kotası'nı aşarsa ne olur?

C: Eğer bir Pod'un talep ettiği veya kullandığı kaynak miktarı, isim alanına uygulanan Kaynak Kotası'nın limitlerini aşarsa, Kubernetes API Sunucusu bu Pod'un oluşturulmasını veya güncellenmesini reddeder. Kullanıcıya "Forbidden" (Yasaklandı) hatası döner ve Pod kümede başlatılamaz.

S: Kaynak Kotası'nı tek bir Pod için belirleyebilir miyim?

C: Hayır, Kaynak Kotaları her zaman bir Kubernetes isim alanı (namespace) düzeyinde uygulanır. Tek bir Pod'un kaynaklarını kontrol etmek için Pod tanımında resources.requests ve resources.limits alanlarını kullanmalı ve bu Pod'un bulunduğu isim alanında bir LimitRange objesi tanımlamalısınız. LimitRange, Pod'lar için varsayılan ve maksimum/minimum kaynakları belirleyebilir.

S: Kaynak Kotası kullanımını nasıl izleyebilirim?

C: Kaynak Kotası kullanımını izlemenin en temel yolu kubectl describe resourcequota -n komutunu kullanmaktır. Bu komut, kotanın ne kadarının kullanıldığını (Used) ve maksimum limitini (Hard) gösterir. Daha gelişmiş izleme için Prometheus ve Grafana gibi araçları entegre ederek, zaman içindeki kullanım trendlerini görselleştirebilir ve uyarı sistemleri kurabilirsiniz.

S: ResourceQuota ile LimitRange arasındaki fark nedir?

C: Temel fark, kapsamlarındadır. ResourceQuota, bir isim alanının *toplam* kaynak tüketimini (CPU, bellek, Pod sayısı vb.) sınırlar. LimitRange ise, bir isim alanı içindeki *her bir* Pod veya kapsayıcı için kaynak requests ve limits değerlerini zorunlu kılar veya varsayılan değerler atar. Birlikte kullanıldıklarında, hem isim alanı geneli hem de bireysel Pod'lar üzerinde kapsamlı kontrol sağlarlar.

S: Kaynak Kotaları küme düzeyinde uygulanabilir mi?

C: Hayır, Kaynak Kotaları doğrudan küme düzeyinde uygulanamaz. Her zaman bir isim alanı ile ilişkilidirler. Ancak, birden fazla isim alanına kota uygulayarak ve bu isim alanlarının toplam kotalarını kümenin genel kapasitesiyle uyumlu hale getirerek dolaylı olarak küme kaynaklarını yönetebilirsiniz. Küme düzeyinde kaynak izolasyonu ve yönetimi için genellikle düğüm havuzları (node pools) veya ayrı kümeler gibi çözümler tercih edilir.