Kubernetesワークロードの基礎と実践:6つの種類からベストプラクティスまで

Kubernetesワークロードとは

Kubernetesワークロードとは、Kubernetesクラスター上で実行されるアプリケーション、サービス、タスクのことです。ワークロードはPod内で実行されますが、通常は、Podの作成・置き換え・スケーリング・更新・終了の方法をKubernetesに指示する上位のワークロードリソースを通じて管理されます。ワークロードリソースごとにライフサイクルの挙動が異なるため、Kubernetesはステートレスなサービス、ステートフルなアプリケーション、ノードレベルのエージェント、単発のバッチ処理、スケジュール実行タスクなどに対応できます。

コアとなる組み込みワークロードリソース:

ワークロードのベストプラクティス:

• 正確なリソースrequestsとlimitsを定義する: スケジューリングのために現実的なCPU・メモリのrequestsを設定し、不要なスロットリングやOOMKilledイベントを引き起こすことなく過剰な消費を防ぐため、limitsは慎重に使用します。
• ワークロードを継続的にライトサイジングする: 過去のCPU・メモリ使用量を設定済みのrequestsおよびlimitsと比較し、アプリケーションの需要の変化に応じて調整します。
• 適切なワークロードコントローラーを使用する: ステートレスなサービスにはDeployment、安定したIDやストレージが必要なワークロードにはStatefulSet、ノードレベルのサービスにはDaemonSet、有限のタスクにはJob、スケジュール実行にはCronJobを使用します。
• readiness・liveness・startupプローブを設定する: プローブを使ってトラフィック受信の可否を制御し、回復不能なアプリケーション障害を検出し、起動の遅いワークロードを早すぎる再起動から保護します。
• 重要なアプリケーションにはPod Disruption Budgetを使用する: ノードのdrainやメンテナンスなどの自発的な中断時に、利用不可となるレプリカ数を制限します。
• レプリカをノードとアベイラビリティゾーンに分散する: Podのanti-affinityやtopology spread constraintsを使用して、ノードやゾーンの障害の影響を軽減します。
• ワークロードとクラスターのオートスケーリングを組み合わせる: HPAなどのワークロードオートスケーリングとノードオートスケーリングを連携させ、追加されたレプリカを実行するのに十分なクラスター容量を確保します。

本記事は、Kubernetesスケジューリングに関する連載記事の一部です。

本記事の内容:

• KubernetesワークロードとWorkload APIの違い
• Kubernetesワークロードの種類
• KubernetesにおけるAI・機械学習ワークロード
• Kubernetesワークロードのライフサイクル
• Kubernetesワークロードの監視
• Kubernetesワークロード管理のベストプラクティス

KubernetesワークロードとWorkload APIの違い

Kubernetesワークロードとは、クラスター内で実行されるアプリケーションやタスクを表し、管理するリソースそのものです。Deployment、StatefulSet、DaemonSet、Job、CronJobなどが該当します。これらのオブジェクトは、実行するコンテナイメージ、レプリカ数、更新戦略、スケジューリング要件など、ワークロードの望ましい状態を記述します。

ワークロードAPIとは、これらのワークロードオブジェクトの作成、読み取り、更新、削除、スケーリングなどの管理に使用されるKubernetes APIインターフェースです。たとえば、Deploymentはワークロードオブジェクトであり、Kubernetesのapps/v1 APIグループを通じて公開されるDeployment APIは、kubectlなどのツール、コントローラー、アプリケーションコードがDeploymentリソースを操作するために使用する操作とスキーマを提供します。

つまり、この違いは管理対象のリソースとそれを管理するためのAPIの違いです。StatefulSetはワークロードであり、StatefulSet APIはクライアントがStatefulSetオブジェクトを作成・変更できるようにします。同様に、Jobはワークロードであり、Job APIはJobリソースへのプログラムによるアクセスを提供します。

この区別は、オペレーター、自動化、プラットフォームツール、カスタム統合を構築する際に特に重要になります。これらのシステムは、稼働中のコンテナやPodを直接操作するのではなく、ワークロードAPIを通じてKubernetesとやり取りすることで、Kubernetesコントロールプレーンが要求されたワークロードの状態を調整できるようにします。

Kubernetesワークロードの種類

Kubernetesは、さまざまなアプリケーション要件に対応する複数のワークロードリソースを提供しています。各リソースはPodを管理しますが、スケジューリング、スケーリング、更新、Podの置き換えに関するルールはそれぞれ異なります。適切なリソースの選択は、アプリケーションがステートレスか、ステートフルか、ノード固有か、あるいは有限時間の実行を想定しているかによって決まります。

