Kubernetes ワークロードとは、Kubernetes クラスターでアプリケーションまたはサービスを実行する Pod とコンテナーのセットです。Pod の安定性とサービスの継続性を確保するために、ワークロードのデプロイ、スケーリング、更新、復元などの操作を実行できます。このトピックでは、Deployment、StatefulSet、Job、CronJob など、さまざまな種類の Kubernetes ワークロードについて紹介します。
Pod
Pod は、Kubernetes のアプリケーションに対して作成または管理できる最小のデプロイ可能な単位です。1 つ以上のコンテナー、ストレージリソース、一意の IP アドレス、およびコンテナーの実行方法を指定する構成をカプセル化します。ほとんどの場合、Kubernetes ユーザーは Pod を直接作成しません。代わりに、Kubernetes では、Deployment や StatefulSet などのコントローラーを使用して Pod を管理できます。
Deployment と StatefulSet
Deployment
以前は、Kubernetes は ReplicaSet コントローラーを使用して、複製された Pod の数、ラベルセレクター、および Pod テンプレートを指定していました。現在、Kubernetes は Deployment コントローラーを使用して ReplicaSet コントローラーを管理しています。これにより、Kubernetes は Pod を間接的に管理および制御できます。
Deployment は、Web サーバーやマイクロサービスアーキテクチャを使用するアプリケーションなど、データの永続性とリクエストの順序に依存しないシナリオに適しています。
シナリオ | 説明 |
ステートレス Web サービス | 変動するリクエストを処理する必要があるフロントエンド Web サービス。Deployment は、Pod の水平スケーリング、更新、およびロールバックをサポートします。 |
マイクロサービスアーキテクチャを使用するアプリケーション | 複数のマイクロサービスで構成されるシステムは、各サービスを個別にデプロイします。各サービスは、独立したライフサイクルと独立したスケーリング要件を持っています。Deployment を使用して、各マイクロサービスを個別にデプロイできます。 |
StatefulSet
Deployment によって管理される Pod はステートレスであり、互いに独立しています。Deployment は、特定のシナリオの要件を満たすことができません。たとえば、A-S モードの分散データベース用に作成された Pod はステートフルであり、相互に依存しています。この場合、StatefulSet を使用して Pod を管理できます。
StatefulSet は、データベースや分散ストレージシステムなど、永続ストレージと順序付けられたデプロイメントが必要なシナリオに適しています。
シナリオ | 説明 |
ステートフルデータベース | ほとんどのステートフルデータベースは永続ストレージを必要とし、Pod の再スケジュール後も同じネットワーク識別子と Pod データを維持する必要があります。たとえば、MySQL データベース用に作成された各 Pod には、Pod の再起動後も変更されない特定のデータと構成があります。 |
分散メッセージキューサービス | 分散メッセージキューサービスでは、ノードステータスの整合性とログの永続性が必要です。たとえば、Apache Kafka では、ブローカーノード間で厳密なデータ整合性が必要です。さらに、データ損失を防ぐために、ログを永続ボリューム (PV) に永続化する必要があります。 |
Deployment と StatefulSet の違い
次の表は、Deployment と StatefulSet を比較して、Deployment と StatefulSet のどちらを選択するかを支援します。
項目 | Deployment | StatefulSet |
シナリオ | Web サーバーや API サービスなどのステートレスアプリケーション向け。Deployment は、迅速なスケーリングとローリングアップデートが必要なシナリオに適しています。 | データベースや分散ファイルシステムなどのステートフルアプリケーション向け。StatefulSet は、永続ストレージと順序付けられたデプロイメントが必要なシナリオに適しています。 |
永続ストレージ | すべての複製された Pod は、同じ永続ボリューム要求 (PVC) を共有します。Pod が再スケジュールまたは更新されると、データの整合性を確保するために、元の PVC が引き続き Pod にマウントされます。 | 各 Pod には個別の PVC がマウントされ、データの永続性を実現します。Pod は、データの整合性を確保するために、固定形式で名前が付けられます。Pod が再起動または再スケジュールされると、元の PVC が引き続き Pod にマウントされます。 |
ネットワーク識別子 | Pod には固定識別子はありません。Pod の名前と IP アドレスは、作成時に動的に生成されます。Pod の識別子、名前、および IP アドレスは、Pod が再作成されるたびに変わります。 | Pod の識別子は、 |
更新ポリシー |
|
|
サービスディスカバリ | さまざまなサービスの種類に基づいてサービスディスカバリを実装し、Pod のロードバランシングを実行します。詳細については、「サービス管理」をご参照ください。 | 各 Pod には、一意の固定ドメイン名があります。StatefulSet は、ヘッドレスサービスを使用してサービスディスカバリを実装し、各 Pod への直接アクセスを有効にできます。 |
DaemonSet
DaemonSet は、クラスター内の各ノードで複製された Pod が実行されるようにします。DaemonSet は、ログ収集サービス、リソース監視システム、ネットワークプラグインなど、すべてのノードで実行する必要があるバックグラウンドサービスまたは監視プロセスに適しています。クラスターにノードが追加または削除されると、DaemonSet はノードに Pod を自動的に作成するか、ノードから Pod を削除します。
DaemonSet は、Kubernetes クラスター内の各ノードで同じデーモンを実行するのに適しています。
シナリオ | 説明 |
ログ収集 | DaemonSet は、ログ収集コンポーネントなどのログ収集ツールのデプロイに適しています。各ノードのログファイルを収集、処理、および一元化されたログ管理システムに配信できるように、ログ収集ツールはクラスター内の各ノードで実行する必要があります。 |
監視エージェント | DaemonSet は、リソース使用量メトリックを収集する Node Exporter や Datadog Agent などの Prometheus 監視エージェントをデプロイするために使用されます。これにより、ノードの状態とパフォーマンスを監視できます。 |
Job と CronJob
Kubernetes では、Job はワンタイムタスクを実行するために使用され、CronJob はスケジュールされたタスクを実行するために使用されます。Job と CronJob は、バッチ処理タスクやデータ処理ジョブなど、オンデマンドで実行されるワークロードに適しています。
Job は、タスクを実行するために 1 つ以上の Pod を作成します。タスクが完了すると、Job によって作成された Pod は自動的に終了します。Job は、データ処理タスクやデータバックアップタスクなどのワンタイムタスクに適しています。
CronJob は、Cron 式で指定されたスケジュールに基づいて Job を作成します。Cron 式は、分、時、日、週、月の組み合わせをサポートしています。CronJob は、スケジュールされたデータベースバックアップタスクやスケジュールされたログ削除タスクなどの定期的なタスクに適しています。
ワークロードの管理
ACK クラスターのワークロードは、API オペレーションの呼び出し、kubectl コマンドライン ツールの使用、または ACK コンソールの使用によって管理できます。これらのメソッドを使用して、アプリケーションを効率的にデプロイ、監視、およびスケーリングできます。
ACK コンソールの使用
ACK コンソールを使用すると、効率的、便利、かつ視覚化された方法でワークロードを作成、管理、および監視できます。次のトピックでは、ACK コンソールでさまざまな種類のワークロードを管理する方法について説明します。
詳細については、「Pod の管理」をご参照ください。
詳細については、「Deployment を使用してステートレスアプリケーションを作成する」をご参照ください。
詳細については、「StatefulSet を使用してステートフルアプリケーションを作成する」をご参照ください。
詳細については、「DaemonSet を作成する」をご参照ください。
詳細については、「Job を作成する」をご参照ください。
詳細については、「CronJob を作成する」をご参照ください。
kubectl の使用
クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続できます。詳細については、「クラスターの kubeconfig ファイルを取得して kubectl を使用してクラスターに接続する」をご参照ください。その後、ビジネス要件に基づいてクラスターを管理できます。たとえば、アプリケーションのデプロイ、リソースの管理、クラスターの監視を行うことができます。
API
API 操作を呼び出すことで、ワークロードを作成、更新、削除、および監視できます。詳細については、「Kubernetes API の使用」をご参照ください。
よくある質問
ワークロードの使用中に問題が発生した場合は、解決策について「ワークロードに関するよくある質問」をご参照ください。
詳細については、「Pod のトラブルシューティング」をご参照ください。
詳細については、「Pod のトラブルシューティング」をご参照ください。
詳細については、「イメージのプルに時間がかかる場合、またはイメージのプルが失敗した場合はどうすればよいですか。」をご参照ください。
詳細については、「非公開イメージをプルするにはどうすればよいですか。」をご参照ください。
参考資料
推奨されるワークロード構成の詳細については、「推奨されるワークロード構成」をご参照ください。
Pod の Auto Scaling を有効にする方法の詳細については、「Auto Scaling の概要」をご参照ください。
Pod のスケジューリングポリシーの詳細については、「スケジューリング」をご参照ください。
アプリケーションへのアクセス、サービスディスカバリの実装、およびロードバランシングの実装の詳細については、「サービス管理」をご参照ください。
クラスター内のサービスへの外部トラフィックを管理する方法の詳細については、「Ingress 管理」をご参照ください。
Pod の永続ストレージを有効にする方法の詳細については、「ストレージの基本」をご参照ください。
Secret を使用せずに ACK クラスターにイメージをプルする方法の詳細については、「Secret を使用せずにイメージをプルする」をご参照ください。
中国本土以外の地域にあるクロスリージョンコンテナイメージをプルする方法の詳細については、「GA インスタンスを使用してコンテナイメージのクロスリージョン高速プルを行う」をご参照ください。