Knoten mithilfe der Planung einem Datenbankcluster zuweisen

Im AlloyDB Omni Kubernetes-Operator ist die Planung ein Prozess, bei dem neue Datenbank-Pods mit Knoten abgeglichen werden, um die Knotenverteilung im Cluster auszugleichen und die Leistung zu optimieren. Pods und Knoten werden anhand mehrerer Kriterien und verfügbarer Ressourcen wie CPU und Arbeitsspeicher zugeordnet.

Weitere Informationen zur Planung finden Sie in der Kubernetes-Dokumentation unter Planung, Vorwegnahme und Auslagerung.

Auf dieser Seite erfahren Sie, wie Sie Toleranzen und Konfigurationen für die Knotenaffinitätsplanung für primäre und Lesepool-Instanzen in Ihrem Kubernetes-Manifest angeben.

Informationen zum Definieren von Markierungen auf Knoten finden Sie in der Kubernetes-Dokumentation unter Markierungen und Toleranzen.

Toleranzen angeben

Wenn Sie Ihre AlloyDB Omni-Pods auf Knoten planen möchten, die keine anderen Anwendungs-Pods enthalten, oder einer bestimmten Markierung entsprechen, die auf diesen Knoten definiert ist, wenden Sie eine oder mehrere Toleranzen auf die Knoten an:

  1. Ändern Sie das Manifest des AlloyDB Omni Kubernetes-Operator-Clusters so, dass er in einem der folgenden Abschnitte im Abschnitt schedulingConfig einen Abschnitt tolerations enthält:
    • primarySpec für primäre Instanzen
    • spec für Lesepoolinstanzen
         tolerations:
      - key: "TAINT_KEY"
        operator: "OPERATOR_VALUE"
        value: "VALUE"
        effect: "TAINT_EFFECT"

    Ersetzen Sie Folgendes:

    • TAINT_KEY: Der vorhandene eindeutige Name des Taint-Schlüssels, z. B. der Hostname eines Knotens oder ein anderer lokal abgeleiteter Wert, auf den sich die Toleranz bezieht. Der Taint-Schlüssel ist bereits für einen Knoten definiert. Ein leeres Feld und OPERATOR_VALUE auf exists festgelegt bedeutet, dass die Toleranz mit allen Werten und allen Schlüsseln übereinstimmen muss.
    • OPERATOR_VALUE: Stellt die Beziehung eines Schlüssels zu einer Reihe von Werten dar. Legen Sie einen der folgenden Werte für den Parameter fest:
      • exists: Kubernetes gleicht jeden Wert ab, wenn die Beschädigung definiert ist, unabhängig vom Wert der Beschädigung.
      • equal: Kubernetes plant keinen Pod auf einem Knoten, wenn die Werte unterschiedlich sind. Der Operator benötigt den Wert true für die Beschädigung.
    • VALUE: Der Wert der Beschädigung, mit dem die Toleranz übereinstimmt. Wenn der Operator „Exists“ ist, ist der Wert leer. Andernfalls ist es ein regulärer String. Beispiel: true.
    • TAINT_EFFECT: Gibt den zu übereinstimmenden Effekt an. Ein leeres Feld bedeutet, dass alle Beeinflussungseffekte abgeglichen werden müssen. Legen Sie einen der folgenden Werte für den Parameter fest:
      • NoSchedule: Kubernetes plant keine neuen Pods auf dem betroffenen Knoten.
      • PreferNoSchedule: Kubernetes vermeidet es, neue Pods auf dem fehlerhaften Knoten zu platzieren, es sei denn, dies ist erforderlich.
      • NoExecute: Kubernetes entfernt vorhandene Pods, die die Markierung nicht tolerieren.
  2. Wenden Sie das Manifest noch einmal an.

Knotenaffinität definieren

Der Kubernetes-Planer verwendet die Knotenaffinität als Regeln, um zu bestimmen, wo ein Pod platziert werden soll. Die Knotenaffinität ist eine flexiblere und ausdrucksstärkere Version von Knotenselektoren.

