Scheduling

Best Practices für Pod Scheduling (Affinity, Topology Spread Constraints, etc.).

Was ist Scheduling?

Scheduling in Kubernetes ist der Prozess der Zuweisung von Pods zu Nodes. Während der Scheduler dies automatisch basierend auf Ressourcenverfügbarkeit tut, können Sie diese Entscheidung mit Regeln beeinflussen. Node Affinity zieht Pods zu einer Gruppe von Nodes an (z.B. "laufe nur auf SSD Nodes"). Pod Affinity/Anti-Affinity zieht Pods relativ zu anderen Pods an oder stösst sie ab (z.B. "keine zwei Datenbank-Replikas auf demselben Node ausführen").

Offizielle Kubernetes Scheduling Dokumentation

NodeSelector / NodeAffinity (NodeAutoscaler)

Node Autoscaling (z.B. auf GCP) erfordert einen nodeSelector oder nodeAffinity, um zu wissen, welcher Node-Pool skaliert werden soll.

TopologySpreadConstraints

Pod Topology Spread Constraints sollten wann immer möglich mit der folgenden Konfiguration verwendet werden:

• kubernetes.io/hostname: DoNotSchedule (wenn wir absolut sicherstellen wollen, dass Workloads über mehrere Nodes verteilt werden, ansonsten ScheduleAnyway verwenden)
• topology.kubernetes.io/zone: ScheduleAnyway (Pods über verschiedene Stromkreise verteilen)

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: ScheduleAnyway  ## oder DoNotSchedule
    nodeTaintsPolicy: Honor
    labelSelector:
      matchLabels:
        app.kubernetes.io/instance: metrics-server
    # topologySpreadConstraint nur auf Pods derselben StatefulSet Revision anwenden
    matchLabelKeys:
      - controller-revision-hash
    # topologySpreadConstraint nur auf Pods derselben Deployment Revision anwenden
    matchLabelKeys:
      - pod-template-hash

Beachten Sie, dass wenn Sie keinen nodeSelector oder nodeAffinity definieren, alle Nodes für den TopologySpreadConstraint ausgewählt werden, ungeachtet ihrer Taints. Wenn Sie nur Nodes einschliessen möchten, auf denen der Pod gescheduled werden kann (Nodes ohne Taints und Nodes mit Taints, für die der Pod Tolerations hat), setzen Sie nodeTaintsPolicy: Honor.

Topology Pod Labels

Die folgenden Labels können verwendet werden, um Pods über verschiedene Nodes/Zonen zu verteilen:

PodAntiAffinity

Anstatt topologySpreadConstraints können Sie auch podAntiAffinity verwenden, um Replicas über verschiedene Nodes zu verteilen. Wichtig: Funktioniert nur, wenn Deployment-Grösse <= Node-Grösse, da Anti-Affinity einen einzelnen Pod auswählt.

# preferred
affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        topologyKey: kubernetes.io/hostname
        labelSelector:
          matchLabels:
            gitops.natron.io/application: app1

# required
affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - topologyKey: kubernetes.io/hostname
      labelSelector:
        matchLabels:
          gitops.natron.io/application: app1

PriorityClass

Pod Priority und Preemption Klassen verfügbar:

Verwenden Sie preemptionPolicy: Never falls nötig.

nodeSelector:
  disktype: ssd

Affinity

Erweiterte Scheduling-Regeln.

Pod Anti-Affinity

Pods über Nodes/Zonen verteilen für Hochverfügbarkeit.

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - services
        topologyKey: kubernetes.io/hostname

Topology Spread Constraints

Gleichmässige Verteilung von Pods sicherstellen.

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: services