Datenbankcluster einem Knoten mithilfe der Planung zuweisen

Wählen Sie eine Dokumentationsversion aus:

Beim 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 abgeglichen.

Weitere Informationen zur Planung finden Sie in der Kubernetes-Dokumentation unter Scheduling, Preemption and Eviction.

Auf dieser Seite wird beschrieben, wie Sie in Ihrem Kubernetes-Manifest Toleranzen, Knotenaffinität und Topologie-Streuungseinschränkungen für die Planung von primären Instanzen und Lesepoolinstanzen angeben.

Informationen zum Definieren von Markierungen auf Knoten finden Sie in der Kubernetes-Dokumentation unter Taints and Tolerations.

Toleranzen angeben

Wenn Sie Ihre AlloyDB Omni-Pods auf Knoten planen möchten, die keine anderen Anwendungs-Pods enthalten, oder eine bestimmte Markierung abgleichen 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-Operator-Clusters so, dass es 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 Markierungsschlüssels, z. B. der Hostname eines Knotens oder ein anderer lokal abgeleiteter Wert, auf den sich die Toleranz bezieht. Der Markierungsschlüssel ist bereits auf einem Knoten definiert. Ein leeres Feld und der auf exists gesetzte OPERATOR_VALUE bedeuten, dass die Toleranz alle Werte und alle Schlüssel abgleichen 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 gleicht jeden Wert ab, wenn die Markierung unabhängig vom Wert der Markierung definiert ist.
      • equal: Kubernetes plant einen Pod nicht auf einem Knoten, wenn die Werte unterschiedlich sind. Der Operator erfordert den Markierungswert true.
    • VALUE: Der Markierungswert, mit dem die Toleranz übereinstimmen muss. Wenn der Operator „Exists“ ist, ist der Wert leer. Andernfalls ist er ein regulärer String. Beispiel: true.
    • TAINT_EFFECT: Gibt den Markierungseffekt an, der abgeglichen werden soll. Ein leeres Feld bedeutet, dass alle Markierungseffekte abgeglichen werden 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, es sei denn, es 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 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, welche Knoten für die Ausführung Ihrer Datenbank geplant werden müssen:

  1. Ändern Sie das Manifest des Datenbankclusters so, dass es nach dem Abschnitt tolerations im Abschnitt schedulingConfig den Abschnitt nodeaffinity enthält. Verwenden Sie entweder primarySpec für primäre Instanzen oder spec für Lesepoolinstanzen: 
          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 den Pod auf einem anderen Knoten im Cluster.
    • WAIT_VALUE: Gibt das Gewicht der Präferenz für die angegebenen Knoten an. Höhere Werte weisen auf eine stärkere Präferenz hin. Gültige Werte sind 1 bis 100.
    • LABEL_KEY: Das Label des Knotens 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 für den Parameter ein Array von Stringwerten fest:
      • 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.

Topologie-Streuungseinschränkungen definieren

Das Feld topologySpreadConstraints in der spec der Kubernetes Pod API und folglich in der schedulingConfig der AlloyDB Omni-Datenbankcluster-Manifeste steuert, wie Pods auf verschiedene Topologiedomains wie Zonen, Knoten oder Regionen in Ihrem Cluster verteilt werden. Dies trägt zu einer hohen Verfügbarkeit und einer ausgewogenen Ressourcenauslastung bei, indem verhindert wird, dass zu viele AlloyDB Omni-Datenbankcluster-Pods an einem einzelnen Fehlerpunkt landen.

Wenn Sie angeben möchten, wie Ihr AlloyDB Omni-Datenbankcluster auf Ihre Clustertopologie verteilt werden soll, fügen Sie den Abschnitt topologySpreadConstraints in die schedulingConfig von primarySpec für primäre Instanzen oder spec für Lesepoolinstanzen ein:

schedulingconfig:
      # Other scheduling configs like tolerations, nodeaffinity
      topologySpreadConstraints:
        - maxSkew: MAXSKEW_VALUE
          topologyKey: "TOPOLOGY_KEY"
          whenUnsatisfiable: WHEN_UNSATISFIABLE_VALUE
          # labelSelector: <object> # optional
          # minDomains: <integer> # optional
          # matchLabelKeys: <list> # optional
          # nodeAffinityPolicy: [Honor|Ignore] # optional
          # nodeTaintsPolicy: [Honor|Ignore] # optional