So legen Sie fest, welche Knoten für die Ausführung Ihrer Datenbank geplant werden müssen:

  1. Ändern Sie das Manifest des Datenbankclusters so, dass der Abschnitt nodeaffinity nach dem Abschnitt tolerations im Abschnitt schedulingConfig von entweder primarySpec für primäre Instanzen oder spec für Lesepoolinstanzen eingefügt wird: 
          nodeaffinity:
         NODE_AFFINITY_TYPE:
         - weight: WAIT_VALUE
           preference:
             matchExpressions:
             - key: LABEL_KEY
               operator: OPERATOR_VALUE
               values:
               - LABEL_KEY_VALUE

    Ersetzen Sie Folgendes:

    • NODE_AFFINITY_TYPE: Legen Sie für den Parameter einen der folgenden Werte fest:
      • requiredDuringSchedulingIgnoredDuringExecution: Kubernetes plant den Pod genau anhand der definierten Regeln.
      • preferredDuringSchedulingIgnoredDuringExecution: Der Kubernetes-Planer versucht, einen Knoten zu finden, der der definierten Regel für die Planung entspricht. Wenn es keinen solchen Knoten gibt, wird die Ausführung von Kubernetes auf einen anderen Knoten im Cluster geplant.
    • WAIT_VALUE: Gibt das Präferenzgewicht für die angegebenen Knoten an. Je höher der Wert, desto stärker die Präferenz. Gültige Werte sind 1 bis 100.
    • LABEL_KEY: Das Label des Knotens für den Schlüssel, das als Standortindikator dient und eine gleichmäßige Pod-Verteilung im Cluster ermöglicht. Beispiel: disktype=ssd.
    • OPERATOR_VALUE: Stellt die Beziehung eines Schlüssels zu einer Reihe von Werten dar. Legen Sie einen der folgenden Werte für den Parameter fest:
      • In: Das Array „values“ darf nicht leer sein.
      • NotIn: Das Array „values“ darf nicht leer sein.
      • Exists: Das Array „values“ muss leer sein.
      • DoesNotExist: Das Array „values“ muss leer sein.
      • Gt: Das Werte-Array muss ein einzelnes Element enthalten, das als Ganzzahl interpretiert wird.
      • Lt: Das Werte-Array muss ein einzelnes Element enthalten, das als Ganzzahl interpretiert wird.
    • LABEL_KEY_VALUE: Der Wert für Ihren Labelschlüssel. Legen Sie den Parameter wie unten beschrieben auf ein Array von Stringwerten fest:
      • Wenn der Operator In oder NotIn ist, darf das Wertearray nicht leer sein.
      • Wenn der Operator Exists oder DoesNotExist ist, muss das Werte-Array leer sein.
      • Wenn der Operator Gt oder Lt ist, muss das Wertearray ein einzelnes Element enthalten, das als Ganzzahl interpretiert wird.
  2. Wenden Sie das Manifest noch einmal an.

Beispiel

Das folgende Beispiel veranschaulicht die Planung von Pods in primären und Lesepoolinstanzen des AlloyDB Omni Kubernetes-Betriebssystems. Mit dieser Planungseinrichtung wird sichergestellt, dass die primäre Instanz des Datenbankclusters auf geeigneten Knoten geplant wird, während bei der Knotenauswahl eine gewisse Flexibilität besteht. Diese Flexibilität kann nützlich sein, um die Auslastung auszugleichen, die Ressourcennutzung zu optimieren oder bestimmte Knotenrollen und -merkmale einzuhalten.

    schedulingconfig:
      tolerations:
      - key: "node-role.kubernetes.io/control-plane"
        operator: "Exists"
        effect: "NoSchedule"
      nodeaffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 1
          preference:
            matchExpressions:
            - key: another-node-label-key
              operator: In
              values:
              - another-node-label-value

Mit der Beispieltoleranz kann der Pod auf Knoten geplant werden, die aufgrund der folgenden Details als Knoten der Steuerungsebene gekennzeichnet sind:

  • Der node-role.kubernetes.io/control-plane-Taint-Schlüssel gibt an, dass der Knoten einen Knoten der Steuerungsebene hat.
  • Der Operator Exists bedeutet, dass die Toleranz mit jeder Beschädigung mit dem angegebenen Beschädigungsschlüssel übereinstimmt, unabhängig vom Wert.
  • Der Effekt NoSchedule bedeutet, dass Pods nur dann auf dem Knoten der Steuerungsebene geplant werden, wenn sie eine übereinstimmende Toleranz haben.

Der Knotenaffinitätstyp preferredDuringSchedulingIgnoredDuringExecution gibt an, dass die für die Knotenaffinität definierten Regeln bevorzugt, aber nicht erforderlich sind. Wenn die bevorzugten Knoten nicht verfügbar sind, wird der Pod möglicherweise trotzdem auf anderen Knoten geplant. Der Gewichtswert 1 gibt eine schwache Präferenz an. Die Kriterien für die Knotenauswahl werden im Abschnitt preference definiert. Der Abschnitt matchExpressions enthält ein Array von Ausdrücken, die zum Abgleichen von Knoten verwendet werden. Der Schlüssel another-node-label-key steht für den Schlüssel des zu vergleichenden Knotenlabels. Der Operator In bedeutet, dass der Knoten den Schlüssel mit einem der angegebenen Werte haben muss. Der Schlüssel another-node-label-key muss den Wert another-node-label-value haben.

Die Beispielregel für die Knotenaffinität gibt an, dass der Pod bevorzugt auf Knoten mit dem Label another-node-label-key und dem Wert another-node-label-value geplant werden soll. Die Präferenz ist schwach, daher ist sie keine strenge Anforderung.

Das Beispiel kombiniert Folgendes:

  • Toleranzen, die es ermöglichen, den Pod auf Knoten der Steuerungsebene zu planen, indem die NoSchedule-Markierung toleriert wird.
  • Eine Knotenaffinität, bei der Knoten mit einem bestimmten Label bevorzugt werden, dies aber nicht zwingend erforderlich ist. Dadurch ist eine flexible Planung möglich.

Nächste Schritte