MIG で VM 構成の更新を自動的に適用する


このドキュメントでは、マネージド インスタンス グループ(MIG)の仮想マシン(VM)インスタンスに構成の更新を自動的に適用する方法について説明します。

Compute Engine は、使用する構成コンポーネント(インスタンス テンプレート、オプションのすべてのインスタンス構成、オプションのステートフル構成)に基づいて MIG 内の VM を維持します。

コンポーネントを変更して MIG の VM 構成を更新すると、Compute Engine は更新された構成を、グループに追加された新しい VM に自動的に適用します。

更新された構成を既存の VM に適用するには、自動更新(先行型更新タイプとも呼ばれます)を設定します。MIG は、グループの VM のすべてまたは一部に構成の更新を自動的にロールアウトします。デプロイの速度、サービス中断のレベルを制御できます。また、カナリア更新を使用することで、MIG が新しい構成で更新するインスタンスの数を制御できます。新しい構成を指定した後は、追加の入力を指定する必要はありません。更新は自動で完了します。

また、新しい構成を MIG の新しいインスタンスまたは特定のインスタンスのみに適用する場合は、MIG で VM 構成の更新を選択的に適用するをご覧ください。判断するには、既存の VM に新しい構成を適用する方法をご覧ください。

始める前に

制限事項

  • ステートフル MIG があり、自動ローリング アップデートを使用する場合は、インスタンスを置換するときにインスタンス名を保持するか、置換メソッドRECREATE に設定する必要があります。

基本的なローリング アップデートの開始

基本的なローリング アップデートとは、すべてのインスタンスが意図する最新の構成に更新されるまで、MIG のすべてのインスタンスに段階的に適用されるアップデートです。ローリング アップデートでは、最新の構成にあるインスタンスが自動的にスキップされます。

更新中にオフラインにすることが可能なインスタンス数、インスタンス間での更新待機時間、新しいテンプレートの影響範囲(全体または一部)など、ローリング アップデートのさまざまな設定を制御できます。

ローリング アップデートの実行時に注意すべき点は以下のとおりです。

  • 更新はインテント ベースです。最初の更新リクエストを行うと、Compute Engine API はリクエストが有効であることを確認するために成功のレスポンスを返しますが、これは更新が成功したことを示すものではありません。更新が正常にデプロイされたかどうかを判断するには、グループのステータスを確認する必要があります。

  • Instance Group Updater API は宣言型 API です。この API は、明示的な関数呼び出しではなく、MIG の更新後に必要な構成を指定するためのリクエストを必要とします。

  • 自動更新では、MIG で最大 2 つのインスタンス テンプレート バージョンをサポートしています。つまり、グループに 2 つの異なるインスタンス テンプレート バージョンを指定できます。これは、カナリアの更新を行う場合に便利です。

グループ内のすべてのインスタンスに更新を適用する基本的なローリング アップデートを開始するには、次の操作を行います。

コンソール

  1. Google Cloud コンソールの [インスタンス グループ] ページに移動します。

    [インスタンス グループ] に移動

  2. 更新する MIG を選択します。

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

  4. [新しいテンプレート] のプルダウン リストをクリックして、更新に使用する新しいテンプレートを選択します。ターゲット サイズは自動的に 100% に設定され、すべてのインスタンスが更新されます。

  5. [構成の更新] で選択メニューを開き、[Update type] で [自動] を選択します。他のオプションはデフォルト値のままにします。

  6. [VM を更新] をクリックして更新を開始します。

gcloud

rolling-action start-update コマンドを使用します。

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=INSTANCE_TEMPLATE_NAME
    [--zone=ZONE | --region=REGION]

以下を置き換えます。

  • INSTANCE_GROUP_NAME: MIG の名前
  • INSTANCE_TEMPLATE_NAME: 新しいインスタンス テンプレート
  • ZONE: ゾーン MIG には、ゾーンを指定します
  • REGION: リージョン MIG には、リージョンを指定します

API

リージョンまたはゾーンの MIG リソースに対して patch メソッドを呼び出します。

たとえば、リージョン MIG の場合、次のリクエストは、すべてのインスタンスを新しいインスタンス テンプレートに自動的に更新するために必要な最小構成を示しています。

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
  "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
  "updatePolicy": {
    "type": "PROACTIVE"
   }
}

