Kubernetes Dengeleme: QoS, Öncelik ve Puanlama ile Nasıl Çalışır?

Modern uygulamaların karmaşıklığı arttıkça, Kubernetes kümelerindeki kaynak yönetimi sadece Pod’ları çalıştırmanın ötesine geçiyor. Peki, kümelerinizdeki kritik iş yüklerinin her zaman yeterli kaynağa sahip olduğundan ve kararlı bir şekilde çalıştığından nasıl emin olabilirsiniz? Bu makalede, Kubernetes’in temel scheduling mekanizmalarının ötesine geçerek, Kalite Servisi (QoS), Öncelik (Priority) ve Puanlama (Scoring) kavramlarını nasıl kullanarak kümenizi dengede tuttuğunu, performansı optimize ettiğini ve kesintileri minimize ettiğini derinlemesine inceleyeceğiz.

Kubernetes, container tabanlı uygulamaları yönetmek için tasarlanmış güçlü bir platformdur. Ancak, milyonlarca kullanıcıya hizmet veren bir e-ticaret uygulamasından tutun da, arka planda çalışan veri analizi işlerine kadar farklı öncelik ve kaynak gereksinimlerine sahip Pod’ları aynı anda, aynı küme üzerinde çalıştırmak, yalnızca Pod’ları uygun bir Node’a yerleştirmekten çok daha fazlasını gerektirir. Basit bir Pod planlaması, kaynak çatışmaları, kritik hizmetlerde performans düşüşleri ve hatta küme kararlılığında ciddi sorunlara yol açabilir. Bu nedenle, Kubernetes geliştiricileri, küme sağlığını ve uygulama performansını korumak için daha sofistike mekanizmalar tasarlamıştır.

Örneğin, bir e-ticaret sitesinin ödeme sisteminin çalıştığı Pod’lar, aynı kümede arka planda çalışan stok güncelleme Pod’ları veya bir geliştiricinin test Pod’ları ile aynı önem düzeyine sahip olmamalıdır. Ödeme sistemi, anlık ve yüksek performansla çalışmak zorundayken, stok güncellemesi daha düşük öncelikli olabilir ve belirli gecikmeler tolere edilebilir. İşte bu noktada, Kubernetes’in geleneksel planlama mantığının ötesine geçerek devreye soktuğu Kalite Servisi (QoS), Pod Önceliği (Priority) ve Scheduler Puanlama (Scoring) mekanizmaları hayati bir rol oynar. Bu mekanizmalar, küme yöneticilerinin, kaynakları daha akıllıca tahsis etmesine, Pod’ların yaşam döngüsünü daha iyi yönetmesine ve sonuç olarak daha kararlı, güvenilir ve verimli bir altyapı sunmasına olanak tanır. Kısacası, Kubernetes, yalnızca Pod’ları bir yere koymakla kalmaz, aynı zamanda onların “ne kadar iyi” çalışacağını da yönetir. Bu ileri düzey kontrol mekanizmaları sayesinde, kritik uygulamalarınızın her koşulda beklendiği gibi çalıştığından emin olabilirsiniz.

Kubernetes Kalite Servisi (QoS) Sınıfları Nelerdir ve Uygulamalarınıza Nasıl Değer Katarlar?

Kalite Servisi (QoS), Kubernetes’in Pod’lara kaynak garantileri atamak ve Node’larda kaynak sıkıntısı yaşandığında hangi Pod’ların öncelikle sonlandırılacağını (evict edileceğini) belirlemek için kullandığı temel bir kavramdır. Kubernetes’te her Pod, tanımlanan kaynak istekleri (requests) ve limitleri (limits) baz alınarak üç farklı QoS sınıfından birine atanır: Guaranteed, Burstable ve BestEffort. Bu sınıflandırma, Pod’ların kararlılığını ve performansını doğrudan etkilerken, aynı zamanda Node kaynaklarının verimli kullanımını da optimize eder. Doğru QoS sınıfını seçmek, uygulamanızın kritiklik düzeyine ve kaynak tüketim desenine göre büyük önem taşır.

QoS sınıflarını anlamak, Pod’larınızın ne zaman ve hangi koşullarda Node’dan atılacağını (eviction) öngörmenizi sağlar. Bu da, özellikle yoğun anlarda veya Node arızaları gibi beklenmedik durumlarda kümenizin direncini artırmanıza yardımcı olur. Şimdi bu üç ana QoS sınıfını daha yakından inceleyelim:

