ステートレス Linux アプリケーションのデプロイ

Autopilot Standard

このページでは、Google Kubernetes Engine（GKE）を使用してステートレス Linux アプリケーションをデプロイする方法について説明します。ステートレス Windows アプリケーションをデプロイする方法も学習します。

概要

ステートレス アプリケーションとは、データやアプリケーションの状態をクラスタや永続ストレージに保存しないアプリケーションです。代わりに、データとアプリケーションの状態はクライアントに保持されるため、ステートレス アプリケーションはスケーラビリティが高くなります。たとえば、フロントエンド アプリケーションはステートレスです。複数のレプリカをデプロイして可用性を高め、需要が低いときにはスケールダウンします。これらのレプリカは一意の ID を必要としません。

Kubernetes は、Deployment コントローラを使用してステートレス アプリケーションを一意でない同一の Pod としてデプロイします。Deployment では、アプリケーションを実行する Pod の数、実行するコンテナ イメージのバージョン、Pod にどのラベルを付けるべきかなど、アプリケーションの望ましい状態を管理します。Deployment の Pod 仕様を更新することによって、望ましい状態を動的に変更できます。

ステートレス アプリケーションは、永続ストレージを使用してデータを保存し、StatefulSet を使用して一意の ID を持つ Pod をデプロイするステートフル アプリケーションとは対照的な存在です。

始める前に

作業を始める前に、次のタスクが完了していることを確認してください。

• Google Kubernetes Engine API を有効にする。
Google Kubernetes Engine API の有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
  注: gcloud CLI がすでにインストールされている場合には、必ず compute/region プロパティを設定してください。主にゾーンクラスタを使用する場合は、代わりに compute/zone を設定します。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。クラスタのロケーションが設定したデフォルトと異なる場合は、特定のコマンドでロケーションの指定が必要になることがあります。

• コンテナ化されたアプリケーションが Artifact Registry などのイメージ レジストリに格納されていることを確認します。

• GKE を初めて使用する方は、クイックスタートを完了する必要があります。クイックスタートでは、GKE API を有効にして、このプロダクトの仕組みを学習します。

Deployment の詳細

単純な Deployment マニフェスト ファイルの例を以下に示します。この Deployment では、Artifact Registry に格納された hello-app イメージを実行する run=my-app というラベルの付いた複製 Pod が 3 つ作成されます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      run: my-app
  template:
    metadata:
      labels:
        run: my-app
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

この例では、次のようになります。

• .spec.replicas は、Deployment で管理される複製 Pod の数です。
• .spec.template.metadata.labels は、各 Pod に付けられたラベルで、Deployment が Pod を管理するために使用します。
• .spec.template.spec は Pod 仕様であり、各 Pod の実行方法を定義します。spec.containers には、各 Pod で実行するコンテナの名前および実行するコンテナ イメージが含まれます。

Deployment 仕様の詳細については、Deployment API のリファレンスをご覧ください。

Deployment を作成する

Deployment は次のいずれかの方法で作成します。

• Google Cloud コンソールの [ワークロード] メニューのデプロイ機能を使用して、Artifact Registry に保存したコンテナ イメージから単純な Deployment を作成できます。

• Deployment マニフェストを作成し、kubectl apply を実行してリソースを作成できます。

kubectl apply

kubectl apply を使用すると、マニフェスト ファイルから Deployment を宣言的に作成および更新できます。この方法では、ライブリソースに対して行われた更新も保持され、マニフェスト ファイルに変更がマージされません。

マニフェスト ファイルから Deployment を作成するには、次のコマンドを実行します。

kubectl apply -f DEPLOYMENT_FILE

DEPLOYMENT_FILE は、マニフェスト ファイル（config.yaml など）で置き換えます。

また、kubectl apply -f DIRECTORY/ を使用して、ディレクトリに保存されたマニフェスト ファイルで定義されているすべてのオブジェクト（既存のものを除く）を作成することもできます。

注: アクティブなクラスタがない場合、kubectl apply は失敗します。

Console

Deployment を作成するには、次の操作を行います。

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

   [ワークロード] に移動

2. [ デプロイ] をクリックします。

3. [コンテナを指定] で、次のいずれかを選択します。

   • 既存のコンテナ イメージ: Artifact Registry または DockerHub から使用可能なコンテナ イメージを選択します。[イメージパス] に、コンテナ イメージのパスとバージョンを入力します。

   • 新しいコンテナ イメージ: Cloud Source Repositories と Cloud Build で作成したイメージを使用します。

4. 必要に応じて、デプロイを次のように構成します。

   • 環境変数: コンテナに渡します。
   • 初期コマンド: ランタイムにコンテナのエントリポイントをカスタマイズします。

5. [完了]、[続行] の順にクリックします。

6. [構成] セクションで、デプロイにアプリケーション名を設定し、デプロイする Kubernetes Namespace を指定します。

7. 必要に応じて、[ラベル] で Kubernetes のラベルを Deployment に追加できます。

8. このデプロイを作成する YAML を保存します。後で更新する場合は、[YAML を表示] をクリックします。YAML をコピーしてファイルに貼り付け、[YAML の出力] ダイアログで [閉じる] をクリックします。

9. [Kubernetes クラスタ] プルダウン メニューから、目的のクラスタを選択します。

10. [デプロイ] をクリックします。

Deployment を検査する

Deployment を作成したら、次のいずれかの方法で検査できます。

• [ワークロード] メニューを使用する

• kubectl describe と kubectl get を使用できます。

kubectl

Deployment の詳細情報を取得するには、次のコマンドを実行します。

kubectl describe deployment DEPLOYMENT_NAME

DEPLOYMENT_NAME は、Deployment の名前で置き換えます。

Deployment によって作成された Pod を一覧表示するには、次のコマンドを実行します。

