So legen Sie die Knoten-zu-Knoten-Affinität in kubernetes fest

Question

Wie kann ich einen bestimmten Pod für die Ausführung in einem kubernetes-Cluster mit mehreren Knoten konfigurieren, sodass die Container des POD auf eine Untergruppe der Knoten beschränkt werden?

z. Lassen Sie uns sagen, ich habe A, B, C drei Knoten mit mu kubernetes Cluster.

Wie kann ein Pod so begrenzt werden, dass seine Container nur auf A & B und nicht auf C laufen?

Answer 1

Sie können Labels zu Knoten hinzufügen, auf denen Sie Pod ausführen möchten, und nodeSelector zur Pod-Konfiguration hinzufügen. Das Verfahren wird hier beschrieben:

http://kubernetes.io/docs/user-guide/node-selection/

Also im Grunde möchten Sie

kubectl label nodes A node_type=foo 
kubectl label nodes B node_type=foo 

Und Sie wollen diese nodeSelector in Ihrem pod spec haben:

nodeSelector: 
    node_type: foo 

Answer 2

Zum einen müssen Sie Label zu Knoten hinzufügen. Sie können sich auf die Antwort von Nebril beziehen, wie Sie ein Label hinzufügen können.

Dann empfehle ich Ihnen die Knoten Affinität Funktion nutzen zu können Schoten beschränken mit bestimmten Labels zu den Knoten. Hier ist ein Beispiel.

apiVersion: v1 
kind: Pod 
metadata: 
    name: with-node-affinity 
spec: 
    affinity: 
    nodeAffinity: 
     requiredDuringSchedulingIgnoredDuringExecution: 
     nodeSelectorTerms: 
     - matchExpressions: 
      - key: node_type 
      operator: In 
      values: 
      - foo 
    containers: 
    - name: with-node-affinity 
    image: gcr.io/google_containers/pause:2.0 

Im Vergleich zu nodeSelector, die Affinität/anti-Affinität stark erweitert die Arten von Constraints können Sie äußern.

Weitere Informationen über Knoten Affinität, Sie auf den folgenden Link beziehen: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/

Answer 3

Ich bin nicht in der Lage einen Kommentar zu früheren Antworten zu schreiben, aber ich upvoted die Antwort, die abgeschlossen ist. nodeSelector ist nicht streng erzwungen und sich darauf verlassen kann einige Trauer verursachen, einschließlich Master, der mit Anfragen sowie IOs von Pods, die auf Master geplant sind, überwältigt wird. Zu der Zeit, als die Antwort gegeben wurde, war es vielleicht immer noch die einzige Option, aber in den späteren Versionen ist das nicht so.

Definitiv verwenden nodeAffinity oder nodeAntiAffinity mit requiredDuringSchedulingIgnoredDuringExecution oder preferredDuringSchedulingIgnoredDuringExecution

Weiteren ausdrucken Filter für die Planung peruse: Assigning pods to nodes