Deployment

Deploymentは、1つ以上の交換可能なPodレプリカを必要とするステートレスアプリケーションを管理します。望ましいコンテナイメージ、レプリカ数、Pod構成を定義すると、Deploymentはその状態を継続的に維持するよう動作します。

Deploymentは制御されたアプリケーション更新もサポートします。ローリングアップデート中に古いPodを新しいPodへ段階的に置き換え、更新が失敗した場合には以前のリビジョンへのロールバックをサポートします。DeploymentはPodを直接作成するのではなく、ReplicaSetを通じて管理します。

例:

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 3

StatefulSet

StatefulSetは、Podに安定したID、予測可能な順序、永続ストレージが必要なアプリケーションを管理します。DeploymentのPodとは異なり、StatefulSetのPodにはdatabase-0、database-1のような永続的な名前が付与されます。

StatefulSetは、定義された順序でPodを作成・終了し、各Podに専用の永続ボリュームクレームを関連付けることができます。これらの特性により、データベース、分散データストアなど、個々のレプリカが交換可能でないアプリケーションに適しています。

例:

apiVersion: apps/v1
kind: StatefulSet
spec:
  serviceName: database
  replicas: 2

DaemonSet

DaemonSetは、対象となるすべてのノード、または選択したノードグループ上でPodが稼働することを保証します。条件に合致するノードがクラスターに参加すると、Kubernetesはそのノード上にPodを作成します。ノードが削除されると、そのDaemonSetのPodも一緒に消えます。

DaemonSetは、ログコレクター、監視エージェント、ストレージコンポーネント、ネットワークソフトウェアなど、ノードレベルのサービスに広く使用されます。ノードセレクター、affinityルール、tolerationsにより、Podを配置するノードを制限できます。

例:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-agent

Job

Jobは、指定されたタスクが正常に完了するまで1つ以上のPodを実行します。アプリケーションを継続的に稼働させるDeploymentとは異なり、Jobは成功完了数を追跡し、完了要件を満たすとPodの作成を停止します。

Jobは、データベースマイグレーション、データ処理、バッチ計算、管理操作などの有限タスクに役立ちます。単一のタスクを実行することも、複数のタスクを逐次または並列に実行することもできます。

例:

apiVersion: batch/v1
kind: Job
metadata:
  name: migration

CronJob

CronJobは、cron構文で表現された定期スケジュールに従ってJobを作成します。Kubernetesはスケジュールを評価し、設定された実行時刻になるとJobを開始します。

CronJobは、バックアップ、レポート生成、クリーンアップ操作、定期的なデータ同期などの繰り返しタスクに適しています。設定により、同時実行、実行漏れ、完了済みJobの保持も制御できます。

例:

apiVersion: batch/v1
kind: CronJob
spec:
  schedule: "0 2 * * *"

ReplicaSet

ReplicaSetは、指定された数の同一Podレプリカを維持します。Podが障害を起こしたり削除されたりすると、ReplicaSetは代替を作成します。条件に合致するPodが多すぎる場合は、余分なPodを削除します。

ReplicaSetは通常、Deploymentを通じて間接的に管理されます。DeploymentはPodテンプレートが変更されると新しいReplicaSetを作成し、それを利用してローリングアップデートやロールバックを実行します。Deploymentが必要なライフサイクル管理を提供する場合、ReplicaSetを直接作成する必要は一般的にありません。

例:

apiVersion: apps/v1
kind: ReplicaSet
spec:
  replicas: 3

KubernetesにおけるAI・機械学習ワークロード

Kubernetesは、モデルトレーニング、分散トレーニング、バッチ処理、推論といったAI・機械学習ワークロードを実行できます。これらのワークロードもPod内で実行されますが、特にアクセラレーター、リソースの可用性、複数Podの連携といった点で、従来のアプリケーションよりも要件が厳しい場合が多くあります。

GPUとアクセラレーターの要件

AI/MLワークロードは、多くの場合GPUなどの特殊なハードウェアに依存します。Kubernetesは、AMDやNVIDIAのGPUなどのハードウェアをスケジュール可能なリソースとして公開するデバイスプラグインをサポートしています。

これにより、チームは次のことが可能になります。

