Workload API

• 1: PodグループのDisruptionと優先度
• 2: Podグループポリシー

apiVersion: scheduling.k8s.io/v1alpha1
kind: Workload
metadata:
  name: training-job-workload
  namespace: some-ns
spec:
  controllerRef:
    apiGroup: batch
    kind: Job
    name: training-job
  podGroups:
  - name: workers
    policy:
      gang:
        # gangは4つのPodが同時に実行できる場合にのみスケジュール可能
        minCount: 4

1 - PodグループのDisruptionと優先度

PodGroupはDisruptionモードを宣言できます。 このモードは、より優先度の高いPodGroupを配置する場合などに、スケジューラーが実行中のPodGroupをどのようにDisruptionできるかを定めます。 また、PodGroupには優先度があり、ワークロードを考慮したプリエンプションの際には、グループ内の各Podの優先度を上書きして適用されます。

Disruptionモードの種類

APIはSingleとAllの2つのDisruptionモードをサポートしています。 デフォルトはSingleです。

Single

Singleモードは、グループ内のすべてのPodを独立したエンティティとして扱うようスケジューラーに指示し、PodGroup内の単一のPodを個別にDisruptionできるようにします。

All

Allモードでは、Disruptionを「全か無か」として扱います。 PodGroup内のすべてのPodをまとめてDisruptionするよう、スケジューラーに指示します。

CompositePodGroup

CompositePodGroupも、その仕様内でdisruptionModeを宣言できます。 これは、プリエンプションイベント中にスケジューラーがCompositePodGroup内の子グループをどのようにDisruptionするかを制御します。

APIはCompositePodGroupに対して2つのDisruptionモードをサポートしています:

• Single: CompositePodGroup内の個々の子グループを、プリエンプション中に個別にDisruptionできます。
• All: CompositePodGroup階層全体で「全か無か」のDisruptionセマンティクスを強制します。 このCompositePodGroup配下の階層に含まれるいずれかのPodをプリエンプトする必要がある場合、階層全体のすべてのPodをプリエンプトする必要があります。

指定しない場合、モードはデフォルトでSingleになります。

Podグループの優先度

PodGroupは、単一のPodと同じPriorityClassの概念を使用します。 1つ以上のPriorityClassを作成すると、その仕様内でいずれかのPriorityClass名を指定したPodGroupを作成できます。 優先度アドミッションコントローラーはpriorityClassNameフィールドを使用し、優先度の整数値を設定します。 優先度クラスが見つからない場合、PodGroupは拒否されます。 PodGroupにpriorityClassNameが設定されていない場合、KubernetesはデフォルトのPriorityClass(globalDefaultがtrueに設定されたPriorityClass)を探します。 globalDefaultがtrueに設定されたPriorityClassがない場合、priorityClassNameが指定されていないPodGroupの優先度は0になります。

個々のPodの優先度が異なる場合でも、ワークロードを考慮したプリエンプションの際には、PodGroupの優先度がグループ内のすべてのPodに対して決定的な優先度になります。 この値は、スケジューリングキュー内のPodGroupの順序付けにも使用されます。 PodGroupを構成する個々のPodの優先度がPodGroupの優先度と異なる場合、PodGroupはall pods in a single pod group should have the same priority as the pod groupというエラーによりスケジュールされません。

PodGroupPreemptionPolicyフィーチャーゲートが有効な場合、PodGroupにはpreemptionPolicyフィールドもあります。 このフィールドもPriorityClassから取得されます。 これはグループ内のすべてのPodに対する権限のあるフィールドであり、PodGroupが自身を配置する場所を確保するために、より低い優先度のPodおよびPodグループをプリエンプトできるかを決定します。 フィーチャーゲートが有効な場合、PodGroup内のすべてのPodはPodGroupと同じpreemptionPolicyを持つ必要があります。 そうでない場合、PodGroupはall pods in a single pod group should have the same preemption policy as the pod group's preemption policyというエラーによりスケジュールされません。 PodGroupがpreemptionPolicy: Neverの場合、ワークロードを考慮したプリエンプションは実行されません。 フィーチャーゲートが無効な場合、PodGroupを構成するすべてのPodは同じpreemptionPolicyを持つ必要があります。 そうでない場合、PodGroupはall pods in a single pod group should have the same preemption policyというエラーによりスケジュールされません。

