Knoten mithilfe der Planung einem Datenbankcluster zuweisen

Wählen Sie eine Dokumentationsversion aus:

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 verschiedener Kriterien und verfügbarer Ressourcen wie CPU und Arbeitsspeicher zugeordnet.

Weitere Informationen zur Planung finden Sie in der Kubernetes-Dokumentation unter Planung, vorzeitiges Beenden und Entfernen.

Auf dieser Seite wird beschrieben, wie Sie Toleranzen und Knotenaffinitäts-Planungskonfigurationen für primäre und Lesepool-Instanzen in Ihrem Kubernetes-Manifest angeben.

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

Toleranzen angeben

Wenn Sie Ihre AlloyDB Omni-Pods auf Knoten planen möchten, auf denen keine anderen Anwendungs-Pods ausgeführt werden, oder wenn Sie eine bestimmte Markierung verwenden möchten, 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-Operatorclusters so, dass es im Abschnitt schedulingConfig einen Abschnitt tolerations in einem der folgenden Abschnitte 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 Markierungsschlü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 gesetzt bedeuten, 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 für den Parameter einen der folgenden Werte fest:
      • exists: Kubernetes stimmt mit jedem Wert überein, wenn die Markierung unabhängig vom Wert der Markierung definiert ist.
      • equal: Kubernetes plant keinen Pod auf einem Knoten, wenn die Werte unterschiedlich sind. Der Operator erfordert den Markierungswert true.
    • VALUE: Der Markierungswert, mit dem die Toleranz übereinstimmt. Wenn der Operator „Exists“ ist, ist der Wert leer. Andernfalls ist er ein regulärer String. Beispiel: true.
    • TAINT_EFFECT: Gibt die zu vergleichende Markierungswirkung an. Ein leeres Feld bedeutet, dass alle Taint-Effekte übereinstimmen müssen. Legen Sie für den Parameter einen der folgenden Werte fest:
      • NoSchedule: Kubernetes plant keine neuen Pods auf dem markierten Knoten.
      • PreferNoSchedule: Kubernetes vermeidet es, neue Pods auf dem markierten Knoten zu platzieren, sofern dies nicht erforderlich ist.
      • NoExecute: Kubernetes entfernt vorhandene Pods, die die Markierung nicht tolerieren.
  2. Wenden Sie das Manifest noch einmal an.

Knotenzielgruppe definieren

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

So geben Sie an, auf welchen Knoten Ihre Datenbank ausgeführt werden soll:

  1. Ändern Sie das Manifest des Datenbankclusters so, dass es nach dem Abschnitt tolerations im Abschnitt schedulingConfig entweder von primarySpec für primäre Instanzen oder von spec für Instanzen des Lesepools den Abschnitt nodeaffinity enthält: 
          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 nach den definierten Regeln.
      • preferredDuringSchedulingIgnoredDuringExecution: Der Kubernetes-Planer versucht, einen Knoten zu finden, der die definierte Regel für die Planung erfüllt. Wenn es keinen solchen Knoten gibt, plant Kubernetes die Ausführung auf einem anderen Knoten im Cluster.
    • WAIT_VALUE: Gibt das Gewicht der Präferenz für die angegebenen Knoten an. Höhere Werte deuten auf eine stärkere Präferenz hin. Gültige Werte liegen zwischen 1 und 100.
    • LABEL_KEY: Das Knotenlabel für den Schlüssel, der 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 für den Parameter einen der folgenden Werte 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 Array „values“ muss ein einzelnes Element enthalten, das als Ganzzahl interpretiert wird.
      • Lt: Das Array „values“ muss ein einzelnes Element enthalten, das als Ganzzahl interpretiert wird.
    • LABEL_KEY_VALUE: Der Wert für Ihren Labelschlüssel. Legen Sie den Parameter auf ein Array von Stringwerten fest, wie unten dargestellt:
      • Wenn der Operator In oder NotIn ist, darf das Array „values“ nicht leer sein.
      • Wenn der Operator Exists oder DoesNotExist ist, muss das Array „values“ leer sein.
      • Wenn der Operator Gt oder Lt ist, muss das Array „values“ ein einzelnes Element enthalten, das als Ganzzahl interpretiert wird.
  2. Wenden Sie das Manifest noch einmal an.

Beispiel

Im folgenden Beispiel wird die Planung von Pods in primären Instanzen und Lesepoolinstanzen des AlloyDB Omni Kubernetes-Operators veranschaulicht. Diese Planungseinstellung trägt dazu bei, dass die primäre Instanz des Datenbankclusters auf geeigneten Knoten geplant wird, während gleichzeitig eine gewisse Flexibilität bei der Knotenauswahl besteht. Diese Flexibilität kann nützlich sein, um die Last 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

Die Beispieltoleranz ermöglicht es, den Pod auf Knoten zu planen, die aufgrund der folgenden Details als Knoten der Steuerungsebene markiert sind:

  • Der Taint-Schlüssel node-role.kubernetes.io/control-plane gibt an, dass der Knoten einen Knoten der Steuerungsebene hat.
  • Der Operator Exists bedeutet, dass die Toleranz mit jedem Taint mit dem angegebenen Taint-Schlü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 beim Planen bevorzugt werden, aber nicht erforderlich sind. Wenn die bevorzugten Knoten nicht verfügbar sind, kann der Pod trotzdem auf anderen Knoten geplant werden. Der Gewichtungswert 1 weist auf eine schwache Präferenz hin. Die Auswahlkriterien für Knoten 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 abzugleichenden 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 zur Knotenaffinität gibt eine Präferenz für die Planung des Pods auf Knoten mit dem Label another-node-label-key und dem Wert another-node-label-value an. Die Präferenz ist schwach, daher ist sie keine strenge Anforderung.

Im Beispiel wird Folgendes kombiniert:

  • Toleranzen, die es ermöglichen, dass der Pod auf Knoten der Steuerungsebene geplant wird, indem die Markierung NoSchedule toleriert wird.
  • Eine Knotenaffinität, die Knoten mit einem bestimmten Label bevorzugt, aber nicht zwingend erfordert. Dies bietet Flexibilität bei der Planung.

Nächste Schritte