kubectl get pods -l KEY=VALUE

このコマンドで -l フラグを指定すると、kubectl は Key-Value ラベルを持つすべてのポッドを取得します。たとえば、Deployment のラベルが run: my-app の場合、kubectl get pods -l run=my-app を実行すると、このラベルを持つポッドが表示されます。

特定の Pod の情報を取得するには、次のコマンドを実行します。

kubectl describe pod POD_NAME

Deployment のマニフェストを確認するには、次のコマンドを入力します。

kubectl get deployments DEPLOYMENT_NAME -o yaml

このコマンドは、Deployment のライブ構成を YAML 形式で表示します。

Console

Deployment を検査するには、次の操作を行います。

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

   [ワークロード] に移動

2. ワークロード リストで、検査する Deployment の名前をクリックします。

3. [デプロイの詳細] ページで、次の操作を行います。

   • [変更履歴] タブをクリックして、Deployment の変更履歴を確認します。
   • [イベント] タブをクリックすると、Deployment に関連するすべてのイベントが表示されます。
   • [ログ] タブをクリックして、Deployment のコンテナ アクティビティ ログを確認します。
   • [YAML] タブをクリックして、Deployment の YAML マニフェストを表示、コピー、ダウンロードします。

Deployment を更新する

更新は、Deployment のPod 仕様（イメージ、リソースの使用量 / リクエスト、構成など）にロールアウトできます。

次の方法で Deployment を更新できます。

• Google Cloud コンソールの [ワークロード] メニューから [ローリング アップデート] メニューと YAML エディタを使用できます。
• マニフェスト ファイルを変更し、それを kubectl apply によって適用できます。
• kubectl set を使用すると、Pod 仕様の image、resources または selector フィールドを更新できます。

• kubectl edit を使用して、シェルまたは任意のエディタで Deployment を直接更新できます。

kubectl apply

新規作成または更新されたマニフェスト ファイルを適用することで、Deployment を更新できます。 これは、スケーリングやアプリケーションの新しいバージョンの指定など、デプロイにさまざまな変更を加える場合に便利です。

注: kubectl apply を使用してリソースを更新するには、kubectl apply または kubectl create --save-config を使用してリソースが作成されている必要があります。

Deployment を更新するには、次のコマンドを実行します。

kubectl apply -f DEPLOYMENT_FILE

DEPLOYMENT_FILE は、更新されたマニフェスト ファイルに置き換えます。

kubectl apply コマンドは、リソースにマニフェスト ファイルを適用します。指定されたリソースが存在しない場合は、このコマンドによって作成されます。

kubectl set

kubectl set を使用すると、Deployment のイメージ、リソース（必須または制限）またはセレクタ フィールドを変更できます。

Deployment のイメージを変更するには、次のコマンドを実行します。

kubectl set image deployment DEPLOYMENT_NAME IMAGE IMAGE:TAG

たとえば、デプロイを nginx バージョン 1.7.9 から 1.9.1 に更新するには、次のコマンドを実行します。

kubectl set image deployment nginx nginx=nginx:1.9.1

Console

Deployment の [ローリング アップデート] メニューにアクセスするには:

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

   [ワークロード] に移動

2. ワークロード リストで、変更する Deployment の名前をクリックします。

3. [アクション] > [ローリング アップデート] をクリックします。

4. 更新戦略のオプション パラメータを構成します。

   • 準備の最短秒数: 新しく作成された Pod が使用可能と見なされるまでの最小秒数を指定します。
   • 最大サージ: 必要な Pod 数を超えて作成できる Pod の最大数を指定します。値として絶対数または割合を指定できます。
   • 最大使用不可: 更新プロセス中に許容される、使用できない状態の Pod の最大数を指定します。値として絶対数または割合を指定できます。

5. [コンテナ イメージ] で、更新されたコンテナ イメージのイメージパスとバージョンを入力します。

6. [更新] をクリックします。

更新のロールバック

kubectl rollout undo を使用すると、更新をロールバックできます。

進行中の更新または完了した更新を以前のリビジョンにロールバックできます。

kubectl rollout undo deployment my-deployment

特定のリビジョンにロールバックすることもできます。

kubectl rollout undo deployment my-deployment --to-revision=3

Deployment をスケーリングする

Google Cloud コンソールまたは kubectl scale を使用して、Deployment を手動でスケーリングできます。

詳細については、Deployment を自動スケーリングするをご覧ください。

kubectl

Deployment をスケーリングするには、kubectl scale を使用します。これはいつでも実行できます。

Deployment を手動でスケーリングするには、次のコマンドを実行します。

kubectl scale deployment DEPLOYMENT_NAME --replicas NUMBER_OF_REPLICAS

NUMBER_OF_REPLICAS は、必要な複製 Pod の数に置き換えます。

Console

Deployment をスケールするには、次の操作を行います。

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

   [ワークロード] に移動

2. ワークロード リストで、変更する Deployment の名前をクリックします。

3. [アクション] > [スケール] > [レプリカの編集] をクリックします。

4. Deployment の新しいレプリカ数を入力します。

5. [スケール] をクリックします。

Deployment を削除する

Deployment を手動で削除するには、 Google Cloud コンソールまたは kubectl delete を使用します。

kubectl

Deployment を削除するには、次のコマンドを実行します。

kubectl delete deployment DEPLOYMENT_NAME

Console

Deployment を削除するには、次の操作を行います。

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

   [ワークロード] に移動

2. ワークロード リストで、削除する 1 つ以上の Deployment を選択します。

3. [ 削除] をクリックします。

4. 確認のメッセージが表示されたら、[削除] をクリックします。

次のステップ

• Deployment の詳細を学習する。
• ステートフル アプリケーションを確認する。