Guaranteed QoS: Kritik İş Yükleriniz İçin Sürekli Performans Nasıl Sağlanır?

Guaranteed sınıfı, Kubernetes kümenizdeki en kritik iş yükleri için tasarlanmıştır. Bu Pod’lar, Node’da en yüksek önceliğe sahiptir ve kaynak sıkıntısı durumunda en son evict edilecek Pod’lar arasındadır. Bir Pod’un Guaranteed sınıfına girmesi için, her bir Container’ı için CPU ve bellek kaynakları için hem requests hem de limits değerlerinin tanımlanması ve bu değerlerin birbirine eşit olması gerekir. Ayrıca, limits değerleri, eğer tanımlıysa, requests değerlerinden büyük olmamalıdır. Bu sıkı gereksinimler, Pod’un her zaman talep ettiği kadar kaynağa sahip olmasını garanti eder.

Örneğin, bir bankacılık uygulamasının veritabanı Pod’ları veya yüksek trafikli bir API ağ geçidi gibi sürekli ve kesintisiz çalışması gereken servisler için Guaranteed sınıfı idealdir. Bu sayede, Pod’lar, Node’da başka Pod’lar kaynakları zorlasa bile tanımlanan performans seviyelerini koruyabilir.

apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  containers:
  - name: my-container
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: "500m"

Burstable QoS: Esnekliğin ve Verimliliğin Dengesi Nasıl Kurulur?

Burstable sınıfı, çoğu tipik uygulama için varsayılan ve en yaygın kullanılan QoS sınıfıdır. Bu Pod'lar, Guaranteed sınıfına kıyasla daha esnektir ve kaynakları daha verimli kullanabilirler. Bir Pod'un Burstable sınıfına girmesi için aşağıdaki koşullardan biri veya birkaçı sağlanmalıdır:

• En az bir Container için CPU veya bellek requests tanımlanmış olmalı, ancak bu kaynaklar için limits tanımlanmamış olabilir.
• Tüm Container'lar için requests tanımlanmış, ancak requests ve limits değerleri birbirinden farklıdır.

Burstable Pod'lar, Node'da boşta kalan kaynakları kullanabilirler ve bu sayede kısa süreli ani yük artışlarını (burst) karşılayabilirler. Ancak, Node kaynak sıkıntısı yaşadığında, Guaranteed Pod'lardan sonra, ancak BestEffort Pod'lardan önce evict edilme riski taşırlar. Web sunucuları, mikroservisler veya orta öncelikli işleme servisleri gibi birçok uygulama, Burstable sınıfı ile gayet iyi çalışır.

apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
spec:
  containers:
  - name: my-container
    image: nginx
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "512Mi"
        cpu: "1000m"

BestEffort QoS: Arka Plan Görevleriniz İçin En Uygun Maliyetli Çözüm Nasıl Uygulanır?

BestEffort sınıfı, en düşük önceliğe sahip Pod'ları temsil eder. Bu Pod'lar için hiçbir kaynak requests veya limits tanımlanmaz. Kubernetes, bu Pod'lara herhangi bir kaynak garantisi vermez ve Node'da kaynak sıkıntısı yaşandığında ilk evict edilecek Pod'lar olurlar. Genellikle önemsiz arka plan görevleri, geliştirme ortamındaki test Pod'ları veya batch işleri gibi kesintiye uğraması performansı kritik ölçüde etkilemeyecek iş yükleri için kullanılırlar. BestEffort Pod'lar, kaynakları en esnek şekilde kullanır ancak kararlılıkları en düşüktür.

apiVersion: v1
kind: Pod
metadata:
  name: besteffort-pod
spec:
  containers:
  - name: my-container
    image: nginx
    # Hiçbir requests veya limits tanımlanmaz

QoS sınıflarının karşılaştırması aşağıdaki tabloda özetlenmiştir:

Pod Önceliği (Priority) ve Preemption: Acil İş Yükleri Diğerlerini Nasıl Yerinden Eder?

