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:
- 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?
- 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,
topologySpreadConstraintstanı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.