ワークロードのデプロイ

クラスタのライフサイクル ガイドで説明されているように、GKE ユーザーは通常、クラスタ管理には Google Cloud ツールを使用し、アプリケーションのデプロイなどのクラスタ内部タスクには kubectl などの Kubernetes ツールを使用します。つまり、別の Kubernetes 実装にワークロードをデプロイすることに慣れている場合、GKE にワークロードをデプロイする際にも、多くのワークフローが同じになります（Kubernetes でのワークロードのデプロイに慣れていない場合は、デプロイと Kubernetes の学習を開始するで他のリソースを確認してください）。

また、GKE には、オブザーバビリティ ツール、ステートフル アプリケーション用のフルマネージド データベース オプション、AI / ML ワークロードなどの特殊なワークロード タイプの特定のハードウェア オプションなど、ワークロードのデプロイと管理のための追加機能も用意されています。

このページでは、GKE クラスタにワークロードをデプロイするデベロッパーと管理者向けの概要と、詳細なドキュメントへのリンクを示します。その他のガイドやチュートリアルについては、GKE コア ドキュメントでデプロイに関するセクションをご覧ください。

このページを読む前に、次のことを理解しておく必要があります。

必要なロール

プロジェクト オーナーでない場合は、ワークロードをデプロイするには、少なくとも次の Identity and Access Management（IAM）ロールが必要です。

  • Kubernetes Engine クラスタ閲覧者（roles/container.clusterViewer）: これにより、container.clusters.get 権限が付与されます。この権限は、Google Cloud プロジェクト内のクラスタの認証に必要です。これにより、これらのクラスタ内でアクションを実行する権限が付与されるわけではありません。クラスタ管理者は、IAM または Kubernetes RBAC を使用して、クラスタで他のアクションを実行する権限を付与できます。

    このロールに含まれる権限の詳細と、読み取り / 書き込み権限を持つロールの付与方法については、IAM のドキュメントで Kubernetes Engine ロールの説明をご覧ください。

GKE でのアクセス制御の仕組みについては、アクセス制御をご覧ください。

ステートレス アプリケーション

ステートレス アプリケーションとは、データやアプリケーションの状態をクラスタや永続ストレージに保存しないアプリケーションです。ステートレス アプリケーションは、Google Cloud コンソールの [ワークロード] メニューから直接デプロイできます。また、Kubernetes API を使用してデプロイすることもできます。GKE にステートレス Linux アプリケーションをデプロイする方法については、ステートレス Linux アプリケーションのデプロイをご覧ください。必要に応じて、ステートレスな Windows Server アプリケーションをデプロイする方法も学習できます。

ステートフル アプリケーションとストレージ

Pod の存続期間を超えて存在するデータを保存する必要があるアプリケーションは、ステートフル アプリケーションと呼ばれます。管理者は、Kubernetes の PersistentVolume オブジェクトを使用して、このストレージをプロビジョニングできます。GKE では、PersistentVolume ストレージは Compute Engine ディスクによってバックアップされます。GKE にシンプルなステートフル アプリケーションをデプロイする方法については、ステートフル アプリケーションのデプロイをご覧ください。

ステートフル アプリケーションのデータを、クラスタの存続期間に関連付けられたストレージではなくデータベースに保持する必要がある場合、GKE には次のオプションがあります。

  • フルマネージド データベース: Cloud SQL や Spanner などのマネージド データベースは、運用上のオーバーヘッドの削減に有効で、Google Cloud インフラストラクチャ用に最適化されています。マネージド データベースの保守や運用は、Kubernetes に直接デプロイするデータベースよりも簡単です。
  • Kubernetes アプリケーション: データベース インスタンス（MySQL や PostgreSQL など）を GKE クラスタでデプロイして実行できます。

GKE のデータ オプションの詳細については、GKE 上のデータと GKE でのデータベース デプロイを計画するをご覧ください。

特別な要件があるワークロード

GKE には、特定のノード アーキテクチャを必要とするアプリケーション、Cloud TPU を使用する AI / ML ワークロード、Pod を同じノードまたは別のノードで実行する必要があるアプリケーションなど、特別な要件のあるワークロードのデプロイに役立つ機能とガイドが用意されています。これらのデプロイの詳細については、次のガイドをご覧ください。

  • GKE の TPU についてでは、GKE の AI / ML ワークロードに Cloud TPU アクセラレータを使用する方法について説明しています。GKE は、TPU VM の作成、構成、削除など、TPU ノードとノードプールのライフサイクル管理全体をサポートしています。TPU ワークロードは、Standard クラスタと Autopilot クラスタの両方にデプロイできます。
  • GKE の GPU についてでは、GKE ワークロードで GPU ハードウェアをリクエストして使用する方法について説明しています。
  • Autopilot のコンピューティング クラスでは、Autopilot クラスタにアプリケーションをデプロイするときに、Pod のスケジューリングに特定のコンピューティング アーキテクチャを選択する方法について説明しています。Standard クラスタの場合、クラスタの作成時にノードに使用するマシン ファミリーを直接指定できます。
  • カスタム コンピューティング クラスについてでは、Autopilot クラスタと Standard クラスタの両方でアプリケーションのハードウェア オプションを指定する際に、さらに柔軟に対応できるようにカスタム コンピューティング クラスを作成する方法について説明しています。
  • GKE でワークロードの分離を構成するでは、アプリケーションの Pod が同じ基盤となるマシンまたは異なる基盤となるマシンで実行されるようにする方法について説明しています。

ワークロードのモニタリング

GKE には、Google Cloud コンソールでのワークロードの状態と指標の概要の確認、より詳細な指標、ログ、アラートなど、ワークロードとその状態をモニタリングするためのさまざまな機能が用意されています。

ワークロードのデプロイの管理

ワークロードのデプロイ用に継続的インテグレーションとデリバリー（CI / CD）パイプラインを設定する場合は、GKE への継続的インテグレーションとデリバリーのベスト プラクティスで、GKE 固有の CI / CD のベスト プラクティスとガイドラインを確認してください。また、特定のツールとプロダクトを使用して CI / CD パイプラインを設定するチュートリアルもご覧ください。

次のステップ