ワークロードのデプロイの概要

コンテナ化されたアプリケーションとその他のワークロードを Google Kubernetes Engine（GKE）クラスタにデプロイして管理するには、Kubernetes システムを使用して Kubernetes コントローラ オブジェクトを作成します。これらのコントローラ オブジェクトは、クラスタ上で実行中のアプリケーション、デーモン、バッチジョブを表します。

コントローラ オブジェクトを作成するには、Kubernetes API または kubectl（gcloud によってインストールされる、Kubernetes へのコマンドライン インターフェース）を使用できます。通常は、目的の Kubernetes コントローラ オブジェクトの表現を YAML 構成ファイルとして作成し、そのファイルを Kubernetes API または kubectlコマンドライン インターフェースで使用します。

ワークロードのタイプ

Kubernetes では、実行可能な多くの種類のワークロードに対応する、さまざまな種類のコントローラ オブジェクトが提供されています。特定のコントローラ オブジェクトは、特定のタイプのワークロードを表すのに適しています。以降のセクションでは、一般的なタイプのワークロードと、クラスタで実行するために作成可能な Kubernetes コントローラ オブジェクトについて説明します。次のようなものがあります。

  • ステートレス アプリケーション
  • ステートフル アプリケーション
  • バッチジョブ
  • デーモン

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

ステートレス アプリケーションは、状態を保持せず、永続ストレージにデータを保存しません。ユーザーデータとセッション データはすべて、クライアントで維持されます。

ステートレス アプリケーションの例としては、Nginx などのウェブ フロントエンド、Apache Tomcat などのウェブサーバー、およびその他のウェブ アプリケーションが挙げられます。

Kubernetes Deployment を作成すれば、クラスタにステートレス アプリケーションをデプロイできます。Deployment によって作成される Pod は一意ではなく、状態を保持しないため、ステートレス アプリケーションのスケーリングや更新が容易になります。

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

ステートフル アプリケーションは、その状態を保存または維持する必要があります。ステートフル アプリケーションはサーバーや他のユーザーによって使用されるデータを保存するために、永続ボリュームなどの永続ストレージを使用します。

ステートフル アプリケーションの例としては、MongoDB などのデータベースや Apache ZooKeeper などのメッセージ キューが挙げられます。

Kubernetes StatefulSet を作成すれば、ステートフル アプリケーションをデプロイすることができます。StatefulSet によって作成されたポッドは、一意の識別子が割り当てられ、順序付けされた安全な方法で更新できます。

バッチジョブ

バッチジョブは、完了するまで実行される、有限で、独立した、（多くの場合）並列のタスクを表します。バッチジョブの例として、電子メールの送信、動画のレンダリング、高度な計算の実行などの自動タスクまたはスケジュールされたタスクが挙げられます。

Kubernetes Job を作成すれば、クラスタ上でバッチタスクを実行して管理することができます。Job が完了する前にタスクを完了する必要があるポッドの数だけでなく、並列実行する必要があるポッドの最大数も指定できます。

デーモン

デーモンは、ユーザーの介入を必要とせずに、割り当てられたノードで継続的なバックグラウンド タスクを実行します。デーモンの例として、Fluentd などのログ収集機能やモニタリング サービスが挙げられます。

Kubernetes DaemonSet を作成すれば、クラスタにデーモンをデプロイすることができます。DaemonSet は、ノードごとに 1 つずつ Pod を作成します。DaemonSet によってデプロイする特定のノードを選択できます。

GKE Autopilot の DaemonSet

GKE は、Autopilot の運用モードを使用して、作成したクラスタ内のノードを管理します。ノードまたは Compute Engine 仮想マシン（VM）を手動で追加、削除、変更することはできません。ただし、Kubernetes ノード オブジェクトは引き続き表示され、Autopilot はワークロードとして DaemonSet をサポートしています。

