Merhaba arkadaşlar! Bugün Kubernetes dünyasında kritik bir konuya, yani Quality of Service (Hizmet Kalitesi) sınıflarına dalalım. Eğer “Neden bazı pod’lar sistem baskı altındayken ayakta kalırken diğerleri hemen ölüyor?” diye sorduysanız, cevabınız bu yazıda.
QoS Nedir ve Neden Önemli?
Quality of Service (QoS), Kubernetes’in pod’larınızı nasıl önceliklendireceğini ve kaynak sıkıntısı olduğunda hangilerini ilk evict edeceğini (çıkaracağını) belirleyen bir sınıflandırma sistemidir [2]. Düşünün ki Kubernetes cluster içinde bir node var ve belleği tükeniyor. Kubernetes’in bu durumda hangi pod’u öldüreceğine karar vermesi gerekiyor. İşte bu karar verme işini QoS’a göre yapıyor [3].
Kubernetes, pod’ları üç farklı QoS sınıfına ayırır: Guaranteed (Garantili), Burstable (Patlamalı) ve BestEffort (En İyi Çaba) [1]. Bu sınıflandırma tamamen sizin pod’larınız için tanımladığınız resource requests (kaynak istekleri) ve limits (limitler) değerlerine göre otomatik olarak yapılır [4]. Yani açıkca sen guaranteed, sen burstable vb. diye bir ayar yapmazsınız, request ve limit değerlerinden bu sınıflar çıkarılır.
Request ve Limit Nedir?
Önce temel kavramlara bakalım. Bir pod oluşturduğunuzda, her container için iki önemli parametre belirleyebilirsiniz [5]:
Request (İstek): Container’ın çalışması için garanti edilen minimum kaynak miktarıdır. Kubernetes scheduler, pod’unuzu bir node’a yerleştirirken bu değerleri kullanır [6]. Örneğin, 256Mi memory request tanımladıysanız, Kubernetes o pod için en az 256 Mi bellek ayıracaktır.
Limit (Limit): Container’ın kullanabileceği maksimum kaynak miktarıdır. Bu değeri aşmaya çalışırsa ne olur? CPU için throttling (kısıtlama) yapılır, yani uygulamanız yavaşlar ama ölmez [7]. Ama memory için durum farklı – limit aşılırsa kernel OOM killer devreye girer ve container’ı öldürür [8].
Compressible vs Incompressible Resources
Kubernetes kaynakları iki kategoriye ayırır [6]:
- Compressible (Sıkıştırılabilir) Kaynaklar: CPU gibi. Limit aşıldığında pod evict edilmez, sadece throttle edilir [7].
- Incompressible (Sıkıştırılamaz) Kaynaklar: Memory gibi. Limit aşıldığında pod terminate edilir [8].
Üç QoS Sınıfını Derinlemesine İnceleyelim
1. Guaranteed (Garantili) – VIP Pod’lar
Guaranteed sınıfı, Kubernetes’teki en yüksek önceliğe sahip pod’lardır [1]. Bu sınıfa girmek için şu kriterleri sağlamanız gerekir [2]:
- Pod’daki her container için memory limit ve request tanımlanmış olmalı
- Her container için memory limit ve request birbirine eşit olmalı
- Her container için CPU limit ve request tanımlanmış olmalı
- Her container için CPU limit ve request birbirine eşit olmalı
Örnek bir Guaranteed pod tanımı görelim:
apiVersion: v1
kind: Pod
metadata:
name: guaranteed-pod
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
memory: "1Gi"
cpu: "500m"
limits:
memory: "1Gi"
cpu: "500m"
Bu pod’u oluşturduğunuzda, Kubernetes otomatik olarak qosClass: Guaranteed olarak işaretleyecektir [9]. Guaranteed pod’lar sadece limit değerlerini aştıklarında veya node’da başka evict edilecek düşük öncelikli pod kalmadığında öldürülürler [1]. Kritik uygulamalarınız için bu sınıfı kullanmalısınız [10].
2. Burstable (Patlamalı) – Esnek Pod’lar
Burstable sınıfı, Guaranteed kriterlerini karşılamayan ama en azından bir container’ında resource tanımı olan pod’lar için geçerlidir [1]. Bu sınıfa girebilmek için [2]:
- Guaranteed kriterlerini karşılamamalı
- En az bir container’da memory veya CPU request ya da limit tanımlanmış olmalı
İki yaygın Burstable senaryosu vardır [11]:
Senaryo 1: Limit, request’ten büyük:
apiVersion: v1
kind: Pod
metadata:
name: burstable-pod
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
memory: "256Mi"
cpu: "200m"
limits:
memory: "1Gi"
cpu: "1000m"
Senaryo 2: Sadece request tanımlı, limit yok:
apiVersion: v1
kind: Pod
metadata:
name: burstable-pod-2
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
memory: "128Mi"
cpu: "100m"
Burstable pod’lar, kullanılabilir kaynak olduğunda request değerlerinin üzerine çıkabilirler [12]. Örneğin 256Mi request ve 1Gi limit tanımladıysanız, node’da boş memory varken 1Gi’a kadar kullanabilirsiniz. Ama kaynak sıkıntısı olduğunda, BestEffort pod’lar bittikten sonra bu pod’lar evict edilmeye başlar [13].
Bu sınıf, değişken kaynak ihtiyacı olan uygulamalar için idealdir [4]. Örneğin, bazen spike yapan bir web uygulamanız varsa, normal zamanlarda az kaynak kullanır ama trafiğe göre burst yapabilir.
3. BestEffort (En İyi Çaba) – Risk Alan Pod’lar
BestEffort, en düşük öncelikli QoS sınıfıdır [1]. Bu sınıfa girmek için [2]:
- Pod’daki hiçbir container için memory veya CPU request ya da limit tanımlanmamış olmalı
apiVersion: v1
kind: Pod
metadata:
name: besteffort-pod
spec:
containers:
- name: nginx
image: nginx
# resources tanımı yok!
BestEffort pod’lar, node’da kalan tüm boş kaynakları kullanabilirler [14]. Ama bu bir kılıç gibi iki taraflı keskin – çok kaynak kullanabilirsiniz ama ilk kurban da sizsiniz! Node kaynak baskısı altına girdiğinde, ilk evict edilenler BestEffort pod’larıdır [1][13].
Bu sınıf, kritik olmayan, kesintiye toleranslı görevler için uygundur [4]. Örneğin batch job’lar, test ortamları veya arka planda çalışan düşük öncelikli işler için kullanabilirsiniz.
Pod Eviction Sırası: Hayatta Kalma Oyunu
Kubernetes, bir node kaynak sıkıntısına düştüğünde şu sırayı takip eder [1][13]:
- İlk Evict Edilenler: BestEffort pod’lar
- İkinci Sıra: Request değerlerini aşan Burstable pod’lar (priority class’a göre sıralanır)
- Son Çare: Guaranteed pod’lar (sadece limit aştıklarında)
Memory pressure (bellek baskısı) durumunda, Kubernetes şu kriterlere göre sıralama yapar [15][16]:
- Pod’un memory kullanımı request’i aşıyor mu?
- Pod’un priority class’ı nedir?
- Request’e göre ne kadar fazla memory kullanıyor?
İlginç bir nokta: CPU pressure durumunda pod eviction olmaz! [18] Çünkü CPU compressible bir kaynaktır – Kubernetes sadece throttle eder, öldürmez. Ama memory pressure’da durum ciddiyetle eviction yapılır çünkü memory incompressible’dır [7][8].
Pratikte Test Edelim!
Üç pod oluşturalım: biri Guaranteed, biri Burstable, biri BestEffort. Sonra node’u stress test’e tabi tutalım ve ne olacağını görelim!
Diyelim ki node’unuzda 2GB memory var. stress-ng aracıyla 2GB memory kullanımı simüle edelim. Eğer daha fazla kaynağınız varsa hem pod hem stress testi ayarlarını one göre değiştirmelisiniz.
stress-ng --vm 1 --vm-bytes 2G
Sonuç? BestEffort ve Burstable pod’lar hata ile çıktı, ama Guaranteed pod sorunsuz çalışmaya devam etti! Sanırım bu örnekle QoS sınıflarının işlevi daha iyi anlaşıldı.
Best Practices: Nasıl Kullanmalıyız?
İşte production ortamları için önerilerim [10][20]:
1. Her Zaman Request ve Limit Tanımlayın
BestEffort pod’lardan kaçının [14]. Her pod için en azından request değerleri belirleyin.
2. Kritik Uygulamalar İçin Guaranteed Kullanın
Database’ler, API gateway’ler, core servisler için Guaranteed sınıfını tercih edin [4][10].
3. Burstable’ı Akıllıca Kullanın
Değişken workload’lar için ideal [4]. Ama dikkatli olun – çok büyük limit koymak kaynak israfına yol açabilir.
4. Priority Class ile Birleştirin
QoS ile birlikte Priority Class kullanarak daha fine-grained kontrol sağlayın [16][20].
5. Monitoring Yapın
Pod’larınızın QoS sınıflarını kontrol edin:
kubectl get pods -o custom-columns=\ NAME:.metadata.name,\ QOS:.status.qosClass
6. Resource Kullanımını İzleyin
Hangi pod’ların request değerlerini ne kadar aştığını takip edin. Bu veriler sizing kararlarınız için kritik [12].
Yaygın Hatalar ve Tuzaklar
Hata 1: Request = Limit her pod için Her pod’u Guaranteed yapmak kaynak verimsizliğine yol açar [14]. Node kapasitenizi doğru kullanamaz, pod’lar boşuna kaynak tutar.
Hata 2: Hiç limit koymamak Burstable pod’larda limit koymazsanız, bir pod tüm node’u işgal edebilir [11][12].
Hata 3: BestEffort production’da Production critical workload’lar için asla BestEffort kullanmayın [14]. Uygulamanız ansızın ölebilir.
Hata 4: Sadece CPU tanımlamak Memory için de tanım yapın! Memory pressure daha tehlikelidir [7][8].
Gelecek ve İleri Seviye Konular
Kubernetes ekosistemi sürekli gelişiyor. QoS ile ilgili bilmeniz gereken bazı ileri seviye konular [17]:
- Memory QoS: Linux cgroup v2 ile gelen gelişmiş memory yönetimi özellikleri
- Node Allocatable: System ve Kubernetes daemon’ları için kaynak rezervasyonu
- Pod Overhead: Runtime overhead’lerini hesaba katma
- Topology-aware scheduling: QoS ile birlikte NUMA aware scheduling
Sonuç
Kubernetes Quality of Service sınıfları, cluster’ınızın kaynak yönetiminde kritik bir rol oynar [1][10]. Guaranteed, Burstable ve BestEffort sınıflarını doğru kullanarak:
✅ Kritik uygulamalarınızın stabil çalışmasını sağlarsınız
✅ Kaynak kullanımını optimize edersiniz
✅ Unpredictable eviction’lardan kaçınırsınız
✅ Cluster maliyetlerinizi düşürürsünüz
Unutmayın: Her pod için doğru QoS sınıfını seçmek, başarılı bir Kubernetes deployment’ının temelidir. Request ve limit değerlerinizi dikkatli belirleyin, monitoring yapın ve gerektiğinde fine-tune edin.
Kaynaklar
[1] Kubernetes.io. “Pod Quality of Service Classes.” https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/
[2] Kubernetes.io. “Configure Quality of Service for Pods.” https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
[3] Sematext. “Kubernetes Quality of Service (QoS) Classes Explained.” https://sematext.com/glossary/kubernetes-quality-of-service-classes/
[4] LinkedIn. “Understanding Kubernetes Pod Quality of Service (QoS) Classes.” https://www.linkedin.com/pulse/understanding-kubernetes-pod-quality-service-qos-matias-nicoletti
[5] Last9. “Kubernetes QoS Explained: Classes & Resource Management.” https://last9.io/blog/kubernetes-qos-explained/
[6] Medium – Google Cloud. “What are Quality of Service (QoS) Classes in Kubernetes.” https://medium.com/google-cloud/quality-of-service-class-qos-in-kubernetes-bb76a89eb2c6
[7] K21Academy. “Kubernetes Quality of Service (QoS) Simplified.” https://k21academy.com/docker-kubernetes/quality-of-service-qos-in-kubernetes-ensuring-reliable-application-performance/
[8] Medium – Anvesh Muppeda. “A Hands-On Guide to Kubernetes QoS Classes.” https://medium.com/@muppedaanvesh/a-hands-on-guide-to-kubernetes-qos-classes-%EF%B8%8F-571b5f8f7e58
[9] Medium – Sridhar. “Kubernetes QoS Classes: Complete Guide with Examples.” https://medium.com/@sridharcloud/kubernetes-qos-classes-complete-guide-with-examples-262f186659c5
[10] WafaTech. “Understanding Kubernetes Quality of Service: A Deep Dive.” https://wafatech.sa/blog/devops/kubernetes/understanding-kubernetes-quality-of-service-a-deep-dive/
[11] Kubernetes.io. “Node-pressure Eviction.” https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/
[12] Kubernetes.io. “Resource Management for Pods and Containers.” https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
[13] Sysdig. “Understanding Kubernetes Evicted Pods.” https://www.sysdig.com/blog/kubernetes-pod-evicted
[14] Opensource.com. “A guide to Kubernetes pod eviction.” https://opensource.com/article/21/12/kubernetes-pod-eviction
[15] Alibaba Cloud. “Kubernetes Eviction Policies for Handling Low RAM and Disk Space Situations – Part 2.” https://www.alibabacloud.com/blog/kubernetes-eviction-policies-for-handling-low-ram-and-disk-space-situations—part-2_595203
[16] Devtron. “Kubernetes Pod Eviction: Causes, Preemption, and Best Practices.” https://devtron.ai/blog/ultimate-guide-of-pod-eviction-on-kubernetes/
[17] Kubernetes.io. “Pod Quality of Service Classes.” https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/
[18] Overcast Blog. “Do Kubernetes Pods Really Get Evicted Due to CPU Pressure?” https://overcast.blog/do-pods-really-get-evicted-due-to-cpu-pressure-2b27274a670c
[19] Unofficial Kubernetes. “Out of resource.” https://unofficial-kubernetes.readthedocs.io/en/latest/concepts/cluster-administration/out-of-resource/
[20] Medium – Kittipat.Po. “How Kubernetes Evicts Pods: Understanding Resource Limits, Requests, and Priority.” https://medium.com/@kittipat_1413/how-kubernetes-evicts-pods-understanding-resource-limits-requests-and-priority-b7a9dae1a1f2
[21] YouTube Video Kaynağı: https://youtu.be/ka-HItczp2I?si=N7vrVf2HlTD8IpXL
