Scheduling ========== Kubernetesのスケジューリングは、いくつかの基準に基づいて、可能な限り最適なノードに新しいポッドを配置するプロセスです。 .. Seealso:: :ref:`Kubernetes documentation ` を参照してください。 使用可能なすべてのポリシーを含むスケジュールの詳細については、 をご覧ください。このページでは、アフィニティ、アンチアフィニティ、ノードセレクターなどの概念に精通していることを前提としています。 :ref:`アフィニティ <アフィニティ>` を介してEDB Postgres for Kubernetesクラスターのインスタンスをスケジュールする方法を制御できます クラスターの定義のセクション。以下をサポートします。 - ポッドアフィニティ/アンチアフィニティ - ノードセレクター - 許容範囲 ポッドアフィニティとアンチアフィニティ -------------------------------------- Kubernetesは、 *アフィニティ*\ および\ *アンチアフィニティ*\ ルールを使用してポッドをスケジュールする場所を制御するメカニズムを提供します。これらのルールを使用すると、そこで既に実行されているワークロードに基づいて、ポッドを特定のノードでスケジュールするかどうか\ *アフィニティ*\ 、または特定のノードで回避するかどうか\ *アンチアフィニティ*\ を指定できます。この機能は、技術的に*\* ポッド間アフィニティ/アンチアフィニティ**と呼ばれます。 デフォルトでは、KubernetesのEDB Postgresは、できれば別のノードでスケジュールされるようにクラスターインスタンスを構成しますが、 ``pgBouncer`` インスタンスは同じノードで実行される場合があります。 例、次の\ ``Cluster`` 仕様の場合 .. code:: yaml apiVersion: postgresql.k8s.enterprisedb.io/v1 kind: Cluster metadata: name: cluster-example spec: instances: 3 imageName: quay.io/enterprisedb/postgresql:17.4 affinity: enablePodAntiAffinity: true # Default value topologyKey: kubernetes.io/hostname # Default value podAntiAffinityType: preferred # Default value storage: size: 1Gi インスタンスポッドに適用される\ ``affinity`` 構成は次のとおりです。 .. code:: yaml affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: labelSelector: matchExpressions: - key: k8s.enterprisedb.io/cluster operator: In values: - cluster-example - key: k8s.enterprisedb.io/podRole operator: In values: - instance topologyKey: kubernetes.io/hostname weight: 100 この設定では、十分なリソースが利用可能であると仮定して、Kubernetesは3つの異なるノードにまたがって3ノードPostgreSQLクラスターをスケジュールすることを *優先* します。 ポッドのアンチアフィニティの必要性 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 上記の設定を調整することにより、デフォルトの動作を変更できます。 たとえば、 ``podAntiAffinityType`` を\ ``required`` に設定すると、\ ``preferredDuringSchedulingIgnoredDuringExecution`` の代わりに\ ``requiredDuringSchedulingIgnoredDuringExecution`` が適用されます。 ただし、この厳密な要件により、リソースが不十分な場合にポッドが保留されたままになる場合があることに注意してください。これは、Kubernetesクラスターでの自動水平スケーリングに `Cluster Autoscaler `_ を使用する場合に特に関連します。 .. Seealso:: 詳細については、 :ref:`Kubernetes documentation ` を参照してください。 トポロジの考慮事項 ^^^^^^^^^^^^^^^^^^ クラウド環境では、ポッドがノードだけではなく異なるアベイラビリティーゾーンに分散されるように、 ``topology.kubernetes.io/zone`` を\ ``topologyKey`` として使用することを検討できます。その他のオプションについては、 `Well-Known Labels, Annotations, and Taints `_ を参照してください。 アンチアフィニティポリシーの無効化 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 必要に応じて、\ ``enablePodAntiAffinity`` を\ ``false`` に設定することにより、オペレーター生成のアンチアフィニティポリシーを無効にできます。 カスタムルールを使用したきめの細かい制御 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ より正確な制御が必要なシナリオの場合、 ``additionalPodAffinity`` および\ ``additionalPodAntiAffinity`` 構成属性を使用して、カスタムポッドアフィニティまたはアンチアフィニティルールを指定できます。これらのカスタムルールは、オペレーターが有効になっている場合は生成されたルールに追加され、オペレーター生成ルールが無効になっている場合は直接使用されます。 .. Note:: `additionalPodAntiAffinity` または`additionalPodAffinity` を使用する場合、Pod仕様で想定されている完全な`podAntiAffinity` または`podAffinity` 構造を提供する必要があります。次のYAML例は、どのPostgreSQLクラスターに属しているかに関係なく、ワーカーノードごとにPostgreSQLのインスタンスを1つだけ構成する方法を示しています。 .. code:: yaml additionalPodAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: postgresql operator: Exists values: [] topologyKey: "kubernetes.io/hostname" ``nodeSelector`` によるノード選択 --------------------------------- Kubernetesでは、 ``nodeSelector`` がラベルのリストキーと値のペアとして定義を提供して、ポッドを実行できるノードを選択できます。具体的には、ノードには、スケジュールおよび実行するポッドのラベルとして、指定された各キーと値のペアが必要です。 同様に、KubernetesのEDB Postgresは、 ``affinity`` セクションで\ ``nodeSelector`` を定義することに同意して、これらのラベルを持つノードでのみ実行するPostgreSQLクラスターを要求できます。 許容範囲 -------- Kubernetesでは、 ``taints`` を介して ``tolerations`` を介して明示的に許容しないすべてのポッドをノードが反発するかどうかを指定できます ``taints`` を介して 。 したがって、特定のノードの\ ``taints`` と一致するワークロードに\ ``tolerations`` の適切なセットを設定することにより、Kubernetesスケジューラーは、汚染されたノードを考慮に入れて、ワークロードをスケジュールするノードを決定するようになります。 ``.spec.affinity.tolerations`` セクションを介して、クラスターのすべてのポッドの許容値を構成できます。このセクションは、許容値の通常のKubernetes構文を受け入れます。 .. Seealso:: taintとtolerationの詳細については、 :ref:`Kubernetes documentation ` を参照してください。 PostgreSQLワークロードの分離 ---------------------------- .. Important:: 続行する前に、ドキュメントの :ref:`アーキテクチャ <アーキテクチャ>` セクションを必ず読んでください。 さまざまな方法でKubernetesにPostgreSQLを展開できますが、運用環境では次の重要な原則に従うことをお勧めします。 - **アベイラビリティーゾーンのエクスプロイト** 可能であれば、異なるAZにPostgreSQLインスタンスを分散することにより、同じKubernetesクラスター内のアベイラビリティーゾーンAZを利用します。 - **専用ワーカーノード** :ref:`PostgreSQLワークロードのノードの予約 ` で詳細に説明しているように、\ ``node-role.kubernetes.io/postgres`` ラベルとテイントを介してPostgreSQLワークロードの特定のワーカーノードを割り当てます。 セクション。 - **ノードのオーバーラップの回避** 同じPostgreSQLクラスターのインスタンスが同じノードで実行されていないことを確認します。 前のセクションで詳しく説明したように、Kubernetes用EDB Postgresは、ポッドのアンチアフィニティ、ノードセレクター、および許容範囲を構成する柔軟性を提供します。 以下は、PostgreSQL ``Cluster`` が\ ``postgres`` ノードにデプロイされ、そのインスタンスがさまざまなノードに分散されていることを確認するためのサンプル構成です。 .. code:: yaml # affinity: enablePodAntiAffinity: true topologyKey: kubernetes.io/hostname podAntiAffinityType: required nodeSelector: node-role.kubernetes.io/postgres: "" tolerations: - key: node-role.kubernetes.io/postgres operator: Exists effect: NoSchedule # そのシンプルさにもかかわらず、このセットアップはPostgreSQLワークロードの最適な分散と分離を保証し、運用環境のパフォーマンスと信頼性の向上につながります。