Kubernetes'teki QoS sınıfları, Pod'ların kaynak garantilerini ve evict edilme davranışlarını belirlerken, Pod Önceliği (Priority) mekanizması, Pod'ların küme içinde ne kadar önemli olduğunu ifade eden daha üst düzey bir kavramdır. Özellikle küme kaynaklarının sınırlı olduğu durumlarda, daha yüksek önceliğe sahip Pod'ların, daha düşük önceliğe sahip Pod'ları Node'dan "yerinden etme" (preemption) yeteneği sayesinde kritik iş yüklerinin çalışmaya devam etmesi sağlanır. Bu mekanizma, cluster yöneticilerine, en önemli uygulamaların her koşulda çalışmasını garantileme konusunda güçlü bir araç sunar.

Öncelik, PriorityClass adında bir küme genelindeki (cluster-scoped) API nesnesiyle tanımlanır. Bu nesne, bir isim ve bir sayısal value içerir. Yüksek value değerleri, daha yüksek önceliği gösterir. Örneğin, 1000000 gibi bir değere sahip bir PriorityClass, 1000 değere sahip olandan daha yüksek öncelikli kabul edilir. Küme yöneticisi, farklı öncelik seviyeleri için birden fazla PriorityClass tanımlayabilir ve Pod'lar bu sınıfları referans göstererek önceliklerini belirtirler. Eğer bir Pod'a PriorityClass atanmazsa, varsayılan olarak sıfır önceliğe sahip olur.

Peki, bu öncelik mekanizması pratikte nasıl çalışır? Bir Pod, bir Node'a yerleşemediğinde (yani, Node'da yeterli kaynak yoksa), Kubernetes Scheduler, daha yüksek önceliğe sahip Pod'un yerleşebilmesi için, daha düşük önceliğe sahip Pod'ları Node'dan zorla çıkarmayı (preemption) deneyebilir. Bu süreçte, Scheduler öncelikle Node üzerindeki kaynakları boşaltmak için en düşük öncelikli Pod'ları belirler ve bunları sonlandırır. Bu, özellikle sürekli entegrasyon/sürekli dağıtım (CI/CD) boru hatlarında, acil üretim yamalarında veya kritik veri işleme görevlerinde çok kullanışlıdır. Örneğin, bir kritik güvenlik güncellemesinin devreye alınması gerektiğinde, bu güncellemenin Pod'ları, mevcut daha düşük öncelikli test Pod'larını preempt ederek anında çalışmaya başlayabilir.

Preemption mekanizması, küme kaynaklarının verimli kullanılmasını sağlarken, aynı zamanda kritik servislerin sürekliliğini teminat altına alır. Ancak, bu gücün dikkatli kullanılması gerekir. Yanlış yapılandırılmış veya aşırı agresif önceliklendirme, önemli olmayan Pod'ların sürekli olarak yerinden edilmesine ve uygulama kesintilerine yol açabilir. Bu nedenle, PriorityClass tanımlarken ve Pod'lara atarken iyi düşünülmüş bir stratejiye sahip olmak esastır.

İşte bir PriorityClass tanımı ve bu sınıfı kullanan bir Pod örneği:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "Bu sınıf, üretimdeki kritik servisler için kullanılır."
---
apiVersion: v1
kind: Pod
metadata:
  name: critical-api-pod
spec:
  containers:
  - name: api-container
    image: my-critical-api:v1.0
    resources:
      requests:
        memory: "512Mi"
        cpu: "1"
      limits:
        memory: "1Gi"
        cpu: "2"
  priorityClassName: high-priority # Tanımladığımız PriorityClass'ı kullanıyoruz

Bu yapılandırma, critical-api-pod'un diğer Pod'lara göre daha yüksek bir önceliğe sahip olmasını sağlar, böylece kaynak sıkıntısı durumunda hayati önem taşıyan bu servis kesintisiz çalışmaya devam edebilir.

Scheduler Puanlama (Scoring): Pod'lar En Uygun Node'u Nasıl Bulur?

