1. GİRİŞ

Kubernetes Scheduler, bir Kubernetes cluster'ında yeni oluşturulan Pod'ları hangi node üzerinde çalıştırılacağına karar veren merkezi bileşendir. Doğru scheduler yapılandırması, uygulama performansı, kaynak kullanımı ve operasyon güvenilirliği üzerinde doğrudan etki eder. Bulut maliyetlerinin optimize edilmesi, SLA hedeflerine ulaşılması ve node kaynaklarının etkin kullanımı, scheduler politikalarının ve davranışlarının iyi anlaşılmasını gerektirir. Bu makalede scheduler'ın iç mekanizması, scheduling algoritmaları, policy'ler, extender ve custom scheduler senaryoları ile üretim ortamında karşılaşılan zorluklar ayrıntılı şekilde ele alınacaktır.

Neden bugün önemli?

• Kubernetes yaygınlaştıkça, schedule kararı sadece "hangi node boş" sorusundan daha karmaşık hale geldi: topology, latency, GPU/accelerator kaynakları, multi‑tenant izolasyonu ve maliyet kısıtları hesaba katılıyor.
• Edge, GPU ve stateful uygulamalar gibi özel kaynak ihtiyaçları, scheduler politikalarının özelleştirilmesini gerekli kılıyor.
• AI/ML iş yüklerinin GPU havuzları ve burst davranışları scheduler'ı hem performans hem de fairness açısından key oyuncu yapıyor.

Kimler için önemli?

• Platform mühendisleri ve SRE ekipleri
• Mikroservis mimarisine sahip uygulama geliştiricileri
• ML mühendisleri ve GPU kaynak yöneticileri

Hangi problemleri çözüyor?

• Kaynak tıkanmalarının önlenmesi ve node'ların dengeli kullanımı
• İzolasyon ve öncelik (priority) tabanlı yerleştirme
• Özel donanım, topoloji veya lisans kısıtlarının göz önünde bulundurulması

2. KAVRAMSAL TEMELLER

2.1 Scheduler'ın rolü

Scheduler, API Server'a yeni Pod kaydı geldiğinde devreye girer. Etki alanı: sadece "hangi node" kararıdır — bir pod çalıştırıldıktan sonra kubelet node tarafında runtime ile ilgilenir. Scheduler'ın karar süreci iki ana faza ayrılır: filtering (uygun node'ların süzülmesi) ve scoring (uygun node'ların puanlanması). Bu iki adım, scheduler'ın replica, affinity, taint, toleration, resource requests ve daha birçok kuralı değerlendirmesini sağlar.

2.2 Temel terimler

• Binding: Scheduler'ın seçtiği node ile pod'u eşleştirme işlemi.
• Predicate / Filter: Pod'un çalışmaya uygun olup olmadığını belirleyen koşullar (resource fit, node taint vs).
• Priority / Score: Uygun node'lar arasında en iyi node'u seçmek için kullanılan değerlendirme mekanizması.
• Preemption: Yüksek öncelikli pod'ların yer açmak için düşük öncelikli pod'ları sonlandırma mekanizması.
• Extender: Scheduler davranışını genişletmeye imkan veren dış bileşenler.

2.3 Scheduler mimarisi (yüksek seviyede)

Kubernetes’in varsayılan scheduler'ı (kube‑scheduler) modüler bir mimariye sahiptir: cache (node bilgileri), queue (schedule bekleyen pod'lar), scheduler framework (filter/score plugins) ve bind aşaması. Scheduler Framework (since Kubernetes 1.16+) plugin bazlıdır: filtering, scoring, reserve, permit, prebind ve reserve gibi lifecycle hook'lar sunar. Bu yapı custom scheduling davranışları yazmayı kolaylaştırır.

3. NASIL ÇALIŞIR? — Scheduler Algoritmaları ve Aşamalar

3.1 Filter (Predicate) aşaması