リクエストを送った後、更新をモニタリングして、更新が完了したことを確認できます。

詳細な構成を行う場合は、その他の更新オプションを含めます。特に指定しない場合、maxSurge オプションと maxUnavailable オプションはデフォルトで 1 に影響を受けるゾーンの数を掛けたものになります。つまり、影響を受ける各ゾーン内では 1 つのインスタンスだけがオフラインになり、MIG は更新中にゾーンごとに 1 つの追加インスタンスのみを作成します。

更新のオプションの構成

より複雑な更新の場合は、次のセクションで説明するように、追加のオプションを構成できます。

タイプを更新する

マネージド インスタンス グループでは、次の 2 種類の更新がサポートされています。

  • 自動(先行型)更新
  • 選択(追従型)更新

更新を自動的に適用するには、先行型タイプに設定します。

また、自動更新が大がかりになる可能性がある場合は、追従型更新の実行を選択できます。MIG は、選択したインスタンスの更新を手動で開始した場合、または新しいインスタンスが作成された場合にのみ、日和見更新を適用します。ご自身や別のサービス(オートスケーラーなど)で MIG をサイズ変更すると、新しいインスタンスが作成されます。既存のインスタンスで、追従型更新を適用するためのリクエストが Compute Engine から積極的に開始されることはありません。

自動更新と選択更新の詳細については、既存の VM に新しい構成を適用する方法をご覧ください。

最大サージ

maxSurge オプションを使用すると、自動更新中に MIG が targetSize を超えて作成できる新しいインスタンスの数を構成できます。たとえば、maxSurge を 5 に設定すると、MIG は新しいインスタンス テンプレートを使用して、ターゲット サイズを超える最大 5 つの新しいインスタンスを作成します。maxSurge の値が大きくなるほど更新速度は上がりますが、インスタンスの追加による費用がかかります。この費用は Compute Engine の料金表に従って課金されます。

固定数を指定するか、マネージド インスタンス グループに 10 個以上のインスタンスがある場合は割合を指定できます。割合を設定した場合、Updater は必要に応じてインスタンス数の値を切り上げます。

maxSurge の値を設定していない場合は、デフォルト値が使用されます。ゾーン MIG の場合、maxSurge のデフォルトは 1 です。リージョン MIG の場合、デフォルトはグループに関連付けられたゾーンの数です。デフォルトでは 3 です。

maxSurge は、追加のリソースをサポートするために十分な割り当てまたはリソースがある場合に限り機能します。

更新で VM の置き換えが不要な場合、このオプションは無視されます。最小アクション オプションを設定すると、更新中に VM を強制的に置き換えることができます。

オフライン上限

maxUnavailable オプションを使用すると、自動更新中に常時利用できないインスタンスの数を構成できます。たとえば、maxUnavailable を 5 に設定すると、更新の際、同時にオフラインになるのは、5 つのインスタンスだけです。このパラメータを使用して、更新がサービスに与える影響の度合いと、更新をデプロイする速度を制御します。

この数値には、他の理由でオフラインになっているインスタンスの数も含まれます。たとえば、グループがサイズ変更の処理中である場合、作成中のインスタンスがオフラインになることがあります。このようなインスタンスの数は、maxUnavailable にカウントされます。

固定数を指定するか、グループに 10 個以上のインスタンスがある場合は割合を指定できます。割合を設定した場合、Updater は必要に応じてインスタンス数の値を切り下げます。

更新中に使用できないマシンをなくしたい場合は、maxUnavailable 値を 0 に設定し、maxSurge の値を 0 より大きい値に設定します。この設定を行うと、Compute Engine は、古いマシンの代替マシンを新規に作成して実行した後にのみ、古いマシンを削除します。

maxUnavailable の値を設定していない場合は、デフォルト値が使用されます。ゾーン MIG の場合、デフォルトは 1 です。リージョン MIG の場合、デフォルトはグループに関連付けられたゾーンの数です。デフォルトでは 3 です。

最小待機時間

minReadySec オプションを使用して、新しいインスタンスまたは再起動されたインスタンスを更新済みとみなすまでの待機時間を指定します。このオプションを使用して、自動更新がデプロイされるレートを制御します。タイマーは、次の条件がどちらも満たされると起動します。

  • インスタンスのステータスが RUNNING である。
  • ヘルスチェックが有効の場合、ヘルスチェックのときに HEALTHY が返される。

