Scheduling
==========


.. raw:: html

   <!-- SPDX-License-Identifier: CC-BY-4.0 -->

Kubernetesのスケジューリングは、いくつかの基準に基づいて、可能な限り最適なノードに新しいポッドを配置するプロセスです。

..  Note::
   
`Kubernetes documentation <https://kubernetes.io/docs/concepts/scheduling-eviction/>`_ を参照してください。

使用可能なすべてのポリシーを含むスケジュールの詳細については、
をご覧ください。このページでは、アフィニティ、アンチアフィニティ、ノードセレクターなどの概念に精通していることを前提としています。
　

:ref:`AffinityConfiguration <AffinityConfiguration>` を介してCloudNativePGクラスターのインスタンスをスケジュールする方法を制御できます

クラスターの定義のセクション。以下をサポートします。

- ポッドアフィニティ/アンチアフィニティ

- ノードセレクター

- 許容範囲

ポッドアフィニティとアンチアフィニティ
--------------------------------------

Kubernetesは、
*アフィニティ*\ および\ *アンチアフィニティ*\ ルールを使用してポッドをスケジュールする場所を制御するメカニズムを提供します。これらのルールを使用すると、そこで既に実行されているワークロードに基づいて、ポッドを特定のノードでスケジュールするかどうか\ *アフィニティ*\ 、または特定のノードで回避するかどうか\ *アンチアフィニティ*\ を指定できます。この機能は、技術的に*\*
ポッド間アフィニティ/アンチアフィニティ**と呼ばれます。

デフォルトでは、CloudNativePGはクラスターインスタンスをできれば別のノードでスケジュールするように構成しますが、
``pgBouncer`` インスタンスは同じノードで実行される場合があります。

例、次の\ ``Cluster`` 仕様の場合

.. code:: yaml

   apiVersion: postgresql.cnpg.io/v1
   kind: Cluster
   metadata:
     name: cluster-example
   spec:
     instances: 3
     imageName: ghcr.io/cloudnative-pg/postgresql:18.1-system-trixie

     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: cnpg.io/cluster
                   operator: In
                   values:
                     - cluster-example
                 - key: cnpg.io/podRole
                   operator: In
                   values:
                     - instance
             topologyKey: kubernetes.io/hostname
           weight: 100

この設定では、十分なリソースが利用可能であると仮定して、Kubernetesは3つの異なるノードにまたがって3ノードPostgreSQLクラスターをスケジュールすることを
*優先* します。

ポッドのアンチアフィニティの必要性
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

上記の設定を調整することにより、デフォルトの動作を変更できます。

たとえば、 ``podAntiAffinityType`` を\ ``required``
に設定すると、\ ``preferredDuringSchedulingIgnoredDuringExecution``
の代わりに\ ``requiredDuringSchedulingIgnoredDuringExecution``
が適用されます。

ただし、この厳密な要件により、リソースが不十分な場合はポッドが保留されたままになる場合があることに注意してください。これは、Kubernetesクラスターでの自動水平スケーリングに `Cluster Autoscaler <https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler>`_ 
を使用する場合に特に関連します。

..  Note::
   詳細については、 
`Kubernetes documentation <https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity>`_ を参照してください。 　

トポロジの考慮事項
^^^^^^^^^^^^^^^^^^

クラウド環境では、ポッドがノードだけではなく異なるアベイラビリティーゾーンに分散されるように、
``topology.kubernetes.io/zone`` を\ ``topologyKey``
として使用することを検討できます。その他のオプションについては、
`Well-Known Labels, Annotations, and Taints <https://kubernetes.io/docs/reference/labels-annotations-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``
がラベルのリストキーと値のペアとして定義を提供して、ポッドを実行できるノードを選択できます。具体的には、ノードには、スケジュールおよび実行するポッドのラベルとして、指定された各キーと値のペアが必要です。

同様に、CloudNativePGは、 ``affinity`` セクションで\ ``nodeSelector``
を定義することに同意して、これらのラベルを持つノードでのみ実行するPostgreSQLクラスターを要求できます。

許容範囲
--------

Kubernetesでは、 ``taints`` を介して ``tolerations``
を介して明示的に許容しないすべてのポッドをノードが反発するかどうかを指定できます
``taints`` を介して 。

したがって、特定のノードの\ ``taints``
と一致するワークロードに\ ``tolerations``
の適切なセットを設定することにより、Kubernetesスケジューラーは、汚染されたノードを考慮に入れて、ワークロードをスケジュールするノードを決定するようになります。
``.spec.affinity.tolerations``
セクションを介して、クラスターのすべてのポッドの許容値を構成できます。このセクションは、許容値の通常のKubernetes構文を受け入れます。

..  Note::
   taintとtolerationの詳細については、 
`Kubernetes documentation <https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/>`_ を参照してください。 　

PostgreSQLワークロードの分離
----------------------------

..  Note::
   続行する前に、ドキュメントの :ref:`Architecture <Architecture>` セクションを必ず読んでください。 　

さまざまな方法でKubernetesにPostgreSQLを展開できますが、運用環境では次の重要な原則に従うことをお勧めします。

- **アベイラビリティーゾーンのエクスプロイト**
  可能であれば、異なるAZにPostgreSQLインスタンスを分散することにより、同じKubernetesクラスター内のアベイラビリティーゾーンAZを利用します。

- **専用ワーカーノード**
  :ref:`PostgreSQLワークロードのノードの予約 <PostgreSQLワークロードのノードの予約>` で詳細に説明しているように、\ ``node-role.kubernetes.io/postgres``
  ラベルとテイントを介してPostgreSQLワークロードの特定のワーカーノードを割り当てます。

セクション。

- **ノードのオーバーラップの回避**
  同じPostgreSQLクラスターのインスタンスが同じノードで実行されていないことを確認します。

前のセクションで詳しく説明したように、CloudNativePGは、ポッドのアンチアフィニティ、ノードセレクター、および許容範囲を構成する柔軟性を提供します。

以下は、PostgreSQL ``Cluster`` が\ ``postgres``
ノードにデプロイされ、そのインスタンスがさまざまなノードに分散されていることを確認するためのサンプル構成です。

.. code:: yaml

     # <snip>
     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
     # <snip>

そのシンプルさにもかかわらず、このセットアップはPostgreSQLワークロードの最適な分散と分離を保証し、運用環境のパフォーマンスと信頼性の向上につながります。