これは、このセクションの複数ページの印刷可能なビューです。印刷するには、ここをクリックしてください.

Workload API

1: PodGroupの中断と優先度
2: Podグループポリシー

FEATURE STATE: Kubernetes v1.35 [alpha](デフォルトで無効)

Workload APIリソースを使用すると、複数のPodで構成されるアプリケーションについて、スケジューリング要件とPodのグループ構成を記述できます。ワークロードコントローラーはワークロードのランタイム動作を提供しますが、Workload APIはJobなどの「真の」ワークロードに対して、スケジューリング制約を提供することを目的としています。

Workloadとは

Workload APIリソースは、scheduling.k8s.io/v1alpha1 APIグループの一部です(このAPIを利用するには、クラスターで、そのAPIグループとGenericWorkloadフィーチャーゲートの両方を有効にする必要があります)。このリソースは、複数のPodで構成されるアプリケーションのスケジューリング要件を、構造化された機械可読な形式で定義します。 Jobのようなユーザー向けのワークロードは何を実行するかを定義します。一方で、Workloadリソースは、Podのグループをどのようにスケジュールし、ライフサイクル全体を通じてその配置をどう管理するかを決定します。

APIの構造

Workloadを使用すると、Podのグループを定義し、それらにスケジューリングポリシーを適用できます。これは、Podグループのリストとコントローラーへの参照という2つのセクションで構成されます。

Podグループ

podGroupsリストは、ワークロードの個別のコンポーネントを定義します。たとえば、機械学習ジョブにはdriverグループとworkerグループがある場合があります。

podGroupsの各エントリには以下が必要です:

PodのWorkload参照で使用できる一意のname
スケジューリングポリシー(basicまたはgang)

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

ワークロード管理オブジェクトの参照

controllerRefフィールドは、WorkloadをJobやカスタムCRDなど、アプリケーションを定義する上位のオブジェクトに紐づけます。これは可観測性とツールの利用に役立ちます。このデータは、Workloadのスケジューリングや管理には使用されません。

次の項目

PodでWorkloadを参照する方法を確認する。
Podグループポリシーについて学ぶ。
gangスケジューリングアルゴリズムについて読む。

1 - PodGroupの中断と優先度

FEATURE STATE: Kubernetes v1.36 [alpha](デフォルトで無効)

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

中断モードの種類

備考:

v1.36以降、PodGroupのpriorityまたはdisruptionModeフィールドは、ワークロードアウェア・プリエンプションでのみ考慮されます。Podのスケジューリングフェーズでは、スケジューラーはPodGroupのpriorityやdisruptionModeフィールドを考慮しません。

APIはPodとPodGroupの2つの中断モードをサポートしています。デフォルトはPodです。

Pod

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

PodGroup

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

PodGroupの優先度

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

個々のPodの優先度が異なる場合でも、ワークロードアウェア・プリエンプションの際には、PodGroupの優先度がグループ内のすべてのPodの優先度として扱われます。

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

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

次の項目

ワークロードアウェア・プリエンプションアルゴリズムについて読む。
Workload APIについて学ぶ。

2 - Podグループポリシー

FEATURE STATE: Kubernetes v1.35 [alpha](デフォルトで無効)

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スケジューリングアルゴリズムについて読む。