Bu yazı Kubernetes Scheduler Nedir? - Bölüm 1 'in devamıdır.

Kubernetes pod'ları düğümlere belli koşullara göre dağıtmayı sağlayan birkaç özelliğe sahiptir.

Node Selectors

Kubernetes'teki her nesne ilişkili bir etiket kümesidir. Etiketler Kubernetes nesneleri için tanımlayıcı meta veriler sağlarken, etiket seçiciler (label selectors) genellikle çeşitli işlemler için API nesne kümelerini dinamik olarak tanımlamak için kullanılır. Örneğin, etiketler ve etiket seçiciler, bir Kubernetes LoadBalancer'ın arkasındaki trafiğe hizmet veren pod gruplarını tanımlamak için kullanılır.

Bir pod tanımlamasında spec.nodeSelector değeri eklenerek belirli bir düğüm kümesine veya tek bir düğüme dağıtılması istenir.

Örnek olarak, SSD gibi yüksek performanslı depolama alanına sahip bir makineye, belirli Pod'lar dağıtılmak istenebilir. Bu özelliğe sahip her makineye aşağıdaki gibi ekstra bir etiket verilecektir:

kind: Node
metadata:
  - labels:
      ssd: true
 ...

Her zaman SSD'ye sahip bir makineye dağıtılacak bir Pod oluşturmak için Pod'un nodeSelector değeri düğümdeki etikete uyacak şekilde ayarlanır:

kind: Pod
spec:
  nodeSelector:
    ssd: true

Kubernetes, varsa, her düğümün nodeSelector etiket sorgusuyla eşleşmesini gerektiren varsayılan bir predicate'e sahiptir. Böylece, ssd etiketine sahip her Pod her zaman uygun donanıma sahip bir düğüme dağıtılacaktır.

Önceki yazıda bahsedildiği gibi, nodeSelector yalnızca planlama sırasında değerlendirilir. Düğümler aktif olarak eklenir ve çıkarılırsa, pod çalıştığında, nodeSelector artık belirtilen düğümle eşleşmeyebilir.

Node Affinity

nodeSelector, bir pod'un belirli bir düğüme dağıtıldığını garanti etmenin basit bir yoludur, ancak esnek değildir. Özellikle, daha karmaşık mantıksal ifadeleri belirtemezler (örneğin, etiket City A yada B ise) veya antiaffinity de belirtemez (örneğin, etiket City A, ancak etiket Disk C değilse).

kind: Pod
---
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              # City == A or B
              - key: City
                operator: In
                values:
                  - A
                  - B

Antiaffinity örneği için, City etiketinin A değerine sahip olduğunu ve Disk etiketinin C'ye eşit olmadığını düşünün:

kind: Pod
---
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              # City == A
              - key: City
                operator: In
                values:
                  - A
              # Disk != C
              - key: Disk
                operator: NotIn
                values:
                  - C

Bir düğüm yerine bir gereksinim (veya bir gereksinime ek olarak) için bir öncelik belirtmek istenirse, preferDuringSchedulingIgnoredDuringExecution öğesi kullanılabilie. Örneğin, City etiketinin A veya B olmasını istediğimiz önceki örneğimizi kullanarak, A etiketli düğümlere zamanlama için bir tercih de ifade edelim. Tercih yapısındaki weight terimi, bir tercihin ne kadar önemli olduğunu ayarlamamızı sağlar.

kind: Pod
---
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              # City == A or B
              - key: City
                operator: In
                values:
                  - A
                  - B
      preferredDuringSchedulingIgnoredDuringExecution:
        preference:
          - weight: 1
            matchExpressions:
              # City == A
              - key: City
                operator: In
                values:
                  - A

requiredDuringSchedulingIgnoredDuringExecution ile verilen koşullar sağlanmalıdır. preferredDuringSchedulingIgnoredDuringExecution ile verilenler ise eğer şartlar sağlanmıyorsa yok sayılarak devam edilir.

Operator olarak kullanılabilecek tüm değerler: In, NotIn, Exists, DoesNotExist, Gt, Lt

Taints and Tolerations

Bazen, uygulamaların davranışlarını değiştirmelerini gerektirmeden pod dağıtımı değiştirilmek istenebilir.

Örneğin, kümeye eklenen yeni düğümler eskilerinden daha yüksek özelliklere sahip olmaya başladı. Bu durumda önceden eklenen düşük güce sahip düğümlere pod dağıtımı yapılması istenmeyebilir. Eski düğümleri işaretleyerek artık onlara dağıtım yapılması engellenebilir.

Tolerations pod'lara uygulanır ve pod'ların eşleşen taints'lere sahip düğümler üzerinde dağıtılmasına izin verir (ancak zorunlu değildir).

Aşağıdaki şekilde node1 düğümüne dağıtım yapılmasını engelleyebilirsiniz.

kubectl taint nodes node1 key=value:NoSchedule

Bu, herhangi bir pod'un, uygun bir toleransa sahip olmadığı sürece node1'e dağıtılamayacığı anlamına gelir.

Kaldırmak için:

kubectl taint nodes node1 key:NoSchedule-

Kaynaklar

• https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/
• https://itnext.io/kubernetes-node-affinity-placing-pods-on-specific-nodes-8ea918dda9b9
• https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/