• 特定のPodに対してGPUをリクエストする。
• 適切なアクセラレーターハードウェアを備えたノードにのみワークロードをスケジュールする。
• ノードラベル、セレクター、affinityを使用して特定のGPUタイプを指定する。
• CPUやメモリなど他のKubernetesリソースと合わせてGPU容量を管理する。

分散AI・MLワークロード

大規模なトレーニングジョブは、ドライバーと複数のワーカーなど、関連する複数のPodで構成されることがあります。十分な数のワーカーが同時に利用可能でない限りワークロードが進行できないため、これらのPodを個別にスケジュールすると非効率になる可能性があります。

Kubernetes Workload APIは、関連するPodをグループ化してスケジューリングポリシーを割り当てられるようにすることで、この種の要件に対応します。たとえば、ギャングスケジューリングでは、分散ジョブの一部だけがリソースを消費することを許さず、必要なPodグループを一括でスケジュールするオール・オア・ナッシング方式を採用できます。

AI/MLのためのワークロード配置

配置はAI/MLのパフォーマンスにも影響します。分散トレーニングではワーカー間の通信が多く発生するため、Kubernetesはワークロードやトポロジーを考慮したスケジューリングを使用して、関連するPodの実行場所を調整できます。

これらの機能は、組織が次のことを行うのに役立ちます。

• 分散ワーカーを適切なトポロジードメイン内に維持する。
• 関連するPod間の通信レイテンシーを削減する。
• 一部のPodしかスケジュールされず処理を進められないトレーニングジョブを回避する。
• 希少なGPUやアクセラレーターリソースをより効率的に割り当てる。

Kubernetesワークロードのライフサイクル

Kubernetesワークロードは、最初の宣言からスケジューリング、実行、スケーリング、更新、最終的な終了まで、複数のステージを経て進行します。最新のKubernetes環境では、アプリケーションレベルのスケーリングと基盤となるノードの動的プロビジョニングの両方を含め、このライフサイクルの多くを自動化できます。

1. ワークロードの定義と作成

ライフサイクルは、Deployment、StatefulSet、DaemonSet、Job、CronJobなどのワークロードリソースを定義することから始まります。マニフェストには、コンテナイメージ、レプリカ数、リソースのrequestsとlimits、環境設定、ストレージ要件、スケジューリング制約など、アプリケーションの望ましい状態を指定します。

リソースがKubernetes APIに送信されると、該当するコントローラーがクラスターの実際の状態と望ましい状態の調整を開始します。たとえば、DeploymentコントローラーはReplicaSetを作成・管理し、ReplicaSetが必要なPodを維持します。

2. Podのスケジューリング

新しく作成されたPodは、通常、ノードが割り当てられていない状態から始まります。Kubernetesスケジューラーは利用可能なノードを評価し、次のような要素に基づいて適切な配置先を選択します。

• CPUとメモリのrequests
• ノードセレクターとnode affinity
• Podのaffinityとanti-affinity
• Taintsとtolerations
• Topology spread constraints
• ストレージとハードウェアの要件

Kubernetesはスケジューリングゲートもサポートしており、外部条件が満たされるまでPodをスケジューラーの対象外にしておくことができます。適切なノードが選択されると、Podはそのノードにバインドされます。

3. 容量不足時のノードプロビジョニング

適切な容量がないためにスケジューラーがPodを配置できない場合、ノードオートスケーリングによって追加のインフラをプロビジョニングできます。

最新のKubernetesでは、これをワークロードオートスケーリングとは区別しています。ノードオートスケーラーはスケジュール不能なPodに反応し、そのリソース要件とスケジューリング要件を満たすノードをプロビジョニングします。Kubernetesは現在、Cluster AutoscalerとKarpenterの両方をSIG Autoscalingが支援する実装として位置付けています。

Karpenterは、このプロセスに対してより動的なアプローチを採用しています。事前定義されたノードグループだけに依存するのではなく、NodePoolの制約と保留中のPodの要件に基づいて、適切なノード容量を選択・プロビジョニングできます。また、ノードの統合や置き換えを含む、より広範なノードライフサイクル操作も管理します。

4. Podの起動と準備完了

Podが割り当てられたノードに到達すると、kubeletがPodを準備してコンテナを起動します。アプリケーションは、トラフィックを処理できるようになるまでに初期化時間を必要とする場合があります。

Kubernetesはこのステージを管理するために複数のプローブを提供しています。