GKE Autopilot ではいくつかの管理機能が制限されているため、DaemonSet によって管理される Pod を含む、すべてのワークロード Pod に影響します。privileged セキュリティ コンテキストなどの昇格された権限を使用してノードで管理機能を実行する DaemonSet は、GKE によって明示的に許可されていない限り、Autopilot クラスタでは動作しません。

Autopilot によって適用される上限の詳細については、ワークロードの制限をご覧ください。Autopilot によって設定された制限を満たすワークロードを含む DaemonSet や、一部の Google Cloud パートナーの DaemonSet を使用できます。

Autopilot での DaemonSet に関するベスト プラクティス

GKE では、デプロイされたワークロードの合計サイズを使用して、Autopilot がクラスタにプロビジョニングするノードのサイズを決定します。Autopilot がノードをプロビジョニングした後に DaemonSet を追加またはサイズ変更した場合、GKE は新しいノードのサイズの合計に合わせて既存のノードのサイズを変更しません。既存のノードの割り当て可能な容量よりも大きなリソース リクエストを持つ DaemonSet も、システム Pod を考慮した結果、これらのノードではスケジュールされません。

GKE バージョン 1.27.6-gke.1248000 以降では、Autopilot モードのクラスタがどの DaemonSet にも適合しないノードを検出し、時間の経過とともに、すべての DaemonSet に適合できるより大きなノードにワークロードを移行します。このプロセスには時間がかかります。特に、ノードがシステム Pod を実行している場合は、コアクラスタ機能が中断しないように、正常に終了するための時間が必要になります。

GKE バージョン 1.27.5-gke.200 以前では、DaemonSet Pod に対応できないノードを閉鎖してドレインすることをおすすめします

Autopilot に DaemonSet をデプロイする場合は、すべての GKE バージョンで次のベスト プラクティスをおすすめします。

  • 他のワークロードの前に DaemonSet をデプロイする。
  • DaemonSet に、通常の Pod よりも高い PriorityClass を設定します。PriorityClass が高い場合、ノードがこれらの Pod に対応していれば、GKE は優先度の低い Pod を強制排除して DaemonSet Pod に対応します。これにより、ノードの再作成をトリガーせずに各ノードに DaemonSet が存在するようになります。

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

命令型と宣言型のメソッドを使用して、オブジェクトの作成、管理、削除を行うことができます。以降のセクションでは、このようなメソッドと、その導入に使用可能な以下のツールについて説明します。

命令型コマンド

命令型コマンドでは、kubectl を使用してオブジェクトをすばやく作成、表示、更新、削除できます。このコマンドは、1 回限りのタスクやクラスタ内のアクティブなオブジェクトに変更を加える場合に便利です。 命令型コマンドは、通常、クラスタにデプロイされたライブ オブジェクトを操作するために使用されます。

kubectl には、Kubernetes オブジェクトを作成または編集するための動詞駆動型のコマンドがあります。次に例を示します。

  • run: クラスタ内に新しいオブジェクトを生成します。特に指定されなければ、run は Deployment オブジェクトを作成します。run は、他の生成ツールもサポートします。
  • expose: 新しい Service オブジェクトを作成し、トラフィックの負荷を一連のラベル付き Pod 全体にわたって分散します。
  • autoscale: 新しいオートスケーラー オブジェクトを作成し、Deployment などのコントローラ オブジェクトを自動的に水平方向にスケーリングします。

命令型コマンドを使用する際、オブジェクト スキーマに関して熟知している必要はありません。また、構成ファイルも必要としません。

命令型オブジェクト構成

命令型オブジェクト構成では、詳細なオブジェクト定義を含む構成ファイルを使用してオブジェクトの作成、更新、削除が行われます。オブジェクト構成ファイルをソース管理システムに保存することで、命令型コマンドよりも簡単に変更を監査できます。

kubectl apply、delete、replace の操作は、構成ファイル、または構成ファイルが格納されたディレクトリを使用して実行できます。

