スケジューリング

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

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

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

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

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

  • ノードセレクター

  • 寛容

注釈

CloudNativePGは、ワークロードのスケジューリングをより細かく制御するためのポッドテンプレートをサポートしていません。それらは最初のコンセプトの一部でしたが、開発チームはAPIの新しいバージョン(おそらくCNPGのv2)での導入を延期することを決定しました。

Podアフィニティとアンチアフィニティ

Kubernetesを使用すると、それらのノードですでに実行されている実際のワークロードに基づいて、ポッドをスケジュールする( アフィニティ)またはスケジュールしない(アンチアフィニティ)ノードを制御できます。これは、技術的に** ポッド間アフィニティ/アンチアフィニティ**として知られています。

CloudNativePGはデフォルトで、クラスターのインスタンスをできれば異なるノードで構成し、次のaffinity 定義になります。

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - podAffinityTerm:
          labelSelector:
            matchExpressions:
              - key: postgresql
                operator: In
                values:
                  - cluster-example
          topologyKey: kubernetes.io/hostname
        weight: 100

次のクラスター仕様の結果:

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

  affinity:
    enablePodAntiAffinity: true #default value
    topologyKey: kubernetes.io/hostname #defaul value
    podAntiAffinityType: preferred #default value

  storage:
    size: 1Gi

したがって、Kubernetesは3つの異なるノード上で3ノードのPostgreSQLクラスターをスケジュールすることを 優先 します-リソースが許す限り。

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

podAntiAffinityType をrequired に設定できます。preferredDuringSchedulingIgnoredDuringExecution の代わりにrequiredDuringSchedulingIgnoredDuringExecution が使用されます。このような強い要件により、リソースが利用できない場合に保留中のインスタンスが発生する可能性があることに注意してください(これは、Kubernetesクラスターの自動水平スケーリングに

Cluster Autoscaler を使用する場合に予想される条件です) 。

クラウド環境でのtopologyKey の別の可能な値はtopology.kubernetes.io/zone です。これにより、ポッドがノードだけでなくアベイラビリティーゾーン全体に分散されるようになります。

Well-Known Labels, Annotations and Taints を参照してください

。

enablePodAntiAffinity をfalseに設定することで、オペレーターが生成した非アフィニティーポリシーを無効にできます。

さらに、よりきめ細かな制御が必要な場合は、 additionalPodAffinity およびadditionalPodAntiAffinity 構成属性を介して、カスタムポッドアフィニティまたはアンチアフィニティルールのリストを指定できます。これらのルールは、有効になっている場合はオペレーターによって生成されたルールに追加され、それ以外の場合は透過的に渡されます。

注釈

additionalPodAntiAffinity または`additionalPodAffinity` にPod仕様で予想される`podAntiAffinity` または`podAffinity` のコンテンツ全体を渡す必要があります(どのPostgreSQLに関係なく、すべてのワーカーノードでPostgreSQLのインスタンスを1つだけ実行する例として、次の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構文を受け入れます。