スケジューリング¶
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
です。これにより、ポッドがノードだけでなくアベイラビリティーゾーン全体に分散されるようになります。
。
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構文を受け入れます。