Ersetzen Sie Folgendes:

  • MAXSKEW_VALUE: Definiert die maximal zulässige Differenz in der Anzahl der übereinstimmenden Pods zwischen zwei Topologiedomains. Dieser Parameter muss größer als 0 sein.
  • TOPOLOGY_KEY: Der Schlüssel der Knotenlabels, der eine Topologiedomain definiert, z. B. topology.kubernetes.io/zone für Zonen. Der Planer versucht, Pods auf diese Domains zu verteilen.
  • WHEN_UNSATISFIABLE_VALUE: Gibt an, wie der Planer mit einem Pod umgeht, wenn der Pod die Streuungseinschränkung nicht erfüllt. Legen Sie für den Parameter einen der folgenden Werte fest:
    • DoNotSchedule: Der Planer plant den Pod nicht auf einem Knoten, wenn die Streuungseinschränkung nicht erfüllt ist. Dies ist der Standardwert.
    • ScheduleAnyway: Der Planer plant den Pod trotzdem, priorisiert aber Knoten, die die Abweichung minimieren.

Weitere Informationen zu Streuungseinschränkungen für Pod-Topologien finden Sie in der offiziellen Kubernetes-Dokumentation.

Beispiel

Das folgende Beispiel veranschaulicht die Planung von Pods in primären Instanzen und Lesepoolinstanzen des AlloyDB Omni Kubernetes-Operators. Eine solche Planung 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
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "topology.kubernetes.io/zone"
          whenUnsatisfiable: DoNotSchedule

Die Beispieltoleranz ermöglicht die Planung des Pods auf Knoten, die als Knoten der Steuerungsebene markiert sind, da Folgendes gilt:

  • Der Markierungsschlüssel node-role.kubernetes.io/control-plane gibt an, dass der Knoten ein Knoten der Steuerungsebene ist.
  • Der Operator Exists bedeutet, dass die Toleranz unabhängig vom Wert mit jeder Markierung mit dem angegebenen Markierungsschlüssel übereinstimmt.
  • Der Effekt NoSchedule bedeutet, dass Pods nicht auf dem Knoten der Steuerungsebene geplant werden, es sei denn, sie haben eine übereinstimmende Toleranz.

Der Knotenaffinitätstyp preferredDuringSchedulingIgnoredDuringExecution gibt an, dass die für die Knotenaffinität definierten Regeln bevorzugt werden, aber während der Planung 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 Kriterien für die Knotenauswahl sind 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 stellt den Schlüssel des abzugleichenden Knotenlabels dar. 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 eine Präferenz für die Planung des Pods auf Knoten an, die das Label another-node-label-key mit dem Wert another-node-label-value haben. Die Präferenz ist schwach, daher ist sie keine strenge Anforderung.

Die topologySpreadConstraints in diesem Beispiel verteilen Pods auf verschiedene Kubernetes-Zonen. Der Wert maxSkew von 1 gibt an, dass in einer bestimmten Zone höchstens ein Pod mehr vorhanden sein darf als in einer anderen Zone. Die Einstellung whenUnsatisfiable mit dem Wert DoNotSchedule bedeutet, dass der Pod nicht geplant wird, wenn diese Einschränkung nicht erfüllt werden kann.

Das Beispiel kombiniert Folgendes:

  • Toleranzen, die die Planung des Pods auf Knoten der Steuerungsebene ermöglichen, indem sie die Markierung NoSchedule tolerieren.
  • Eine Knotenaffinität, die Knoten mit einem bestimmten Label bevorzugt, aber nicht zwingend erfordert. Daher bietet sie Flexibilität bei der Planung.
  • Topologie-Streuungseinschränkungen, die eine ausgewogene Verteilung von Pods auf Verfügbarkeitszonen erzwingen und so die Ausfallsicherheit verbessern und die Ressourcenauslastung optimieren.

Nächste Schritte