Filter aşaması, pod'ı barındırabilecek node'ları eler. Örnek filtreler: NodeUnschedulable, InsufficientResources, NodeSelector, PodAffinity/AntiAffinity, Taints/Tolerations, NodeAffinity ve daha fazlasıdır. Filtering sonucu dönen node set'i, scoring aşamasına gönderilir.

3.2 Score (Prioritize) aşaması

Scoring, her bir uygun node'a puan atar. Varsayılan scoring plugin'leri arasında LeastRequestedPriority (az kullanılmış kaynakları tercih etme), BalancedResourceAllocation (CPU ve memory dengesi), NodeAffinityPriority gibi seçenekler vardır. Puanlama sonucunda en yüksek skor alan node seçilir. Puanların normalize edilmesi ve farklı plugin'lerin ağırlıklandırılması score sonucunu etkiler.

3.3 Bind ve Post‑bind işlemleri

Bind aşamasında scheduler API Server üzerinden Binding çağrısı yapar ve pod ile node eşleştirilir. Daha sonra reserve, permit, prebind, postbind gibi hook'lar varsa çağrılır; ör. bir reserve plugin'i kaynak rezervasyonu yapabilir.

3.4 Preemption — Öncelik bazlı yer açma

Eğer uygun node yoksa ve yeni pod yüksek priority'e sahipse scheduler preemption süreçlerini tetikler: aday pod'ları (victims) belirler, onları sonlandırarak yer açar ve yeni yüksek öncelikli pod'u yerleştirir. Preemption, hizmet sürekliliği ile priority trade‑off'ı arasında dikkatli plan gerektirir. SRE ekipleri preemption limitlerini, disruption budget'leri ve priority class'ları dikkatle tanımlamalıdır.

3.5 Scheduler Framework ve plugin modeli

Modern kube‑scheduler, plugin tabanlı bir framework sağlar. Plugin türleri: Filter, Score, Reserve, Prebind, Bind, PostBind, Permit ve PreFilter. Bu yapı ile özel ihtiyaçlara göre custom plugin yazılabilir (ör. GPU packing, license aware scheduling). Plugin'ler Go ile yazılır ve scheduler konfigürasyonuna eklenir.

4. ÖZEL POLİTİKALAR: AFFINITY, TAINTS, TOLERATIONS, TOPLOGY

4.1 NodeAffinity ve PodAffinity/AntiAffinity

NodeAffinity, belirli label'lara sahip node'lara pod konumlandırma kısıtları sağlar (requiredDuringSchedulingIgnoredDuringExecution veya preferredDuringScheduling...). PodAffinity ve PodAntiAffinity ise pod'ların birbirine yakın veya uzak yerleşmesini sağlar; ör. aynı availability zone'da birlikte çalıştırma veya kin‑ship uygulamaları için anti‑co‑location. Bu politikalar performans, locality ve fault domain tasarımlarında kritik rol oynar.

4.2 Taints ve Tolerations

Taints node'ları belirli pod'lara 'itici' yapar; sadece uygun toleration'a sahip pod'lar bu node'lara yerleşebilir. Bu mekanizma, node'ları özel iş yükleri (GPU, dedicated high‑memory) için ayırma veya maintenance durumlarını işaretleme amaçlı kullanılabilir.

4.3 TopologyAwareScheduling

Topology‑aware scheduling, pod'ların ağ topolojisi, zone, region, rack gibi domain'leri dikkate alarak yerleşmesini sağlar. Özellikle stateful veya latency sensitive uygulamalarda rack‑aware, zone‑aware scheduling uygulamak yüksek erişilebilirlik ve düşük gecikme sağlar.

5. ÖZEL SENARYOLAR: GPU, FPGA, LICENSE VE LİSANSLAMA KISITLARI

5.1 GPU scheduling ve packing