以下のYAMLは、整数の優先度値1000000に対応するhigh-priority PriorityClassを使用するPodGroup設定の例です。 優先度アドミッションコントローラーは仕様を確認し、PodGroupの優先度を1000000に設定します。

apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  namespace: ns-1
  name: job-1
spec:
  priorityClassName: high-priority

CompositePodGroupの優先度

CompositePodGroup APIにもpriorityClassNameとpriorityフィールドがあり、優先度アドミッションコントローラーによりPodGroupと同じ方法で解決されます。

ルートのCompositePodGroupの優先度は、ワークロードを考慮したプリエンプションイベント中に、その階層内のすべての子グループとPodに対する決定的な優先度として機能します。 単一のグループ階層内のすべてのPodは完全に同じ優先度を共有し、ルートのCompositePodGroupの優先度と等しくなければいけません。

優先度の値は、スケジューリングのアクティブキュー内にあるルートのCompositePodGroupの順序付けにも使用されます。

CompositePodGroupのPreemptionPolicy

CompositePodGroup APIにもpreemptionPolicyフィールドがあり、PodGroup APIとまったく同じ方法で解決されます。

ルートのCompositePodGroupのpreemptionPolicyの値により、必要に応じてスケジューリング中にそのPodを配置するためにワークロードを考慮したプリエンプションを実行できるかどうかが決まります:

• PreemptLowerPriorityポリシーは、より低い優先度の犠牲対象をプリエンプトできます。
• Neverポリシーは、そのルートのCompositePodGroupに対するワークロードを考慮したプリエンプションを無効にします。

単一のグループ階層内のすべてのPodは、ルートのCompositePodGroupのプリエンプションポリシーと等しい、完全に同じプリエンプションポリシーを共有しなければなりません。

フィーチャーゲートが無効な場合、グループ階層に属するいずれかのPodのpreemptionPolicyがNeverに設定されていない限り、ルートのCompositePodGroupはプリエンプションを実行できます。

次の項目

• ワークロードを考慮したプリエンプションについて読む。
• Workload APIについて学ぶ。
• Disruptionモードのビルディングブロックを含む、スケジューリングのビルディングブロックとworkloadbuilderライブラリについて学ぶ。

2 - Podグループポリシー

Workloadで定義される各Podグループは、スケジューリングポリシーを宣言する必要があります。 このポリシーは、スケジューラーがPodのグループをどのように扱うかを指定します。

ポリシータイプ

現在、APIはbasicとgangの2つのポリシータイプをサポートしています。 各グループに対して、いずれか1つのポリシーを指定する必要があります。

basicポリシー

basicポリシーは、グループ内のすべてのPodを独立したエンティティとして扱い、標準的なKubernetesの動作でスケジューリングするようスケジューラーに指示します。

basicポリシーを使用する主な理由は、Workload内のPodを整理して、可観測性と管理性を向上させることです。 このポリシーは、同時起動を必要としないが、論理的に同じアプリケーションに属するWorkloadのグループに使用できます。 また、将来的に「全か無か」の配置を意味しないグループ制約を追加する余地も残されています。

policy:
  basic: {}

gangポリシー

gangポリシーは、「全か無か」のスケジューリングを強制します。 これは、一部のPodだけが起動すると、デッドロックやリソースの浪費が発生する密結合したワークロードには必須です。

これは、すべてのワーカーが同時に実行されなければ処理が進まないJobや、その他のバッチ処理に使用できます。

gangポリシーにはminCountパラメーターが必要です:

policy:
  gang:
    # グループが受け入れられるために、
    # 同時にスケジュール可能である必要があるPodの数
    minCount: 4

次の項目

• gangスケジューリングアルゴリズムについて読む。