Kubernetes Scheduler'ın temel görevi, yeni oluşturulan veya planlanmamış Pod'ları (yani Node alanı boş olan Pod'ları) bir Node'a atamaktır. Bu süreç iki ana aşamadan oluşur: Filtreleme (Filtering) ve Puanlama (Scoring). Filtreleme aşamasında, Pod'un gereksinimlerini karşılamayan (örneğin, yeterli kaynağı olmayan, belirli bir taint'e sahip olan ancak toleration'ı olmayan) Node'lar elenir. Gerçek dengeleme sanatı ise Puanlama aşamasında başlar. Puanlama (Scoring), Pod'un kalan uygun Node'lar arasında en "uygun" olanını belirlemek için kullanılır. Her bir uygun Node'a bir puan atanır ve en yüksek puanı alan Node, Pod için seçilir.

Puanlama, çeşitli faktörlere dayalı olarak yapılır ve Scheduler, bu faktörleri kullanarak her Node'un Pod için ne kadar ideal olduğunu değerlendirir. Bu faktörler arasında şunlar bulunabilir:

• Kaynak Kullanımı: Node'un mevcut CPU ve bellek kullanımı. Scheduler genellikle, kaynakları en az kullanan veya en dengeli dağıtıma sahip Node'ları tercih eder.
• Node Affinity/Anti-Affinity: Pod'un belirli etiketlere (labels) sahip Node'larda çalışmasını isteyen veya belirli Node'lardan uzak durmasını isteyen kurallar. Örneğin, bir veritabanı Pod'u, yüksek performanslı depolama birimine sahip Node'ları tercih edebilir.
• Pod Affinity/Anti-Affinity: Pod'un belirli diğer Pod'larla aynı Node üzerinde veya farklı Node'lar üzerinde çalışmasını sağlayan kurallar. Bu, yüksek erişilebilirlik veya performans için kritik öneme sahiptir.
• Taints ve Tolerations: Node'ları yalnızca belirli Pod'ların üzerinde çalışmasına izin verecek şekilde işaretlemek için kullanılır.
• Volume Kullanımı: Pod'un persistent volume taleplerini karşılayabilecek Node'lar.
• Dengeleme Politikaları: Pod'ları Node'lar arasında eşit dağıtma veya belirli Pod'ları belirli Node'larda yoğunlaştırma gibi politikalar.

Scheduler, bu ve benzeri birçok "puanlama fonksiyonunu" kullanarak her Node için bir toplam puan hesaplar. Her fonksiyon, Pod'un ve Node'un özelliklerine göre bir puan döndürür ve bu puanlar ağırlıklandırılarak nihai bir toplam puan elde edilir. Örneğin, bir Pod'un bellek isteği yüksekse, Scheduler daha fazla boş belleği olan Node'lara daha yüksek puan verebilir. Bu dinamik puanlama sistemi sayesinde, Kubernetes kümesi sadece kaynakları boş olan Node'a Pod yerleştirmekle kalmaz, aynı zamanda gelecekteki performans, erişilebilirlik ve dengeleme hedeflerini de göz önünde bulundurarak en optimum kararı verir. Bu yaklaşım, kümenin uzun vadeli sağlığı ve verimliliği için kritik öneme sahiptir.

Gelişmiş senaryolarda, Kubernetes'in varsayılan Scheduler'ının davranışını değiştirmek veya genişletmek mümkündür. Scheduler Extenders ve Custom Schedulers kullanarak, kendi puanlama algoritmalarınızı veya filtreleme kurallarınızı uygulayabilir, böylece iş yüklerinize özel optimizasyonlar yapabilirsiniz. Bu, özellikle karmaşık veya özel gereksinimleri olan kurumsal ortamlarda büyük avantaj sağlar.

İşte bir Pod Affinity örneği, Scheduler'ın puanlama aşamasında bu tür kuralları nasıl değerlendireceğine dair bir ipucu sunar:

apiVersion: v1
kind: Pod
metadata:
  name: web-server-pod
  labels:
    app: webserver
spec:
  containers:
  - name: web-container
    image: nginx
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: cache-service # Bu Pod'un, 'app: cache-service' etiketli Pod'larla aynı Node'a yerleşmesini istiyoruz
        topologyKey: "kubernetes.io/hostname"

Bu Pod tanımı, Scheduler'a, web-server-pod'u, app: cache-service etiketine sahip başka bir Pod'un çalıştığı bir Node'a yerleştirmesi için yüksek puan vermesini söyler. Bu, web sunucusunun önbellek servisine düşük gecikmeli erişim sağlaması gereken durumlarda kritik bir optimizasyondur.

Gelişmiş Dengeleme Stratejileri: QoS, Öncelik ve Puanlamayı Birlikte Kullanmak

Kubernetes'teki QoS, Öncelik ve Puanlama mekanizmaları, tek başlarına güçlü araçlar olsalar da, gerçek anlamda dengeli ve verimli bir küme oluşturmak için bunların birleşik kullanımı vazgeçilmezdir. Bu üçlünün akıllıca orkestrasyonu, sadece Pod'ların uygun Node'lara yerleşmesini sağlamakla kalmaz, aynı zamanda kümenin yaşam döngüsü boyunca kaynak kullanımını dinamik olarak optimize eder ve beklenmedik durumlar karşısında dayanıklılığı artırır.

Örneğin, bir büyük veri işleme platformunda, kritik veritabanı Pod'ları Guaranteed QoS ve yüksek PriorityClass ile yapılandırılabilirken, veri işleme iş yükleri Burstable QoS ile daha orta seviye bir öncelik alabilir. Anlık raporlama veya ad-hoc analizler için kullanılan Pod'lar ise BestEffort ve düşük öncelik ile çalıştırılabilir. Scheduler, bu Pod'ları yerleştirirken, puanlama algoritmaları aracılığıyla Node kaynaklarını, mevcut iş yükünü ve Pod'lar arasındaki affinity/anti-affinity kurallarını göz önünde bulundurarak en uygun kararı verir. Kaynak sıkıntısı yaşandığında, yüksek öncelikli Pod'lar, düşük öncelikli Pod'ları preempt ederek kritik operasyonların aksamamasını sağlar. Bu entegre yaklaşım, operasyonel sürekliliği maksimize ederken, aynı zamanda kaynakların israfını önler.

Bu mekanizmaları daha da ileri taşımak için, Kubernetes ekosistemindeki diğer araçlarla entegrasyon önemlidir. Örneğin:

• Horizontal Pod Autoscaler (HPA) ve Vertical Pod Autoscaler (VPA): HPA, CPU veya bellek kullanımı gibi metrikleri izleyerek Pod sayısını yatayda ölçeklendirirken, VPA, Pod'ların kaynak isteklerini (requests) ve limitlerini dikeyde optimize eder. Bu otomasyon araçları, QoS ve Priority ile birlikte çalışarak Pod'ların doğru boyutta olmasını ve değişen yük altında bile doğru öncelikle kaynak almasını sağlar.
• Cluster Autoscaler: Node'da yeterli kaynak kalmadığında yeni Node'lar ekler veya Node'lar boşaldığında gereksiz Node'ları kaldırarak maliyet optimizasyonu sağlar. Priority ve QoS, Cluster Autoscaler'ın hangi Pod'ların Node'ları dolduracağını ve hangi Pod'ların yeni Node tetikleyeceğini anlamasına yardımcı olur.
• Descheduler: Zaman zaman Pod'lar, ilk planlandıkları Node'da en iyi yeri bulamayabilirler (örneğin, Node'a sonradan yüksek öncelikli bir Pod gelmiş olabilir). Descheduler, küme genelindeki Pod dağılımını optimize etmek için Pod'ları Node'lar arasında yeniden dağıtarak daha iyi denge sağlar.

Vaka Analizi: Büyük Bir SaaS Şirketinin Kaynak Optimizasyon Hikayesi
Büyük bir SaaS şirketi, artan müşteri talepleriyle birlikte Kubernetes kümesinde performans sorunları yaşamaya başlamıştı. Kritik müşteri odaklı servisler (ödeme, kullanıcı girişi) ile arka plan veri işleme ve analitik servisleri aynı kümede çalışıyordu. Özellikle yoğun saatlerde, arka plan işleri kaynakları tüketerek ön uç servislerin yavaşlamasına neden oluyordu.

Şirket, bu durumu çözmek için aşağıdaki adımları izledi:

1. QoS Sınıflandırması: Ödeme ve kullanıcı girişi servisleri Guaranteed QoS sınıfına alındı. Orta öncelikli API servisleri Burstable, arka plan işleri ise BestEffort olarak belirlendi.
2. PriorityClass Tanımları: Üretimdeki kritik servisler için "prod-critical", diğer servisler için "prod-standard" ve test/dev ortamları için "low-priority" şeklinde PriorityClass'lar oluşturuldu ve Pod'lara atandı.
3. Affinity/Anti-affinity Kuralları: Veritabanı Pod'ları ile uygulama Pod'ları arasında bölgesel anti-affinity kuralları tanımlanarak yüksek erişilebilirlik sağlandı.
4. Autoscaler Entegrasyonu: HPA ve VPA, kritik servislerin her zaman doğru boyutta ve yeterli kaynakla çalışmasını sağlamak için devreye alındı. Cluster Autoscaler ise Node kaynakları yetersiz kaldığında otomatik olarak yeni Node'lar ekledi.

Bu entegre yaklaşım sayesinde şirket, yoğun saatlerde bile kritik servislerinin performansını stabilize etmeyi başardı, kaynak israfını azalttı ve operasyonel maliyetlerden önemli ölçüde tasarruf etti. Ayrıca, preemption mekanizması sayesinde, kritik güvenlik yamaları gibi acil durum Pod'ları, diğer iş yüklerini durdurarak anında devreye alınabildi. Bu örnek, Kubernetes'in QoS, Priority ve Puanlama yeteneklerinin birleşiminin, modern iş yüklerinin karmaşıklığını yönetmek için ne kadar hayati olduğunu açıkça göstermektedir.

@media (max-width: 768px) { /* Mobil özel CSS kuralları */ }

Sonuç: Kubernetes Kümelerinizde Kararlılığı ve Verimliliği Nasıl Sağlayabilirsiniz?

Görüldüğü üzere, Kubernetes, Pod'ları sadece Node'lara yerleştiren basit bir planlayıcı olmaktan çok daha fazlasıdır. Kalite Servisi (QoS), Pod Önceliği (Priority) ve Scheduler Puanlama (Scoring) gibi sofistike mekanizmalar aracılığıyla, küme yöneticilerine iş yüklerini önceliklendirme, kaynakları garanti altına alma ve Node'lar arasında dengeli bir dağılım sağlama yeteneği sunar. Bu entegre yaklaşım, modern, dinamik ve çeşitli iş yüklerine sahip kümeler için kesintisiz performans, yüksek erişilebilirlik ve optimum kaynak kullanımı sağlamanın anahtarıdır. Doğru yapılandırma ve stratejik kullanım ile Kubernetes kümelerinizde kararlılığı ve verimliliği en üst düzeye çıkarabilir, böylece uygulamalarınızın her zaman en iyi şekilde çalıştığından emin olabilirsiniz. Gelecekte, bu mekanizmaların yapay zeka ve makine öğrenimi ile daha da entegre olarak özerk ve kendi kendini optimize eden kümeler oluşturma potansiyeli de bulunmaktadır.

Sıkça Sorulan Sorular

• QoS Sınıfları Arasında Geçiş Yapılabilir mi?
  Bir Pod'un QoS sınıfı, Pod oluşturulduğu anda belirlenir ve yaşam döngüsü boyunca değişmez. Eğer bir Pod'un QoS sınıfını değiştirmek istiyorsanız, Pod'u silip, istediğiniz kaynak istekleri ve limitleri ile yeni bir Pod oluşturmanız gerekir.
• PriorityClass Kullanımı Performansı Nasıl Etkiler?
  PriorityClass kullanımı, kritik iş yüklerinin Node üzerinde öncelik kazanmasını sağlayarak onların performansını artırır. Ancak, düşük öncelikli Pod'ların preempt edilmesine yol açabileceği için, bu Pod'ların performansında geçici düşüşler veya kesintiler yaşanabilir. Dengeli bir kullanım stratejisi önemlidir.
• Puanlama Mekanizmasını Özelleştirmek Ne Zaman Gerekir?
  Varsayılan Kubernetes Scheduler çoğu senaryo için yeterli olsa da, çok özel gereksinimleri olan karmaşık kümelerde (örneğin, belirli donanım akseleratörlerine sahip Node'lar, lisanslama kısıtlamaları veya özel coğrafi dağıtım kuralları) puanlama mekanizmasını özelleştirmek gerekebilir. Bu genellikle Scheduler Extenders veya Custom Schedulers ile yapılır.
• BestEffort Pod'lar Ne Zaman Evict Edilir?
  BestEffort Pod'lar, Node'da kaynak sıkıntısı (örneğin, bellek basıncı) yaşandığında, Burstable ve Guaranteed Pod'lardan önce, yani ilk olarak evict edilirler. Kubernetes'in kubelet bileşeni, bu eviction kararlarını alır.