Scheduling

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

Kubernetes documentation を参照してください。

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

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

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

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

  • ノードセレクター

  • 許容範囲

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

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

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

例、次のCluster 仕様の場合

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 構成は次のとおりです。

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 を使用する場合に特に関連します。

注釈

詳細については、

Kubernetes documentation を参照してください。

トポロジの考慮事項

クラウド環境では、ポッドがノードだけではなく異なるアベイラビリティーゾーンに分散されるように、 topology.kubernetes.io/zone をtopologyKey として使用することを検討できます。その他のオプションについては、 Well-Known Labels, Annotations, and Taints を参照してください。

アンチアフィニティポリシーの無効化

必要に応じて、enablePodAntiAffinity をfalse に設定することにより、オペレーター生成のアンチアフィニティポリシーを無効にできます。

カスタムルールを使用したきめの細かい制御

より正確な制御が必要なシナリオの場合、 additionalPodAffinity およびadditionalPodAntiAffinity 構成属性を使用して、カスタムポッドアフィニティまたはアンチアフィニティルールを指定できます。これらのカスタムルールは、オペレーターが有効になっている場合は生成されたルールに追加され、オペレーター生成ルールが無効になっている場合は直接使用されます。

注釈

additionalPodAntiAffinity または`additionalPodAffinity` を使用する場合、Pod仕様で想定されている完全な`podAntiAffinity` または`podAffinity` 構造を提供する必要があります。次のYAML例は、どのPostgreSQLクラスターに属しているかに関係なく、ワーカーノードごとにPostgreSQLのインスタンスを1つだけ構成する方法を示しています。

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構文を受け入れます。

注釈

taintとtolerationの詳細については、

Kubernetes documentation を参照してください。

PostgreSQLワークロードの分離

注釈

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

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

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

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

セクション。

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

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

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

# <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ワークロードの最適な分散と分離を保証し、運用環境のパフォーマンスと信頼性の向上につながります。