GPU kaynakları discrete kaynaklardır ve scheduler'ın bunları packing (aynı node'da birden fazla GPU çekirdek kullanımını optimize etme) ve fragmentation sorunlarıyla başa çıkması gerekir. Device plugin'ler ve resource integer quantity'leri kullanılarak scheduler GPU taleplerini anlamlandırır. Ayrıca GPU hotplug veya MIG (NVIDIA Multi Instance GPU) gibi teknolojileri göz önüne alan custom plugin'ler geliştirmek gerekebilir.

5.2 Licensing constraints ve proprietary resources

Bazı enterprise yazılımlar lisans sınırlamaları, token veya node bazlı lisans modellerine sahiptir. Scheduler, license aware scheduling ile lisans havuzlarına göre yerleştirme yapabilir; bu genelde eksternal extender veya custom predicate/plugin ile uygulanır.

5.3 Spot/preemptible node'ları ile çalışma

Spot veya preemptible node'lar maliyet avantajı sağlar ancak kesintiye uğrama riski taşır. Scheduler konfigürasyonunda bu node'lara tolerate eden hafif veya batch işlerini yönlendirmek; stateful kritik uygulamaları on‑demand node'lara bırakmak iyi bir pratiktir. Ayrıca node taints ile spot node'ları işaretleyip toleration gerektiren pod'ları yönlendirebilirsiniz.

6. EXTENDER'LAR VE CUSTOM SCHEDULERLAR

6.1 Scheduler Extender

Extender, scheduler'ın dış kaynaklı karar verme süreçlerini entegre etmesine izin verir. Örneğin, bir extender dış API'ye danışarak node uygunluğunu kontrol edebilir veya node'ları farklı bir puanlama fonksiyonu ile sıralayabilir. Extender'lar HTTP tabanlı bir API ile scheduler'a bağlanır ve uygulama özelliklerine göre özelleştirme sağlar.

6.2 Custom scheduler

Bazı organizasyonlar tamamen özel scheduler implementasyonu geliştirirler: belirli iş yükleri için optimal packing, latency aware placement veya multi‑cluster scheduling gibi özellikler içeren scheduler'lar. Custom scheduler'lar genelde farklı scheduler name ile pod spec'te belirtilir (schedulerName). Ancak custom scheduler yazmak karmaşıklık ve operasyon maliyeti getirir; genelde plugin veya extender ile başlamak daha pratiktir.

6.3 Multi‑scheduler stratejileri

Bir cluster'da birden fazla scheduler çalıştırmak mümkündür: default kube‑scheduler genel iş yükleri, özel scheduler'lar ise ML/GPUs veya edge iş yükleri için ayrılabilir. Bu yaklaşım isolation, performance ve policy ayrımı sağlar.

7. PERFORMANS, ÖLÇÜM VE OPTİMİZASYON

7.1 Scheduler latency ve throughput

Scheduler'ın hızını etkileyen unsurlar: node sayısı, pod queue derinliği, filter/score plugin sayısı ve etcd koordinasyonu. Büyük cluster'larda scheduler latency'si kritik olabilir. İyileştirme yolları: plugin sayısını sınırlamak, prefilter ile hızlı elenebilen pod'ları erken ayırmak, node affinity ve partitioning ile scheduler yükünü dengelemek.

7.2 Cache ve cache invalidation

Scheduler lokal cache'ini etkin kullanır; ancak cache invalidation yanlış veriyle karar alınmasına neden olabilir. Node metadata güncellemeleri, resource usage telemetry ve node heartbeat'leri doğru sürelerle sync edilmelidir.

7.3 Partitioning ve sharding stratejileri

Çok büyük ortamlar için namespace veya node pool bazlı partitioning ile scheduler yükünü ve complexity'yi azaltabilirsiniz. Ayrıca multi‑cluster yaklaşımları ile yatay ölçeklemek mümkün olur.

8. GERÇEK DÜNYA KULLANIMLARI

Netflix — Traffic locality ve fault domains