ヘルスチェックを行うにあたり、Updater は次の条件が満たされるのを待ちます。

  1. ヘルスチェックで HEALTHY が返されるまで、MIG の autohealingPolicies.initialDelaySec 値で指定された時間まで待機します。
  2. 次に、minReadySec で指定された時間待機します。

ヘルスチェックが initialDelaySec 内に HEALTHY を返さなければ、Updater は VM インスタンスを異常とみなし、場合によっては更新を停止します。VM インスタンスが initialDelaySecminReadySec で指定された時間、検証を待機している間は、インスタンスの currentActionVERIFYING になります。ただし、基礎となる VM インスタンスのステータスは RUNNING のままです。

グループのヘルスチェックが行われない場合、タイマーはインスタンスのステータスが RUNNING のときに起動します。

minReadySec フィールドの最大値は 3,600 秒(1 時間)です。

次の図は、ターゲット サイズ、オフライン上限、最大サージ、最小待機時間オプションがインスタンスにどのように影響するかを示しています。ターゲット サイズの詳細については、カナリア更新をご覧ください。

ポリシー更新のオプションがリクエストに与える影響

最小アクション

最小アクション オプションは、中断を可能な限り最小限に抑えるため、または必要以上に大がかりなアクションを適用するために使用します。たとえば、Compute Engine ではメタデータを変更するために VM を再起動する必要はありませんが、アプリケーションが VM の再起動時にのみインスタンス メタデータを読み取る場合は、メタデータの変更を取得するために、最小限のアクションを設定して再起動します。

このフラグで設定したアクションよりも大がかりなアクションが更新で必要となる場合、Compute Engine は更新に必要なアクションを実行します。たとえば、最小アクションとして再起動を指定すると、Updater は更新を適用するためにインスタンスの再起動を試みます。ただし、OS を変更する場合(インスタンスの再起動では実行できません)、Updater はグループ内のインスタンスを新しい VM インスタンスに置き換えます。

有効なオプションを含む詳細については、ローリング アップデート中の中断の制御をご覧ください。

許容される最も大がかりなアクション

許容可能なレベルを超える中断が必要な場合は、許容される最も大がかりなアクション オプションを使用して更新を回避します。この設定が原因で更新を完了できない場合、更新は失敗し、VM は以前の構成を維持します。

詳細については、ローリング アップデート中の中断レベルの制御をご覧ください。

置換メソッド

デフォルトでは、MIG をプロアクティブに更新すると、グループが VM インスタンスを削除し、新しい名前の新しいインスタンスに置き換えます。VM インスタンスの名前を保持する必要がある場合は、replacementMethod オプションを使用します。

特定のインスタンス名の使用に依存するアプリケーションやシステムがある場合は、既存のインスタンス名を保持することが役立つ場合があります。たとえば、Memcached などの一部のアプリケーションは、検出サービスがないためインスタンス名に依存しています。その結果、インスタンス名が変更されると、アプリケーションはその特定の VM への接続を失います。

インスタンス名を保持するには、gcloud CLI または Compute Engine API を使用して MIG を更新するときに、置換メソッドを SUBSTITUTE ではなく RECREATE に設定します。Google Cloud コンソールから MIG を更新する場合は、[インスタンスを置き換えるときにインスタンス名を維持する] チェックボックスをオンにします。

マネージド インスタンスの置換メソッド。

指定できる replacementMethod 値は次のとおりです。

  • SUBSTITUTE(デフォルト)。古い VM がシャットダウンされる前に新しい VM が作成されるため、VM インスタンスは更新中にすばやく置換されます。ただし、古いインスタンスでまだ名前が使用されているため、インスタンス名は保持されません。

  • RECREATE。更新を通してインスタンス名が保持されます。Compute Engine は、古い VM がシャットダウンされるとインスタンス名を解放します。その後、Compute Engine は同じ名前を使用して新しいインスタンスを作成します。このモードを使用するには、maxSurge0 に設定する必要があります。

詳細については、インスタンス名の保持をご覧ください。

追加の更新例

