2025-03-15Hünkar Döner

Kubernetes Scheduler Mantığı ve EKS Davranışları

KubernetesSchedulerEKSInternals
K

Kubernetes Scheduler Mantığı ve EKS Davranışları

Bir pod oluşturduğunuzda, onun hangi Worker Node üzerinde çalışacağına kube-scheduler karar verir. Bu karar süreci, Amazon EKS performansını ve maliyetini doğrudan etkiler.

Scheduling Süreci

Scheduler, her yeni pod için iki aşamalı bir eleme yapar:

  1. Filtering (Eleme): Pod'un çalışamayacağı node'ları eler.
    • Yeterli CPU/RAM var mı?
    • Node üzerindeki Taint'ler (Leke), Pod'un Toleration'ları (Tolerans) ile uyuşuyor mu?
    • Node Selector ve Affinity kuralları tutuyor mu?
  2. Scoring (Puanlama): Kalan node'lara puan verir.
    • Image Locality: Pod'un imajı bu node'da zaten varsa puan artar (daha hızlı başlar).
    • Least Requested: En boş olan node genellikle daha yüksek puan alır (Yük dengeleme).

EKS'te Dikkat Edilmesi Gerekenler

  • AZ Dağılımı: Scheduler, topologySpreadConstraints tanımlamazsanız podları aynı AZ'ye yığabilir. Bu HA riskidir.
  • Bin Packing vs Load Balancing: Scheduler varsayılan olarak yükü dağıtmaya çalışır (Least Requested). Ancak maliyet optimizasyonu (Karpenter) için podları sıkıştırmak (Bin Packing) isterseniz, Scheduler profillerini değiştirmeniz gerekebilir.

Podlarınızın "Pending" kalmasının nedeni genellikle Scheduler'ın uygun bir node bulamamasıdır. kubectl describe pod <pod-name> komutu, Scheduler'ın neden başarısız olduğunu (Örn: Insufficient cpu) size net bir şekilde söyler.