Netflix ölçeğinde scheduling politikaları, trafikte locality, rack/zone aware placement ve progressive rollout stratejileri ile entegre edilir. Scheduler konfigürasyonları, canary ve chaos testleriyle doğrulanır.

Uber — Regional & edge scheduling

Uber türü uygulamalar bölgesel scheduler tercihleri, edge node'lara özel placement ve latency‑aware routing ile çalışır. Özel scheduler plugin'leri ile region sensiitivity sağlanır.

Amazon / EKS — GPU havuzları ve batch iş yükleri

EKS üzerinde GPU havuzları yönetilirken, scheduler policy'ları batch işlerini spot node'lara yönlendirir ve priority queue'lar ile adil paylaştırma sağlanır.

OpenAI — Model training job'ları

Büyük model training job'ları genelde cluster resource orchestration ve scheduling optimizasyonu gerektirir. Pod dağıtımı, data locality ve GPU packing, scheduler'ın merkezi rolünü artırır.

9. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Kaynakların efektif kullanımı ve iş yükleri için adil yerleştirme
• Özelleştirilebilirlik: plugin, extender veya custom scheduler ile farklı ihtiyaçlara çözüm
• Priority ve preemption ile kritik iş yükleri için garanti tanımlayabilme

Sınırlamalar

• Scheduler konfigürasyonu karmaşıklaşabilir ve yanlış politika üretim stabilitesini etkileyebilir
• GPU/accelerator fragmentasyonu ve bin packing problemleri
• Preemption operasyonel etkiler yaratır; dikkatli plan gerekir

10. EN İYİ PRATİKLER

Production için tavsiyeler

• Kaynak isteklerini (requests) ve limitleri (limits) her pod için tanımlayın; scheduler doğru karar verebilmek için bu veriye ihtiyaç duyar.
• PriorityClass ve PodDisruptionBudget (PDB) kombinasyonları ile preemption risklerini kontrol altına alın.
• Taints/tolerations ile node sınıflandırması yapın (GPU, spot, high‑mem) ve pod'ları uygun sınıflara yönlendirin.
• Affinity/AntiAffinity ve topology spread constraints ile availability zone bazlı dağılım sağlayın.

Performans optimizasyonu

• Scheduler plugin'leri dikkatle seçin; gereksiz plugin'leri devre dışı bırakın.
• Large cluster'larda scheduler latency'yi izleyin ve queue backlog'u azaltmak için partitioning uygulayın.
• GPU/accelerator için custom packing algoritmaları uygulayan plugin'leri değerlendirin.

Güvenlik ve operasyon

• Scheduler tarafından tetiklenen binding ve preemption olaylarını audit log'ları ile takip edin.
• Custom scheduler veya extender'lar kullanıyorsanız, bunları RBAC ile sınırlandırın ve yüksek güvenlik standartlarında çalıştırın.

11. SIK YAPILAN HATALAR

• Pod kaynak taleplerini belirtmemek: scheduler yanlış yerleştirme yapar.
• Preemption politikalarını plansız kullanmak: beklenmedik iş kesintilerine yol açar.
• GPU ve özel kaynaklar için packing stratejisi uygulanmaması: kaynak israfı olur.
• Custom extender'ları test etmeden prod ortamına almak: hatalı yerleştirmeler meydana gelir.

12. GELECEK TRENDLER

1. AI‑assisted scheduling: ML tabanlı scheduler karar destek sistemleri, workload behavior'ını öngörerek daha iyi placement kararları alacak.
2. Topology & energy aware scheduling: Data center enerji tüketimi ve thermal bölgelere göre scheduler optimizasyonları gelecekte önem kazanacak.
3. Federated ve multi‑cluster scheduling: Global application placement, gecikme ve maliyet optimizasyonu için yaygınlaşacak.
4. Scheduler as a Service: Merkezi scheduler çözümleri veya control plane'in scheduler yeteneklerini cloud sağlayıcılar üzerinden optimize edilmiş hizmet olarak sunması artacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Scheduler neden bazı pod'ları preempt eder?

   Preemption, yüksek öncelikli (priority) bir pod için yer açmak amacıyla düşük öncelikli pod'ların sonlandırılmasıdır. Bu mekanizma, kritik iş yüklerinin kaynak bulmasını sağlar ancak dikkatle konfigüre edilmelidir.