ここでは、一般的な構成オプションを使用したコマンドラインの例を示します。

すべての VM インスタンスのローリング アップデートを実行するが、ターゲット サイズを超える新しいインスタンスの作成は一度に 5 個までとする

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --max-surge=5 \
    [--zone=ZONE | --region=REGION]

最大 3 台のオフライン マシン、最小待機時間 3 分を指定してローリング アップデートを実行してから、新しいインスタンスをオンラインとしてマークする

gcloud beta compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --min-ready=3m \
    --max-unavailable=3 \
    [--zone=ZONE | --region=REGION]

すべての VM インスタンスのローリング アップデートを実行するが、ターゲット サイズを超える新しいインスタンスの作成は一度に 10% までとする

たとえば、1,000 個のインスタンスがあり、次のコマンドを実行した場合、Updater は最大 100 個のインスタンスを作成してから、前のインスタンス テンプレートを実行しているインスタンスの削除を開始します。

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --max-surge=10% \
    [--zone=ZONE | --region=REGION]

カナリア更新

カナリア更新とは、グループ内のインスタンスのサブセットに適用される更新です。カナリア更新を使用すると、大がかりになる可能性のある更新をすべてのインスタンスにロールアウトするのではなく、ランダムなインスタンスのサブセットで新しい機能または更新をテストできます。更新がうまくいかない場合、単にインスタンスのサブセットをロールバックするだけで済み、ユーザーに対する影響を最小限に抑えることができます。

カナリア更新は、更新が必要なインスタンス数がインスタンス グループの合計サイズより小さい点を除いては、標準のローリング アップデートと同じです。標準のローリング アップデートと同様に、追加のオプションを構成してサービス中断のレベルを制御できます。

カナリア更新の開始

カナリア更新を開始するには、最大 2 つのインスタンス テンプレート バージョンを指定します。通常、カナリアに対しては新しいインスタンス テンプレートを、残りのインスタンスに対しては現在のインスタンス テンプレートを指定します。たとえば、NEW_INSTANCE_TEMPLATE に基づいてインスタンスの 20% が作成され、残りのインスタンスは引き続き OLD_INSTANCE_TEMPLATE で実行されるように指定できます。同時に指定できるインスタンス テンプレートは 2 つまでです。NEW_INSTANCE_TEMPLATE は、MIG と同じリージョンのリージョン インスタンス テンプレートか、グローバル インスタンス テンプレートのいずれかです。

カナリア バージョンにはターゲット サイズ(targetSize)を常に指定する必要があります。カナリア バージョンのターゲット サイズを省略すると、カナリア更新を開始できません。たとえば、カナリア処理にインスタンスの 10% を使用するように指定した場合、残り 90% のインスタンスはそのままで、現在のインスタンス テンプレートが使用されます。

コンソール

  1. Google Cloud コンソールで、[インスタンス グループ] ページに移動します。

    [インスタンス グループ] に移動

  2. 更新するマネージド インスタンス グループを選択します。
  3. [VM を更新] をクリックします。
  4. [2 つ目のテンプレートを追加] をクリックして、カナリア更新する新しいインスタンス テンプレートを選択します。
  5. [ターゲット サイズ] で、新しいインスタンス テンプレートのカナリア更新に使用するインスタンスの数、または割合を入力します。
  6. 必要に応じて、他の更新オプションを構成できます。
  7. [VM を更新] をクリックして更新を開始します。

gcloud

rolling-action start-update コマンドを使用します。現在のテンプレートと新しいテンプレートを両方指定し、各テンプレートを使用するインスタンス数を明示的に指定します。

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=CURRENT_INSTANCE_TEMPLATE_NAME \
    --canary-version=template=NEW_TEMPLATE,target-size=SIZE \
    [--zone=ZONE | --region=REGION]

以下を置き換えます。

  • INSTANCE_GROUP_NAME: インスタンス グループ名。
  • CURRENT_INSTANCE_TEMPLATE_NAME: インスタンス グループが実行されているインスタンス テンプレート。
  • NEW_TEMPLATE: カナリア更新に使用する新しいテンプレート。
  • SIZE: この更新を適用するインスタンスの数または割合。target-size プロパティは、--canary-version テンプレートに適用する必要があります。グループに 10 個以上のインスタンスが含まれている場合は、割合のみを設定できます。
  • ZONE: ゾーン MIG には、ゾーンを指定します。
  • REGION: リージョン MIG には、リージョンを指定します。