宣言型オブジェクト構成

宣言型オブジェクト構成は、ローカルに保存された構成ファイルを操作しますが、実行する操作を明示的に定義する必要はありません。代わりに、操作は kubectl によってオブジェクト単位で自動的に検出されます。これは、さまざまな操作で複数の構成ファイルがあるディレクトリを使用する場合に便利です。 宣言型オブジェクトを管理するには、オブジェクト スキーマと構成ファイルに精通している必要があります。

kubectl apply を実行して、宣言型の方法でオブジェクトを作成または更新できます。apply は、ライブ オブジェクト全体を読み取り、差分を計算してから、API サーバーにパッチ リクエストを送信してその差分をマージすることにより、オブジェクトを更新します。

公開 Docker Hub イメージ

Docker Hub から公開コンテナ イメージをデプロイすると、GKE によりコンテナ イメージのキャッシュに保存されたコピーに対してキャッシュ プロキシ mirror.gcr.io が自動的にチェックされます。キャッシュされたコピーが使用できない場合、GKE はリクエストされたイメージを Docker Hub から pull し、キャッシュ プロキシが後で使用できるようにイメージをキャッシュに保存します。詳しくは、キャッシュに保存されたイメージの pull をご覧ください。

コンソール

kubectl または API を使用してワークロードをデプロイした後、Google Cloud コンソールで GKE の [ワークロード] メニューを使用して、クラスタで実行中のワークロードを検査、管理、編集を行うことができます。

このメニューでは以下のような機能が提供されます。

  • YAML ベースのテキスト エディタを使用して、ウェブブラウザからライブ オブジェクトを編集できます。
  • 変更履歴、最近のイベントとアクティビティ、マネージド ポッドなどのオブジェクトに関する詳細情報を表示できます。
  • Deployment、Job、StatefulSet を簡単にスケーリングできます。
  • [操作] メニューから、Deployment の自動スケーリング、ローリング更新のトリガー、手動スケーリングが可能です。
  • Cloud Shell を使用して、任意のオブジェクトを検査、編集、削除できます。

API

GKE REST API と Kubernetes API で Google Cloud クラウド ライブラリを使用することで、プログラムによってワークロードを作成および管理できます。

構成ファイル

前述の方法のいずれかを使用してワークロードをデプロイすると、GKE によってオブジェクトを表現する構成ファイルがクラスタに追加されます。

オブジェクトのライブ構成は、ローカル ファイルと異なる場合があります。YAMLは、Kubernetes オブジェクトの作成と表現によく使用されます。JSON も使用できます。

Kubernetes オブジェクトの仕様、ステータス、Kubernetes API について詳しくは、Kubernetes オブジェクトを理解すると Kubernetes API リファレンスをご覧ください。

ライブ構成を検査する

コンソール

デプロイされたオブジェクトのライブ構成を検査するには、次の手順で操作します。

  1. Google Cloud コンソールの [ワークロード] ページに移動します。

    [ワークロード] に移動

  2. 目的のワークロードを選択します。

  3. YAML をクリックします。

gcloud

デプロイされたオブジェクトのライブ構成を検査するには、次のコマンドを実行します。

kubectl get [OBJECT_TYPE] [OBJECT_NAME] -o yaml

[OBJECT_TYPE] は、deployment、statefulset、job などのオブジェクト型です。次に例を示します。

kubectl get deployment my-stateless-app -o yaml

割り当てによるリソース使用量の管理

多くのユーザーやチームがクラスタ内のリソースを共有する場合、一部の関係者が公正な取り分よりも多くのリソースを使用するかもしれないという懸念があります。Kubernetes ResourceQuota オブジェクトを使用すると、特定の名前空間内でのリソース消費量を制限できます。

また、GKE はデフォルトのイミュータブル gke-resource-quotas オブジェクトを、100 ノード以下のクラスタの名前空間に適用して、不安定性を防止します。

次のステップ