2. 2. Custom scheduler yazmak ne zaman gereklidir?

   Özel donanım, lisans kısıtları veya çok sofistike packing algoritmaları gibi varsayılan kube‑scheduler'ın karşılamadığı gereksinimler varsa custom scheduler veya plugin geliştirmek gerekebilir.

3. 3. Scheduler latency nasıl izlenir?

   Scheduler metrics (kube_scheduler_schedule_attempts_total, kube_scheduler_scheduling_duration_seconds) Prometheus üzerinden izlenebilir. Queue length, schedule latency ve bind süreleri takip edilmelidir.

4. 4. Taints vs NodeAffinity farkı nedir?

   Taints node tarafında konulur ve toleration olmayan pod'ları engeller; NodeAffinity pod tarafında kurallar tanımlar ve tercih/zaruret bazlı yerleşim sağlar. İkisi farklı amaçlara hizmet eder ve birlikte kullanılabilir.

5. 5. GPU scheduling için hangi ekstra önlemler alınmalı?

   Device plugin'ler, resource requests doğru şekilde set edilmelidir; ayrıca packing stratejileri ve fragmentation önleyici algortimalar test edilmelidir. MIG veya multi‑instance GPU özellikleri varsa bunlar da değerlendirilmelidir.

6. 6. Extender nedir ve ne zaman kullanılır?

   Extender, scheduler'ın dış bir servise danışarak node uygunluğunu veya scoring'i genişletmesini sağlar. Lisans kontrolü, özel veri tabanı yerleşimi veya üçüncü taraf kaynak planlayıcı entegrasyonlarında kullanılır.

7. 7. Çok büyük cluster'larda scheduler nasıl ölçeklenir?

   Partitioning, node pool bazlı ayrım, multi‑cluster yaklaşımları ve scheduler performans tuning ile büyük cluster'larda scheduling throughput artırılabilir. Ayrıca gereksiz plugin'lerin kapatılması önemlidir.

8. 8. Preemption etkilerini azaltmak için ne yapabilirim?

   PodDisruptionBudget'lar, PriorityClass tasarımı ve fazlı rollout stratejileri ile preemption etkisi minimize edilebilir. Ayrıca critical workload'lar için dedicated node pool'lar kullanmak da çözüm sunar.

Anahtar Kavramlar

Filter (Predicate)

Pod için uygun olmayan node'ları eleyen koşullar.

Score (Priority)

Uygun node'lar arasından en iyi node'u seçmek için verilen puan.

Preemption

Yüksek öncelikli pod yerleşimi için düşük öncelikli pod'ların sonlandırılması.

Extender

Scheduler davranışını dış servislerle genişleten mekanizma.

Plugin

Scheduler lifecycle'ına müdahale eden modüler uzantılar (filter/score/reserve vs.).

Öğrenme Yol Haritası

1. 0–1 ay: Kubernetes scheduler'ın temel işleyişini, pod lifecycle'ını ve temel kaynak kavramlarını öğrenin.
2. 1–3 ay: NodeAffinity, PodAffinity, Taints/Tolerations, PriorityClass ve PDB konularında uygulama yapın.
3. 3–6 ay: Scheduler metrics, preemption senaryoları ve scheduler pluginlerini inceleyin; küçük bir custom plugin yazın veya extender entegrasyonu deneyin.
4. 6–12 ay: GPU scheduling, multi‑cluster scheduling ve scheduler performans tuning konularında deneyim kazanın; production‑grade scheduling policy'leri tasarlayın.