たとえば、次のコマンドは、example-template-B をグループ内のインスタンスの 10% にロールアウトするカナリア更新を実行します。

gcloud compute instance-groups managed rolling-action start-update example-mig \
    --version=template=example-template-A \
    --canary-version=template=example-template-B,target-size=10%

API

リージョンまたはゾーンの MIG リソースに対して patch メソッドを呼び出します。リクエストの本文には、現在のインスタンス テンプレートと、カナリアに追加する新しいインスタンス テンプレートの両方を含めます。次に例を示します。

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
   "targetSize": {
    "[percent|fixed]": NUMBER|PERCENTAGE # Use `fixed` for a specific number of instances
   }
  },
  {
   "instanceTemplate": "global/instanceTemplates/CURRENT_INSTANCE_TEMPLATE_NAME"
  }
 ]
}

以下を置き換えます。

  • NEW_TEMPLATE: カナリアに追加する新しいテンプレートの名前。
  • NUMBER|PERCENTAGE: この更新を行うカナリアのインスタンスの数または割合。グループに 10 個以上のインスタンスが含まれている場合は、割合のみを設定できます。それ以外の場合は、固定数を指定します。
  • CURRENT_INSTANCE_TEMPLATE_NAME: グループが実行されている現在のインスタンス テンプレートの名前。

その他のオプションについては、更新のオプションの構成をご覧ください。

リクエストを送った後、更新をモニタリングして、更新が完了したことを確認できます。

カナリア更新のロール フォワード

カナリア更新の実行後、すべての MIG への更新を commit するかロールバックするかを決定できます。

コンソール

  1. Google Cloud コンソールで、[インスタンス グループ] ページに移動します。

    [インスタンス グループ] に移動

  2. 更新するマネージド インスタンス グループを選択します。
  3. [VM を更新] をクリックします。
  4. [新しいテンプレート] で、カナリア テンプレートのターゲット サイズを 100% に更新して、テンプレートをすべてのインスタンスにロール フォワードするようにします。あるいは、プライマリ テンプレートをカナリア テンプレートに置き換えて、2 つ目のテンプレート フィールドを削除することもできます。
  5. [VM を更新] をクリックして更新を開始します。

gcloud

カナリア更新に commit する場合は、別の rolling-action start-update コマンドを発行して更新をロール フォワードしますが、version フラグのみを設定し、--canary-version フラグを省略します。

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    [--zone=ZONE | --region=REGION]

API

リージョンまたはゾーンの MIG リソースに対して patch メソッドを呼び出します。リクエストの本文で、新しいインスタンス テンプレートを version として指定し、古いインスタンス テンプレートは、リクエスト本文に入れないようにします。すべてのインスタンスに更新をロールアウトするために、ターゲット サイズの指定は省略します。次に例を示します。

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
"versions": [
   {
   "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE" # New instance template
   }
 ]
}

更新のモニタリング

更新を開始した後に、新しい更新に対して影響を受けるすべてのインスタンスへのロールアウトを完了するには時間がかかることがあります。更新の進捗状況は、以下をチェックしてモニタリングできます。

グループのステータス

グループレベルでは、Compute Engine により、versionTarget.isReached フラグisStable フラグを含む status という読み取り専用フィールドに値が設定されます。これらのフラグには、gcloud CLI や Compute Engine API を使用してアクセスできます。Google Cloud コンソールを使用して、現在更新中のインスタンス数とターゲット数を確認することもできます。

Console

グループの詳細ページに移動すると、グループのローリング アップデートをモニタリングできます。

  1. Google Cloud コンソールで、[インスタンス グループ] ページに移動します。

    [インスタンス グループ] に移動

  2. モニタリングするマネージド インスタンス グループを選択します。グループの概要ページに、各インスタンスが使用するテンプレートが表示されます。
  3. 詳細を表示するには、[詳細] タブをクリックします。
  4. [インスタンス テンプレート] で、各インスタンス テンプレートの現在のインスタンス数、インスタンスのターゲット数、更新パラメータを確認できます。

gcloud

describe コマンドを使用します。

