Kubernetes API'sinin öncelikli işlerinden biri, kümedeki worker düğümlerine, pod'ları doğru şekilde dağıtmaktır. Bu görev, Kubernetes Scheduler adında Kubernetes kümesindeki özel bir uygulama tarafından gerçekleştirilir.

Kubernetes ile birbirinden farklı bir çok uygulamayı, birden çok sunucuyu birbiri ile bir bütün şeklinde kullanarak dağıtabilir ve yönetebilirsiniz. Bu çok farklı uygulamaların hepsinin aynı kümede uyum içinde çalışmasını sağlamanın yolu, her bir pod'un kendisine en uygun düğüme yerleştirilmesini sağlayan job scheduling'dir.

Bir pod ilk kez oluşturulduğunda, genellikle bir nodeName alanına sahip değildir. nodeName, pod'un çalıştırılması gereken düğümü belirtir. Kubernetes Scheduler, nodeName özelliği olmayan pod'lar için sürekli olarak API sunucusunu (bir watch isteği yoluyla) takip eder, bunlar schedule için uygun olan podlardır. Scheduler daha sonra pod için uygun bir düğümü seçer ve pod tanımını, Scheduler'ın seçtiği düğüm adı ile değiştirir. nodeName ayarlandıktan sonra, bu düğümde çalışan kubelet pod'un varlığı hakkında bilgilendirilir ve bu pod'u o düğümde çalıştırmaya başlar.

Scheduler'ı atlamak istiyorsanız, nodeName öğesini her zaman kendiniz bir pod'da ayarlayabilirsiniz. Bu doğrudan bir pod'u belirli bir düğüme dağıtır. Özel durumlar haricinde pod dağıtımı işini Scheduler'a bırakmak en doğrusudur. Örneğin kümede bir düğümü sadece tek bir uygulama için kullanmak isterseniz nodeName alanını belirtmeniz gerekir. Aksi halde pod diğer düğümlere dağıtılabilir.

Schedule Süreci

Scheduler, bir düğüme atanmamış olan bir pod'u bulduğunda, pod'u hangi düğüme dağıtacağını belirlemelidir. Bir pod için doğru düğüm, bazıları kullanıcı tarafından sağlanan ve bazıları Scheduler tarafından hesaplanan bir kaç farklı faktör tarafından belirlenir. Scheduler, belirli pod için en iyi düğümü bulurken çeşitli kriterleri optimize etmeye çalışır.

Predicates

Bir pod'un nasıl programlanacağı konusunda karar verirken, Scheduler karar vermek için iki genel kavram kullanır. Birincisi predicate'lerdir. İhlal edildiğinde, bir pod'un o düğümde doğru veya hiç çalışmamasına yol açan önemli kısıtlamalardır.

Örnek olarak, pod tarafından istenen bellek miktarı gösterilebilir. Bu bellek düğümde kullanılamıyorsa, pod ihtiyacı olan tüm belleği alamaz ve kısıtlama ihlal edilir. Başka bir örnek olarak node-selector belirtilerek seçim yapılmaya çalışılırsa ve seçime uygun düğüm yoksa o zamanda ihlal edilmiş olur.

Aşağıda filtre için kontrol edilen bazı kriterler ve açıklamaları var. Ayrıntılı liste için bu sayfayı inceleyebilirsiniz.

• PodFitsHostPorts:
  Bir düğümde, Pod'un istediği pod bağlantı noktaları için boş bağlantı noktaları olup olmadığını kontrol eder.

• PodFitsHost:
  Pod'un ana bilgisayar adına göre belirli bir düğümü belirtip belirtmediğini kontrol eder.

• PodFitsResources:
  Düğümün, pod'un gereksinimlerini karşılamak için boş kaynaklara (ör. CPU ve Bellek) sahip olup olmadığını kontrol eder.

• PodMatchNodeSelector:
  Pod node-selector değerine sahip bir düğüm olup olmadığını kontrol eder.

• NoDiskConflict:
  Bir pod'un istediği birimler ve zaten bağlanmış olan birimler nedeniyle düğüme sığıp sığmayacağını değerlendirir.

• CheckNodeMemoryPressure:
  Bir düğüm bellek baskısını bildiriyorsa ve yapılandırılmış bir istisna yoksa, pod orada dağıtılmayacaktır.

• CheckNodeDiskPressure:
  Bir düğüm depolama kapasitesinin yetersiz olduğunu bildiriyorsa (dolu veya neredeyse dolu bir dosya sistemi) ve özel bir istisna yoksa, pod orada dağıtılmayacaktır.

Priorities

Bu tercihler priorities yada priority functions olarak ifade edilir. Öncelikli bir işlevin rolü, belirli bir düğüme bir pod dağıtmanın göreceli değerini puanlamaktır. Öngörülerin aksine, öncelik işlevi düğüme programlanan pod'un geçerli olup olmadığını göstermez. pod'un düğümde başarılı bir şekilde yürütülebileceği varsayılır.

Örnek olarak, bir priority fonksiyonu docker image'ın önceden çekildiği düğümleri ağırlıklandıracaktır. Bu nedenle, pod kullanması gereken image'ın olmadığı ve çekilmesi gereken düğümlere göre ağırlıklı düğümlerde daha hızlı başlayacak ve pod başlangıcını hızlandıracaktır.

Önemli bir priority fonksiyonu spreading fonksiyonudur. Bu işlev, aynı Kubernetes Service'e ait olan pod'ların bulunmadığı düğümlerin önceliklendirilmesinden sorumludur. Bu şekilde aynı servisteki pod'lar olabildiğince farklı düğümlere dağılarak herhangi bir düğüm arızasında en az kesinti yaşamayı sağlar.

Bu şekilde birçok kriter kontrol edilip ağırlıklandırılarak uygun düğüm seçimi için kullanılır.

Aşağıda filtre için kontrol edilen bazı kriterler ve açıklamaları var. Ayrıntılı liste için bu sayfayı inceleyebilirsiniz.

• LeastRequestedPriority:
  Daha az kaynak gerektiren düğümleri destekler. Yani bir düğüme ne kadar çok pod yerleştirilirse ve bu pod'lar ne kadar çok kaynak kullanırsa, bu değerin sıralaması o kadar düşük olur.

• MostRequestedPriority:
  En çok istenen kaynaklara sahip düğümleri destekler. Bu politika, planlanan podleri, genel iş yükleri kümenizi çalıştırmak için gereken en az sayıda düğüme sığdırır.

• BalancedResourceAllocation:
  Dengeli kaynak kullanımına sahip düğümleri destekler.

• ImageLocalityPriority:
  Pod'un önbelleğe alınmış pod image'larına zaten sahip olan düğümleri tercih eder.

• ServiceSpreadingPriority:
  Halihazırda atanmış Service için Pod'ları olmayan düğümlere dağıtmayı tercih eder.

---

Kaynaklar

• https://github.com/kubernetes/kubernetes/blob/master/pkg/scheduler/core/generic_scheduler.go
• https://kubernetes.io/docs/reference/scheduling/policies
• https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/