スケジューリングの詳細については、Kubernetes ドキュメントのスケジューリング、プリエンプションと退避をご覧ください。
このページでは、Kubernetes マニフェストでプライマリ プール インスタンスと読み取りプール インスタンスの toleration、ノード アフィニティ、トポロジの分散の制約に関するスケジューリング構成を指定する方法について説明します。
ノードで taint を定義する方法については、Kubernetes ドキュメントの Taint と Toleration をご覧ください。
toleration を指定する
他のアプリケーション Pod が存在しないノードに AlloyDB Omni Pod をスケジュールするか、これらのノードで定義された特定の taint と一致させるには、次のように 1 つ以上の toleration をノードに適用します。
- AlloyDB Omni Kubernetes Operator クラスタのマニフェストを変更して、次のいずれかの
schedulingConfigセクションにtolerationsセクションを追加します。- プライマリ インスタンスの場合は
primarySpec - 読み取りプール インスタンスの場合は
spec
tolerations: - key: "TAINT_KEY" operator: "OPERATOR_VALUE" value: "VALUE" effect: "TAINT_EFFECT"次のように置き換えます。
TAINT_KEY: taint キーの既存の一意の名前（ノードのホスト名や、toleration が適用されるローカルで推論された値など）。taint キーはノードにすでに定義されています。フィールドが空で、OPERATOR_VALUEがexistsに設定されている場合、toleration はすべての値とすべてのキーと一致している必要があります。OPERATOR_VALUE: キーと値のセットの関係を表します。パラメータを次のいずれかに設定します。exists: taint が定義されている場合、Kubernetes は taint の値に関係なく任意の値と一致させます。equal: 値が異なる場合、Kubernetes は Pod をノードにスケジュールしません。この演算子には tainttrue値が必要です。
VALUE: toleration と照合される taint 値。演算子が Exists の場合、値は空になります。それ以外の場合は、通常の文字列になります。例:trueTAINT_EFFECT: 一致する taint の効果。フィールドが空の場合、すべての taint 効果が一致する必要があることを意味します。パラメータを次のいずれかに設定します。NoSchedule: Kubernetes は、taint が設定されたノードに新しい Pod をスケジュールしません。PreferNoSchedule: Kubernetes は、必要でない限り、taint が追加されたノードに新しい Pod を配置しません。NoExecute: Kubernetes は、taint を許容しない既存の Pod を強制排除します。
- プライマリ インスタンスの場合は
- マニフェストを再度適用します。
ノード アフィニティを定義する
Kubernetes スケジューラは、Pod の配置場所を決定するために、ノード アフィニティをルールセットとして使用します。ノード アフィニティは、ノードセレクタよりも柔軟で表現性に優れています。
データベースの実行にスケジュールを設定する必要があるノードを指定するには、次の操作を行います。
- データベース クラスタ マニフェストを変更し、
primarySpec（プライマリ インスタンスの場合）またはspec（読み取りプール インスタンスの場合）のschedulingConfigセクションのtolerationsセクションの後にnodeaffinityセクションを追加します。nodeaffinity: NODE_AFFINITY_TYPE: - weight: WAIT_VALUE preference: matchExpressions: - key: LABEL_KEY operator: OPERATOR_VALUE values: - LABEL_KEY_VALUE次のように置き換えます。
NODE_AFFINITY_TYPE: パラメータを次のいずれかに設定します。requiredDuringSchedulingIgnoredDuringExecution: Kubernetes は、定義されたルールに基づいて Pod をスケジュールします。preferredDuringSchedulingIgnoredDuringExecution: Kubernetes スケジューラは、定義されたスケジューリング ルールを満たすノードを探します。そのようなノードがない場合、Kubernetes はクラスタ内の別のノードにスケジュールします。
WAIT_VALUE: 指定したノードの優先度の重み。値が大きいほど優先度が高くなります。有効な値は1～100です。LABEL_KEY: ロケーション インジケーターとして機能し、クラスタ全体に Pod を均等に分散するキーのノードのラベル。例:disktype=ssdOPERATOR_VALUE: キーと値のセットの関係を表します。パラメータを次のいずれかに設定します。-
In: values 配列は空にできません。 -
NotIn: values 配列は空にできません。 -
Exists: values 配列は空にする必要があります。 -
DoesNotExist: values 配列は空にする必要があります。 -
Gt: values 配列には、整数として解釈される単一の要素が必要です。 -
Lt: values 配列には、整数として解釈される単一の要素が必要です。
-
LABEL_KEY_VALUE: ラベルキーの値。次のように、パラメータに文字列値の配列を設定します。- 演算子が
InまたはNotInの場合、値の配列は空にできません。 - 演算子が
ExistsまたはDoesNotExistの場合、値の配列は空にする必要があります。 - 演算子が
GtまたはLtの場合、値の配列には整数として解釈される単一の要素が必要です。
- 演算子が
- マニフェストを再度適用します。
トポロジの分散の制約を定義する
Kubernetes Pod API の spec にあり、そのため AlloyDB Omni データベース クラスタ マニフェストの schedulingConfig にもある topologySpreadConstraints フィールドは、クラスタ内のゾーン、ノード、リージョンなどのさまざまなトポロジ ドメインに Pod を分散する方法を制御します。これにより、単一障害点に AlloyDB Omni データベース クラスタ Pod が過剰に配置されるのを防ぎ、高可用性とバランスの取れたリソース使用率の実現を促進できます。
AlloyDB Omni データベース クラスタがクラスタ トポロジ全体にどのように分散されるかを指定するには、プライマリ インスタンスの場合は primarySpec、読み取りプール インスタンスの場合は spec の schedulingConfig に topologySpreadConstraints セクションを追加します。
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
次のように置き換えます。
-
MAXSKEW_VALUE: 任意の 2 つのトポロジ ドメイン間で一致する Pod の数の許容される最大差を定義します。このパラメータは0より大きい値にする必要があります。 TOPOLOGY_KEY: トポロジ ドメインを定義するノードラベルのキー（例: ゾーンの場合のtopology.kubernetes.io/zone）。スケジューラは、これらのドメイン間で Pod のバランスを取ろうとします。WHEN_UNSATISFIABLE_VALUE: Pod がスプレッド制約を満たしていない場合に、スケジューラが Pod をどのように処理するかを示します。パラメータを次のいずれかに設定します。DoNotSchedule: スプレッド制約が満たされていない場合、スケジューラは Pod をノードにスケジュールしません。これはデフォルト値です。ScheduleAnyway: スケジューラは引き続き Pod をスケジュールしますが、スキューを最小限に抑えるノードを優先します。
Pod トポロジの分散の制約について詳しくは、公式の Kubernetes ドキュメントをご覧ください。
例
次の例は、AlloyDB Omni Kubernetes Operator プライマリ インスタンスと読み取りプール インスタンスで Pod をスケジュールする方法を示しています。このようなスケジューリングにより、データベース クラスタのプライマリ インスタンスが適切なノードにスケジュールされ、ノードの選択に柔軟性を持たせることができます。この柔軟性は、負荷の分散、リソース使用量の最適化、特定のノードロールと特性の遵守に役立ちます。
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
次の詳細により、この toleration の例ではコントロール プレーン ノードとしてマークされているノードで Pod をスケジュールできます。
node-role.kubernetes.io/control-planetaint キーは、ノードにコントロール プレーン ノードがあることを示します。Exists演算子は、toleration が値に関係なく、指定された taint キーを持つ任意の taint と一致することを意味します。NoScheduleの効果は、一致する toleration がなければ、Pod がコントロール プレーン ノードにスケジュールされないことを意味します。
preferredDuringSchedulingIgnoredDuringExecution ノード アフィニティ タイプは、ノード アフィニティに定義されたルールが優先されることを指定しますが、スケジュール時に必須ではありません。優先ノードが使用できない場合、Pod が他のノードにスケジュールされることがあります。1 の重み値は、優先度が低いことを示します。ノードの選択条件は preference セクションで定義されています。matchExpressions セクションには、ノードとの照合に使用される式の配列が含まれています。another-node-label-key キーは、一致するノードラベルのキーを表します。In 演算子は、ノードに指定された値のいずれかを含むキーが存在することを意味します。another-node-label-key キーには another-node-label-value の値を設定する必要があります。
ノード アフィニティ ルールの例は、another-node-label-value 値の another-node-label-key ラベルを持つノードで Pod をスケジュールすることを示しています。優先度は低く、必須ではありません。
この例の topologySpreadConstraints は、Pod を異なる Kubernetes ゾーンに分散します。1 の maxSkew 値は、任意のゾーンで、他のゾーンの最小 Pod 数と比較して、最大 1 つ多くの Pod を配置できることを示します。whenUnsatisfiable 設定の値が DoNotSchedule の場合、この制約を満たせないと、Pod はスケジュールされていない状態のままになります。
この例では、次のものを組み合わせています。
NoScheduletaint を許容して Pod をコントロール プレーン ノードにスケジュールできるようにする toleration。- 特定のラベルを持つノードを優先するが、厳密に要求するものではないノード アフィニティ。これにより、スケジューリングの柔軟性が向上します。
- アベイラビリティ ゾーン間で Pod のバランスの取れた分散を強制し、復元性を高め、リソース使用率を向上させるトポロジの分散の制約。