gcloud compute instance-groups managed describe INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

gcloud compute instance-groups managed wait-until コマンド--version-target-reached フラグを付けて使用すると、グループの status.versionTarget.isReachedtrue になるまで待機することもできます。

gcloud compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --version-target-reached \
    [--zone=ZONE | --region=REGION]

API

リージョンまたはゾーンの MIG リソースに対して get メソッドを呼び出します。

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME/get

更新の公開が完了したかどうかの確認

MIG の status.versionTarget.isReached フィールドの値を確認して、更新のロールアウトが完了したかどうかを確認します。

  • status.versionTarget.isReachedtrue である場合、すべての VM インスタンスがターゲット バージョンを使用して作成済みまたは作成中であることを示します。

  • status.versionTarget.isReachedfalse である場合、少なくとも 1 つの VM が、まだターゲット バージョンを使用していないことを示します。カナリア更新の場合、false は、ターゲット バージョンを使用する VM の数がターゲット サイズと一致しないことを示します。

マネージド インスタンス グループが安定しているかどうかの確認

グループの status.isStable フィールドの値をチェックして、マネージド インスタンス グループ内のすべてのインスタンスが実行中で正常な状態であることを確認します。

status.isStablefalse である場合は、変更がアクティブか、保留中か、MIG 自体が変更されていることを示します。

status.isStabletrue の場合は、次のことを意味します。

  • なんらかの変更が行われているインスタンスが MIG 内に 1 つもなく、すべてのインスタンスの currentActionNONE となっている。
  • 変更が保留中になっているインスタンスが MIG 内に 1 つもない。
  • MIG 自体も変更されていない。

MIG はさまざまな方法で変更可能なため、MIG の安定性はさまざまな要因で変化します。例:

  • 新しいインスタンス テンプレートのロールアウトをリクエストした。
  • MIG 内のインスタンスの作成、削除、サイズ変更、または更新をリクエストした。
  • オートスケーラーによって MIG のサイズ変更をリクエストした。
  • 自動修復ツールリソースが MIG 内の正常な状態でないインスタンスを少なくとも 1 つ置き換えた。
  • リージョン MIG で、一部のインスタンスが再分散された。

すべてのアクションが終了すると、その MIG の status.isStabletrue に再び設定されます。

インスタンスでの現在のアクション

Google Cloud CLI や Compute Engine API を使用して、マネージド インスタンス グループ内のインスタンスの詳細を表示します。詳細には、インスタンスのステータスと、グループがインスタンスで実行中の現在のアクションが含まれます。

gcloud

すべてのマネージド インスタンス

グループ内のすべてのインスタンスのステータスと現在のアクションを確認するには、list-instances コマンドを使用します。

gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

このコマンドは、ステータス、現在のアクション、その他の詳細情報を含むグループ内のインスタンスの一覧を返します。

NAME               ZONE           STATUS   HEALTH_STATE  ACTION  INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f                          CREATING  my-new-template
vm-instances-h2r1  us-central1-f  STOPPING                DELETING  my-old-template
vm-instances-j1h8  us-central1-f  RUNNING                 NONE      my-old-template
vm-instances-ngod  us-central1-f  RUNNING                 NONE      my-old-template

ヘルスチェックを設定しない限り、HEALTH_STATE 列は空欄になります。

特定のマネージド インスタンス

グループ内の特定のインスタンスのステータスと現在のアクションを確認するには、describe-instance コマンドを使用します。

gcloud compute instance-groups managed describe-instance INSTANCE_GROUP_NAME \
    --instance INSTANCE_NAME \
    [--zone=ZONE | --region=REGION]

このコマンドは、インスタンスの詳細情報(現在のステータス、現在のアクション、ステートフル MIG の保持状態など)を返します。

currentAction: NONE
id: '6789072894767812345'
instance: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/instances/example-mig-hz41
instanceStatus: RUNNING
name: example-mig-hz41
preservedStateFromConfig:
  metadata:
    example-key: example-value
preservedStateFromPolicy:
  disks:
    persistent-disk-0:
      autoDelete: NEVER
      mode: READ_WRITE
      source: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/disks/example-mig-hz41
version:
  instanceTemplate: https://www.googleapis.com/compute/v1/projects/example-project/global/inst