• Startupプローブ:アプリケーションが正常に初期化されたタイミングを判定します。
• Readinessプローブ:Podがトラフィックを受信すべきタイミングを判定します。
• Livenessプローブ:稼働しているものの正常でなく、再起動が必要なコンテナを検出します。

したがって、Podは実行中であっても、まだリクエストを処理する準備ができていないと見なされる場合があります。

5. 実行時の運用とヘルス管理

準備が整うと、Podはアプリケーションの処理を実行し、Kubernetesは宣言された状態を維持するために継続的に動作します。

コンテナに障害が発生した場合、kubeletは再起動ポリシーに従ってコンテナを再起動できます。DeploymentやStatefulSetが管理するPodが完全に消失した場合は、ワークロードコントローラーが代替を作成できます。Readinessチェックは、必ずしも再起動することなく、異常なPodをサービスエンドポイントから一時的に除外することもできます。

6. ワークロードのオートスケーリング

運用中、Kubernetesは需要の変化に応じてワークロードの容量を調整できます。現在のKubernetesは、単一のスケーリングメカニズムに依存するのではなく、複数のアプローチをサポートしています。

• Horizontal Pod Autoscaler(HPA): CPU、メモリ、カスタムメトリクス、外部メトリクスに基づいてレプリカ数を変更します。
• Vertical Pod Autoscaler(VPA): ワークロードの要件に基づいてリソースのrequestsとlimitsを調整します。VPAはKubernetesのコアAPIの一部ではなく、別途インストールします。
• インプレースでの垂直リサイズ: Kubernetesは、必ずしもPodを置き換えることなく、コンテナに割り当てられたCPUとメモリリソースをリサイズできます。Podのインプレース垂直スケーリングはKubernetes 1.35で安定版となりました。
• KEDA: キュー、ストリーミングシステム、データベース、監視プラットフォームなどのソースに基づく、イベント駆動型のオートスケーリングを追加します。

KEDAは、CPUやメモリの使用率ではなくアプリケーションイベントに応じてスケーリングすべき場合に特に有用です。Deployment、StatefulSet、その他のスケーラブルなリソースをスケールでき、HPAでさらにスケールする前に、ワークロードをゼロと1レプリカの間でスケールすることも可能です。また、KEDAはScaledJobを通じてKubernetes Jobの作成とスケーリングも行えます。

7. ノードのスケーリングと統合

ワークロードのレプリカが増えても、既存のノードにそれらを実行する十分な余裕があるとは限りません。そのため、ワークロードオートスケーリングとノードオートスケーリングは連携して動作することがよくあります。

例:

• HPAまたはKEDAが需要に応じてPod数を増やす。
• クラスターの容量不足により、一部の新しいPodがスケジュール不能になる。
• ノードオートスケーラーが追加ノードをプロビジョニングする。
• スケジューラーが保留中のPodを新たに利用可能になった容量に配置する。

このプロセスは逆方向にも機能します。需要が減少すると、ワークロードオートスケーリングが不要なPodを削除し、ノードオートスケーリングが十分に活用されていないインフラを統合できます。

Karpenterの統合機能では、空または低稼働のノードを削除・置き換えることができ、単に固定のノードグループを維持するのではなく、クラスターのインフラをワークロードに適応させるのに役立ちます。

8. ワークロードの更新とロールアウト

チームが新しいコンテナイメージ、設定、リソース設定、アプリケーションバージョンをデプロイするのに伴い、ワークロードはそのライフサイクルの中で頻繁に変化します。

Deploymentの場合、Kubernetesは通常ローリングアップデートを実行し、新しい仕様に基づくPodを段階的に作成しながら、古いPodを終了します。これにより、新バージョンの導入中もアプリケーションの可用性を維持できます。ロールアウトの挙動は、maxSurgeやmaxUnavailableなどの設定で制御できます。

コントローラーは、稼働中のPodが更新後の望ましい状態と一致するまで、ワークロードの調整を続けます。

9. スケールダウンと終了

Podは、手動削除、ワークロードのスケールダウン、ローリングアップデート、ノードの中断、ノードの統合などにより終了することがあります。

通常の終了時、Kubernetesはアプリケーションに正常にシャットダウンする機会を与えます。Podは通常のサービストラフィックから除外され、コンテナは終了シグナルを受信し、Kubernetesは設定された終了猶予期間が経過するまで待ってから、残っているプロセスを強制停止します。

ワークロードの需要が低下すると、オートスケーラーはレプリカ数を削減でき、Karpenterなどのノードオートスケーラーは、不要になった容量をその後統合または削除できます。