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

Workload API

1: Podグループポリシー

Feature state: Kubernetes v1.35 (Alpha; disabled by default)

More information about this feature

To use this feature, you (or a cluster administrator) will need to enable the GenericWorkload feature gate for all relevant components in your cluster.

See Enable Or Disable Feature Gates for more information.

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 - Podグループポリシー

Feature state: Kubernetes v1.35 (Alpha; disabled by default)

More information about this feature

To use this feature, you (or a cluster administrator) will need to enable the GenericWorkload feature gate for all relevant components in your cluster.

See Enable Or Disable Feature Gates for more information.

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