本頁面由 Cloud Translation API 翻譯而成。

自動套用 MIG 中的 VM 設定更新

本文說明如何自動將設定更新套用至代管執行個體群組 (MIG) 中的虛擬機器 (VM) 執行個體。

Compute Engine 會根據您使用的設定元件 (執行個體範本、選用的所有執行個體設定，以及選用的具狀態設定)，維護 MIG 中的 VM。

每當您變更這些元件來更新 MIG 的 VM 設定時，Compute Engine 會自動將更新後的設定套用至新增至群組的 VM。

如要將更新後的設定套用至現有 VM，可以設定自動更新，也就是主動更新類型。MIG 會自動將設定更新發布至群組的所有 VM 或部分 VM。您可以控制部署速度、服務中斷程度，以及使用初期測試版更新時，MIG 以新設定更新的執行個體數量。指定新設定後，您不必提供其他輸入內容，更新作業就會自行完成。

或者，如要選擇性地將新設定套用至 MIG 中的新執行個體或特定執行個體，請參閱「在 MIG 中選擇性套用 VM 設定更新」一文。如要瞭解如何決定，請參閱「將新設定套用至現有 VM 的方法」。

事前準備

如要更新有狀態的 MIG，請參閱「套用、查看及移除 MIG 中的有狀態設定」。
如果尚未設定驗證，請先完成設定。「驗證」是指驗證身分的程序，確認您有權存取 Google Cloud 服務和 API。如要從本機開發環境執行程式碼或範例，請選取下列任一選項，向 Compute Engine 進行驗證：

Select the tab for how you plan to use the samples on this page:
Console

When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.
gcloud
1. 安裝 Google Cloud CLI。安裝完成後，執行下列指令初始化 Google Cloud CLI：
  gcloud init
  如果您使用外部識別資訊提供者 (IdP)，請先使用聯合身分登入 gcloud CLI。
  
  注意：如果您先前已安裝 gcloud CLI，請執行 gcloud components update，確認您使用的是最新版本。
2. Set a default region and zone.
REST

如要在本機開發環境中使用本頁的 REST API 範例，請使用您提供給 gcloud CLI 的憑證。
詳情請參閱 Google Cloud 驗證說明文件中的「Authenticate for using REST」。

限制

如果您有有狀態的 MIG，且想使用自動滾動式更新，替換執行個體時必須保留執行個體名稱，或將替換方法設為 RECREATE。

啟動基本的滾動式更新作業

基本滾動式更新會逐步更新 MIG 中的所有執行個體，直到所有執行個體都更新為最新的預期設定為止。系統會自動略過已採用最新設定的執行個體。

您可以控制滾動式更新的各種層面，例如要將多少個執行個體離線更新、執行個體的更新間隔、新範本會影響全體或僅部分的執行個體等等。

以下是進行滾動式更新時的注意事項：

更新是意圖式的。當您第一次提出更新要求時，Compute Engine API 會傳回成功的回應來向您確認該要求是有效的，但這不代表更新已順利完成。您必須查看群組的狀態，才能判斷更新是否已成功部署。
Instance Group Updater API 是宣告式 API。API 預期您會在提出的要求中，指定 MIG 的更新後設定，而非明確的函式呼叫。
自動更新功能支援 MIG 中最多兩個版本的執行個體範本。這表示您可以為群組指定兩個不同的執行個體範本版本，這對執行初期測試更新很有幫助。

如要啟動基本的滾動式更新，並將更新套用到群組中所有執行個體，請按照下列操作說明進行。

這項工作需要的權限

如要執行這項工作，您必須具備以下權限：

如果是區域 MIG，呼叫 instanceGroupManagers.patch 方法需要的所有權限
如果是區域 MIG，呼叫 regionInstanceGroupManagers.patch 方法需要的所有權限

主控台

前往 Google Cloud 控制台的「Instance groups」(執行個體群組) 頁面。

前往「Instance groups」(執行個體群組) 頁面
選取要更新的 MIG。
按一下「更新 VM」。
在「New template」(新範本) 下方，按一下下拉式清單，然後選取要做為更新目標的新範本。目標大小會自動設為 100%，表示所有執行個體都會更新。
在「更新設定」下方，展開選單並選取「自動」做為「更新類型」。其他選項則保留預設值。
按一下「更新 VM」即可開始更新。

gcloud

使用 rolling-action start-update 指令。

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

更改下列內容：

INSTANCE_GROUP_NAME：MIG 的名稱
INSTANCE_TEMPLATE_URL：您要用來在 MIG 中建立 VM 的執行個體範本網址。網址可以包含執行個體範本的ID 或名稱。指定下列其中一個值：
- 如果是區域執行個體範本：projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
- 全域執行個體範本：INSTANCE_TEMPLATE_ID
ZONE：如果是區域 MIG，請提供區域
REGION：如果是區域 MIG，請提供區域

REST

在區域或可用區 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 個額外的執行個體。

設定更新的選項

如要進行更複雜的更新，可以設定其他選項，詳情請參閱下列各節。

更新類型

代管執行個體群組支援下列兩種更新類型：

自動或主動更新
選擇性或隨機更新

如要自動套用更新，請將類型設為「主動式」。

或者，如果自動更新可能造成過大的干擾，您可以選擇執行機會式更新。只有在您針對選定的執行個體手動啟動更新時，或是在新的執行個體是由代管執行個體群組所建立時，MIG 才會套用隨機式更新。當您或其他服務 (例如自動調度器) 調整 MIG 大小時，系統會建立新的執行個體。Compute Engine 不會主動啟動會對現有執行個體套用隨機式更新的要求。

如要進一步瞭解自動更新與選擇性更新，請參閱「將新設定套用至現有 VM 的方法」。

可擴充的 pod 數量上限

使用 maxSurge 選項，設定 MIG 在自動更新期間可建立的新執行個體數量，上限為 targetSize。舉例來說，如果您將 maxSurge 設定為 5，則 MIG 會利用新的執行個體範本，建立最多超出目標大小 5 個的新執行個體。設定較高的 maxSurge 值可加快更新速度，但代價是會產生額外的執行個體，而我們會根據 Compute Engine 的價目表向您收取這些執行個體的費用。

您可以指定固定數量，或是在群組至少有 10 個執行個體時指定百分比。如果您指定百分比，Updater 就會在必要時以無條件進位的方式來計算執行個體數量。

如果您沒有設定 maxSurge 值，系統會採用預設值。對於區域 MIG，maxSurge 的預設值為 1。對於地區 MIG，預設值是與群組相關聯的區域數目，預設為 3。

maxSurge 只在您有足夠的配額或資源來支援額外的資源時才有作用。

如果更新不需要更換 VM，系統會忽略這個選項。您可以設定最小動作選項，在更新期間強制更換 VM。

無法使用的 pod 數量上限

使用 maxUnavailable 選項設定自動更新期間，任何時候都無法使用的執行個體數量。舉例來說，如果您將 maxUnavailable 設定為 5，系統在同一時間就只會讓 5 個執行個體離線來進行更新。使用這個選項就能控制更新作業對您服務的干擾程度，以及控制更新的部署速率。

這個數量也包括因其他原因而無法使用的所有執行個體。舉例來說，如果群組正處於調整大小的過程中，則正在建立的執行個體可能無法使用。這些執行個體會計入 maxUnavailable 數量。

您可以指定固定數量，或是在群組至少有 10 個執行個體時指定百分比。如果您指定百分比，Updater 就會在必要時以無條件捨去的方式來計算執行個體數量。

如果不想在更新期間有任何機器無法使用，請將 maxUnavailable 值設為 0，並將 maxSurge 值設為大於 0。使用這些設定時，Compute Engine 只會在建立並執行替代的新機器後，移除每個舊機器。

如果您沒有設定 maxUnavailable 值，系統會採用預設值。對於區域 MIG，預設值為 1。如果是地區 MIG，預設值是與群組相關聯的區域數量，預設為 3。

最短等待時間

使用 minReadySec 選項指定要等待多久時間後，才會將新建立或重新啟動的執行個體視為已更新。使用這個選項可控制自動更新的部署速率。計時器會在以下兩個條件皆符合時開始計時：

執行個體的狀態為 RUNNING。
如果健康狀態檢查已啟用，且健康狀態檢查傳回 HEALTHY 時。

請注意，為了讓健康狀態檢查傳回健康狀態良好，Updater 會等待下列條件：

最多會等待由 MIG 的 autohealingPolicies.initialDelaySec 值為了讓健康狀態檢查傳回 HEALTHY 所指定的時間。
然後，等待由 minReadySec 所指定的時間。

如果健康狀態檢查沒有在 initialDelaySec 的時間內傳回 HEALTHY，Updater 就會宣告 VM 執行個體的健康狀態不良，然後可能會停止更新作業。當 VM 執行個體在 initialDelaySec 和 minReadySec 的時間範圍內等待驗證時，執行個體的 currentAction 會顯示為 VERIFYING。不過基礎 VM 執行個體的狀態仍會是 RUNNING。

如果群組沒有健康狀態檢查，計時器就會在執行個體的狀態為 RUNNING 時開始計時。

minReadySec 欄位的最大值為 3600 秒 (1 小時)。

下圖說明目標大小、無法使用數量上限、供應過度上限和最短等待時間選項，如何影響執行個體。如要進一步瞭解目標大小，請參閱「Canary 更新」。

最少動作

使用「最少動作」選項，盡可能減少干擾，或套用干擾程度高於必要動作的動作。舉例來說，Compute Engine 不必重新啟動 VM 即可變更中繼資料。但如果應用程式只會在 VM 重新啟動時讀取執行個體中繼資料，您可以將最少動作設為重新啟動，以便擷取中繼資料變更。

如果您的更新作業需要執行干擾程度超出您利用此標記所設定的動作，Compute Engine 就會執行必要的動作來進行更新。舉例來說，如果您將重新啟動設為最少動作，Updater 就會嘗試重新啟動執行個體來執行更新作業。但如果您要變更作業系統 (無法透過重新啟動執行個體完成)，Updater 就會以新的 VM 執行個體取代群組中的執行個體。

如要瞭解有效選項等詳細資訊，請參閱「在輪替更新期間控管中斷程度」。

允許的最大干擾動作

如果更新作業需要執行的干擾動作超過您能承擔的範圍，請使用「允許的最大干擾動作」選項禁止更新。如果這項設定導致更新無法完成，更新就會失敗，VM 會維持先前的設定。

詳情請參閱「在滾動更新期間控管中斷程度」。

替換方法

根據預設，當您主動更新 MIG 時，群組會刪除 VM 執行個體，並換成具有新名稱的新執行個體。如要保留 VM 執行個體的名稱，請使用 replacementMethod 選項。

如果您有應用程式或系統需要使用特定執行個體名稱，保留現有執行個體名稱可能會有幫助。舉例來說，部分應用程式 (例如 Memcached) 依賴執行個體名稱，因為這些應用程式沒有探索服務；因此，每當執行個體名稱變更時，應用程式就會失去與該特定 VM 的連線。

如要保留執行個體名稱，請使用 gcloud CLI 或 Compute Engine API 更新 MIG 時，將替換方法設為 RECREATE，而非 SUBSTITUTE。或者，如果您是透過 Google Cloud 控制台更新 MIG，請選取「替換 VM 時保留名稱」核取方塊。

受管理執行個體更換方法。

replacementMethod 的有效值如下：

SUBSTITUTE (預設)。在更新期間，系統會先建立新的 VM，再關閉舊的 VM，因此能更快取代 VM 執行個體。不過，由於舊執行個體仍在使用這些名稱，因此執行個體名稱不會保留。
RECREATE。在更新期間保留執行個體名稱。Compute Engine 會在舊 VM 關閉時釋出執行個體名稱。接著，Compute Engine 會使用相同名稱建立新執行個體。如要使用這個模式，請將 maxSurge 設為 0。

詳情請參閱保留執行個體名稱。

其他更新範例

以下是幾個附帶常見設定選項的指令列範例。

執行所有 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]

執行所有虛擬機器執行個體的滾動式更新，但同一時間最多只能建立超出目標大小 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]

初期測試更新

初期測試更新就是只會對群組中的部分執行個體執行的更新作業。透過初期測試更新，您可以對隨機選擇的執行個體子集測試新的功能或升級，而非對所有執行個體進行可能會干擾服務的更新作業。如果更新並不順利，您只需要復原小部分的執行個體，進而將對使用者的干擾降到最低。

初期測試更新與標準的滾動式更新是一樣的，唯一的不同之處在於，初期測試更新要更新的執行個體數量，少於執行個體群組中的執行個體總數。與標準的滾動更新一樣，您可以設定其他選項，控管服務中斷的程度。

啟動初期測試更新

如要啟動初期測試更新，請指定最多兩個版本的執行個體範本，通常一個是用於進行初期測試的新執行個體範本，另一個則是剩下的執行個體目前所用的執行個體範本。舉例來說，您可以指定有 20% 的執行個體是根據 NEW_INSTANCE_TEMPLATE 建立的，而剩下的執行個體則繼續根據 OLD_INSTANCE_TEMPLATE 來執行。您無法同時指定兩個以上的執行個體範本。NEW_INSTANCE_TEMPLATE可以是與 MIG 位於相同區域的區域執行個體範本，也可以是全域執行個體範本。

您必須指定初期測試版本的目標大小 (targetSize)。如果您省略初期測試版本的目標大小，就無法啟動初期測試更新。舉例來說，如果您指定要把 10% 的執行個體用來執行初期測試，剩下 90% 就不會受到影響，且會使用目前的執行個體範本。

這項工作需要的權限

如要執行這項工作，您必須具備以下權限：

如果是區域 MIG，呼叫 instanceGroupManagers.patch 方法需要的所有權限
如果是區域 MIG，呼叫 regionInstanceGroupManagers.patch 方法需要的所有權限

主控台

前往 Google Cloud 控制台的「Instance groups」(執行個體群組) 頁面。
前往「Instance groups」(執行個體群組) 頁面
選取要更新的代管執行個體群組。
按一下「更新 VM」。
按一下「新增第二個範本」，然後選擇要進行初期測試的新執行個體範本。
在「Target size」(目標大小) 下方，輸入您要用來對新的執行個體範本進行初期測試的執行個體數量百分比，或是固定的執行個體數量。
如有需要，可以設定其他更新選項。
按一下「更新 VM」即可開始更新。

gcloud

使用 rolling-action start-update 指令。請提供目前的範本和新的範本，以便明確表示這兩個範本分別會有多少執行個體採用：

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

更改下列內容：

INSTANCE_GROUP_NAME：執行個體群組名稱。
CURRENT_INSTANCE_TEMPLATE：執行個體群組目前執行的執行個體範本。
NEW_TEMPLATE：要進行初期測試的新範本。
SIZE：要套用此更新的執行個體數量或百分比。您必須將 target-size 屬性套用至 --canary-version 範本。如果群組至少有 10 個執行個體，您就只能設定百分比。
ZONE：如果是可用區 MIG，請提供可用區。
REGION：如果是區域 MIG，請提供區域。

舉例來說，下列指令會執行初期測試更新，針對群組中 10% 的執行個體推出 example-template-B：

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%

REST

在區域或可用區 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"
  }
 ]
}

更改下列內容：

NEW_TEMPLATE：您要進行初期測試的新範本名稱。
NUMBER|PERCENTAGE：要初期測試此更新的執行個體固定數量或百分比。如果群組至少有 10 個執行個體，您就只能設定百分比。否則，請提供固定數量。
CURRENT_INSTANCE_TEMPLATE：群組目前執行的執行個體範本。

如需更多選項，請參閱「設定更新的選項」。

提出要求後，即可監視更新作業，瞭解更新何時完成。

將初期測試更新向前推進

執行初期測試更新後，您可以決定是否要讓整個 MIG 都採用這個更新，或是要復原。

主控台

前往 Google Cloud 控制台的「Instance groups」(執行個體群組) 頁面。
前往「Instance groups」(執行個體群組) 頁面
選取要更新的代管執行個體群組。
按一下「更新 VM」。
在「New template」(新範本) 下方，將初期測試範本的目標大小更新為「100%」，以便將範本向前滾動至所有的執行個體。或者，您可以使用初期測試範本取代主要範本，並移除第二個範本欄位。
按一下「更新 VM」即可開始更新。

gcloud

如果對初期測試更新的結果感到滿意，請發出另一個 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]

REST

在區域或可用區 MIG 資源上呼叫 patch 方法。請在要求主體中，利用 version 來指定新的執行個體範本，並把舊的執行個體範本從要求主體中去除。請去除目標大小規格，以便對 100% 的執行個體推出這個更新。例如：

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
   }
 ]
}

監控更新

啟動更新後，新設定需要一段時間，才會完成向所有受影響執行個體推出。如要監控更新進度，請檢查下列項目：

如要確認所有 VM 是否都已達到目標範本版本，請查看群組狀態。
如要確認特定 VM 是否已達到目標範本版本，請查看執行個體的目前動作。
如為有狀態 MIG，另請參閱「確認是否已套用個別執行個體設定」。

群組狀態

在群組層級，Compute Engine 會在名為 status 的唯讀欄位中填入值，該欄位包含 versionTarget.isReached 旗標和 isStable 旗標。您可以使用 gcloud CLI 或 REST 存取這些標記。您也可以利用 Google Cloud 主控台，查看目前正在更新中和計劃要更新的執行個體數量。

這項工作需要的權限

如要執行這項工作，您必須具備以下權限：

compute.instanceGroupManagers.get的 MIG

主控台

只要前往群組的詳細資料頁面，即可監控該群組的滾動式更新作業。

前往 Google Cloud 控制台的「Instance groups」(執行個體群組) 頁面。
前往「Instance groups」(執行個體群組) 頁面
選取要監控的代管執行個體群組。群組的總覽頁面會顯示每個執行個體使用的範本。
如要檢視詳細資料，請按一下 [Details] (詳細資料) 分頁標籤。
在「Instance template」(執行個體範本) 下方，您可以查看每個執行個體範本的目前執行個體數和目標數量，以及更新參數。

gcloud

使用 describe 指令。

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

您也可以利用搭配 --version-target-reached 標記的 gcloud compute instance-groups managed wait-until 指令來等待，直到該群組的 status.versionTarget.isReached 變成 true 為止：

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

REST

在區域或可用區 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.isReached 設為 true 表示所有 VM 執行個體都已是目標版本，或是正在建立成目標版本。
status.versionTarget.isReached 設為 false 表示至少有一個 VM 尚未使用目標版本。或者在初期測試更新的情況下，false 表示使用目標版本的 VM 數量與該更新的目標大小不相符。

檢查代管執行個體群組是否穩定

如要確認代管執行個體群組中的所有執行個體是否都在執行中，且健康狀態良好，請查看群組的 status.isStable 欄位值。

當 status.isStable 為 false 時，代表變更已生效、待處理，或是系統正在修改 MIG。

當 status.isStable 為 true 時，則代表：

在 MIG 中，沒有任何執行個體遭到任何類型的變更，且所有執行個體的 currentAction 都顯示 NONE。
代管執行個體群組中的執行個體沒有任何待處理的變更。
代管執行個體群組本身未經修改。

請注意，MIG 的穩定性取決於多項因素，因為 MIG 可以透過多種方式修改。例如：

由您發出推出新執行個體範本的要求。
由您發出建立、刪除、調整大小或更新 MIG 中執行個體的要求。
自動調度器要求調整 MIG 大小。
自動修復程式資源正在取代 MIG 中一或多個健康狀態不良的執行個體。
在地區 MIG 中，部分執行個體正在重新分配。

當所有動作都執行完畢之後，該 MIG 的 status.isStable 會再次變成 true。

目前對執行個體的動作

使用 Google Cloud CLI 或 REST，查看代管執行個體群組中執行個體的詳細資料。詳細資料包括執行個體狀態，以及群組目前對執行個體執行的動作。

這項工作需要的權限

如要執行這項工作，您必須具備以下權限：

compute.instanceGroupManagers.get群組
compute.instanceGroupManagers.list群組

gcloud

所有受管理執行個體

如要檢查群組中所有執行個體的狀態和目前動作，請使用 list-instances 指令。

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

這個指令會傳回群組中的執行個體清單，包括狀態、目前動作和其他詳細資料：

NAME: vm-instances-9pk4
ZONE: us-central1-f
STATUS:
HEALTH_STATE:
ACTION: CREATING
INSTANCE_TEMPLATE: my-new-template
VERSION_NAME:
LAST_ERROR:

NAME: vm-instances-h2r1
ZONE: us-central1-f
STATUS: STOPPING
HEALTH_STATE:
ACTION: DELETING
INSTANCE_TEMPLATE: my-old-template
VERSION_NAME:
LAST_ERROR:

除非您已設定健康狀態檢查，否則 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/instanceTemplates/example-template

REST

在區域或可用區 MIG 資源上呼叫 listManagedInstances 方法。舉例來說，如要查看區域 MIG 資源中執行個體的詳細資料，可以發出下列要求：

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME/listManagedInstances

呼叫會傳回 MIG 的執行個體清單，其中包含每個執行個體的 instanceStatus 和 currentAction。

{
  "managedInstances": [
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-prvp",
      "instanceStatus": "RUNNING",
      "currentAction": "REFRESHING",
      "id": "5317605642920955957",
      "version": {
        instanceTemplate": "https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template"
      },
      "name": "vm-instances-prvp"
    },
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-w2t5",
      "instanceStatus": "RUNNING",
      "currentAction": "REFRESHING",
      "id": "2800161036826218547",
      "version": {
        "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template"
      },
      "name": "vm-instances-w2t5"
    }
  ]
}

如果您設定健康狀態檢查，回應也會包含 instanceHealth 欄位。

如要查看有效的 instanceStatus 欄位值清單，請參閱 VM 執行個體生命週期。

如果執行個體正在經歷某種類型的變更，代管執行個體群組就會將執行個體的 currentAction 欄位設為下列其中一個動作，協助您追蹤變更進度。否則，currentAction 欄位會設為 NONE。

可能的 currentAction 值：

ABANDONING：執行個體正從 MIG 中移除。
CREATING：執行個體目前正在建立。
CREATING_WITHOUT_RETRIES：執行個體目前正在建立，且不會重試；如果執行個體在第一次嘗試時無法建立，則 MIG 將不會嘗試再次取代執行個體。
DELETING：執行個體目前正在刪除。
RECREATING：執行個體正在更換。
REFRESHING：執行個體正從其目前目標集區中移除，並正讀入至現有的目標集區清單中 (此清單可能會與現有目標集區相同或不同)。
RESTARTING：系統正在使用 stop 和 start 方法重新啟動該執行個體。
RESUMING：執行個體已暫停，目前正在恢復。
STARTING：執行個體已停止，目前正在啟動。
STOPPING。執行個體正在停止。
SUSPENDING：執行個體正在暫停。
VERIFYING：執行個體已建立，目前正受到驗證。
NONE：目前並未對執行個體執行任何動作。

復原更新內容

目前沒有可將更新復原到先前版本的明確指令，但如果您決定要將更新復原 (無論是全面更新還是初期測試更新)，您可以提出新的更新要求，並在其中提供做為復原目標的執行個體範本。

gcloud

舉例來說，下列 gcloud CLI 指令會盡快將復原更新。將 OLD_INSTANCE_TEMPLATE 換成做為復原目標的執行個體範本名稱。

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

REST

在區域或可用區 MIG 資源上呼叫 patch 方法。

請在要求主體中，將先前的執行個體範本指定為 version：

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

{
  "updatePolicy":
  {
    "maxUnavailable":
    {
      "percent": 100
    }
  },
  "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/OLD_INSTANCE_TEMPLATE" # Old instance template
    }
  ]
}

如果是少於 10 個執行個體的地區 MIG，則您必須在 maxUnavailable 中使用固定值，並將該值設為群組中的執行個體數目。

Updater 會將復原要求視為一般更新要求，因此您可以指定其他更新選項。

停止更新

目前沒有可停止更新的明確方法或指令。您可以把更新從主動式變更成隨機式，這會讓群組在沒有遭到其他服務 (例如自動配置器) 調整大小時，您把更新變更為隨機式的做法將會有效地停止更新。

如要使用 gcloud CLI 將更新從主動式變更為隨機式，請執行下列指令：

gcloud compute instance-groups managed rolling-action stop-proactive-update INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

如果您在把更新從主動式轉換到隨機式之後，想要完全停止更新，請按照下列步驟操作：

提出要求，判斷系統已更新多少個執行個體：

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

gcloud CLI 會傳回回應，其中包含群組中的執行個體清單，以及每個執行個體目前的狀態：

NAME               ZONE           STATUS   HEALTH_STATE  ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f  RUNNING  HEALTHY       NONE      example-new-template
vm-instances-j1h8  us-central1-f  RUNNING  HEALTHY       NONE      example-old-template
vm-instances-ngod  us-central1-f  STAGING  UNKNOWN       CREATING  example-new-template

在此範例中，兩個執行個體已更新。

接著，提出要求來執行新的更新，但傳遞已更新的執行個體數目來做為目標大小：

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

對 Updater 來說，這個更新作業看來已完成，因此不會再更新任何執行個體，進而有效地停止了更新。

控制滾動式更新的速度

根據預設，當您提出更新要求時，Updater 就會盡快執行更新作業。如果您不確定要完全套用更新，還是試驗性測試變更，可使用下列方式來控制更新速度。

啟動初期測試更新，而非完全更新。
設定較大的 minReadySec 值。設定此值會造成更新程式必須先等待這個秒數之後，才會將執行個體視為已成功更新，並繼續處理下一個執行個體。
啟用健康狀態檢查，讓更新程式會先等待應用程式啟動並回報健康狀態良好之後，才會把執行個體視為已更新完畢，然後繼續更新下一個執行個體。
設定較小的 maxUnavailable 和 maxSurge 值，這可確保系統一次只會更新少數的執行個體。
選擇性更新 MIG 中的執行個體，而非使用自動更新。

您也可以結合上述的不同方法來控制更新的速率。

控制滾動式更新期間的中斷程度

視更新的性質而定，更新作業可能會干擾執行個體的生命週期狀態。舉例來說，如要變更執行個體的開機磁碟，就必須取代執行個體。您可以設定下列選項，控制滾動式更新期間的干擾程度：

最少動作：使用這個選項盡可能減少干擾，或套用干擾程度高於必要動作的動作。
- 為盡可能減少中斷，請將最低動作設為 REFRESH。如果更新作業需要干擾程度較大的動作，Compute Engine 就會執行該動作。
- 如要套用干擾程度超出必要範圍的動作，請將最少動作設為 RESTART 或 REPLACE。舉例來說，Compute Engine 不必重新啟動 VM，即可變更 VM 的中繼資料。但如果應用程式只會在 VM 重新啟動時讀取執行個體中繼資料，您可以將最低動作設為 RESTART，以便擷取中繼資料變更。
允許的最大干擾動作：如果更新作業所需的干擾程度超出您的承受範圍，請使用這個選項禁止更新。如果您的更新作業需要執行干擾程度超出您利用此標記所設定的動作，更新要求就會失敗。舉例來說，如果您將允許的最大干擾動作設為 RESTART，則嘗試更新開機磁碟映像檔就會失敗，因為該更新作業需要替換執行個體，而這動作的干擾程度比重新啟動還要大。

這兩個選項都接受下列值：

值	說明	可以更新哪些執行個體屬性？
`REFRESH`	不會停止執行個體。	其他磁碟、執行個體中繼資料、標籤、標記
`RESTART`	會停止執行個體，然後重新啟動。	其他磁碟、執行個體中繼資料、標籤、標記、機型
`REPLACE`	(預設值)。根據「更換方法」選項更換執行個體。	儲存在執行個體範本或個別執行個體設定中的所有執行個體屬性

允許的最大干擾動作所造成的干擾情況不能小於最小動作。

自動推出更新時，系統會套用下列預設值：

預設的最小動作為 REPLACE。如要避免不必要的干擾，請將最小動作設為干擾程度較低的動作。
允許的最大干擾動作預設為 REPLACE。如果無法承受這類干擾，請將允許的最大干擾動作設為干擾程度較低的動作。

如要變更預設行為，請使用 Compute Engine API，在 MIG 資源中設定 updatePolicy.minimalAction 和 updatePolicy.mostDisruptiveAllowedAction 欄位，例如呼叫 regionInstanceGroupManagers.patch 方法。或者，您也可以透過 Google Cloud 控制台更新 MIG 時，選取特定的可用的 VM 更新動作。如要查看目前的設定，請參閱「取得 MIG 的屬性」。

如果更新作業需要執行干擾程度超出您允許範圍的動作，就會失敗。如果發生這種情況，您可以嘗試再次更新，並允許干擾程度較大的動作，或是選擇性更新執行個體。Compute Engine 會盡力驗證執行個體是否能以指定的中斷限制更新。但由於系統中同時進行變更，更新開始後情況可能會有所不同。如果特定執行個體的作業失敗，請列出執行個體錯誤來查看錯誤。

執行滾動式重新啟動或取代

滾動式重新啟動會停止並重新啟動所有執行個體，而滾動式取代則會根據取代方法選項取代所有執行個體。您可能基於下列原因，需要執行滾動式重新啟動或取代作業：

清理記憶體流失的問題。
重新啟動應用程式，讓它可以從新機器執行。
定期執行取代作業，來做為測試執行個體的最佳做法。
更新執行個體的作業系統映像檔，或是重新執行開機指令碼，以便更新軟體。

使用Google Cloud 控制台或 Google Cloud CLI 執行執行個體的滾動重新啟動或取代作業時，系統會在 MIG 中執行下列基礎動作。不過，如果您使用 REST，就必須在要求中設定這些欄位，才能觸發重新啟動或取代作業。

如果 updatePolicy.type 為 OPPORTUNISTIC，MIG 會將類型變更為 AUTOMATIC。
MIG 會更新每個執行個體的 versions.name。

如要執行輪流重新啟動或更換作業，請選取下列任一選項：

主控台

前往 Google Cloud 控制台的「Instance groups」(執行個體群組) 頁面。

前往「Instance groups」(執行個體群組) 頁面
選取含有要重新啟動或取代 VM 的代管執行個體群組。
按一下「重新啟動/替換 VM」。
在「作業」下方，選取「重新啟動」或「更換」。
- 如果選取「重新啟動」，請修改下列參數或使用預設值：
  - 無法使用的執行個體數量上限
  - 最短等待時間
- 如果選取「取代」，請按照下列步驟操作：
  1. 選擇是否要在替換執行個體時保留執行個體名稱。
  2. 指定下列參數或使用預設值：
如要啟動作業，請按一下「重新啟動 VM」或「取代 VM」。

gcloud

使用 restart 指令或 replace 指令。

下列指令會對區域 MIG 中的執行個體執行滾動式重新啟動或取代作業。如果是區域 MIG，請將 --zone=ZONE 標記替換為 --region=REGION。

如要一次重新啟動區域 MIG 中的一個執行個體，請執行下列步驟：

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --zone=ZONE

如要一次取代區域 MIG 中的一個執行個體，請按照下列步驟操作：

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME \
    --zone=ZONE

您可以藉由用於更新的相同選項 (例如 --max-surge 和 --max-unavailable)，進一步自訂上述兩個指令。

REST

使用下列其中一種方法傳送 PATCH 要求：

如果是區域 MIG，請使用 regionInstanceGroupManagers.patch 方法。
如果是區域 MIG，請使用 instanceGroupManagers.patch 方法。

您必須在要求主體中設定下列欄位。如果未指定這些欄位，要求可能仍會成功，但 MIG 不會執行重新啟動或取代作業。

將 updatePolicy.minimalAction 欄位設為 RESTART 或 REPLACE。
設定 versions.name 欄位。舉例來說，您可以使用時間戳記指定版本號碼，例如 v2-ddmmyyhhmm。
將 versions.instanceTemplate 欄位設為目前的範本網址。

如要重新啟動區域 MIG 中的所有執行個體，請發出下列要求。如要取代所有執行個體，請在同一要求中將 minimialAction 欄位設為 REPLACE。

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME

{
 "updatePolicy": {
  "minimalAction": "RESTART",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/CURRENT_INSTANCE_TEMPLATE",
   "name": "v2-1705499403"
  }
 ]
}

您可以使用與更新相同的選項進一步自訂要求，例如 maxSurge 和 maxUnavailable。

完成重新啟動或更換作業後，您可以列出 MIG 的 VM，並檢查每個 VM 的 versions.name 欄位，判斷哪些 VM 已重新啟動或更換。

其他的取代/重新啟動範例

針對所有 VM 執行滾動式重新啟動作業，一次處理兩個

下列指令會將群組中的所有 VM 重新啟動，一次處理兩個。請注意，該指令沒有指定任何新的執行個體範本。

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --max-unavailable=2 \
    [--zone=ZONE | --region=REGION]

盡快對所有 VM 執行滾動式重新啟動

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

針對所有 VM 執行滾動式取代作業，越快越好

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME  \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

保留執行個體名稱

如要在更新期間保留 VM 執行個體名稱，請將 replacementMethod 設為 RECREATE。您也必須將 maxUnavailable 設為大於 0，並將 maxSurge 設為 0。如果重新建立執行個體而非替換，更新作業需要較長時間才能完成，但更新後的執行個體會保留名稱。

如未指定取代方法，系統會使用 MIG 目前的 updatePolicy.replacementMethod 值。如果未設定，系統會使用 substitute 的預設值，將 VM 執行個體替換為名稱隨機產生的新執行個體。

gcloud

發出 rolling-action 指令時，請加入 --replacement-method=recreate 旗標。

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

REST

在區域或可用區 MIG 資源上呼叫 patch 方法。在要求主體中加入 updatePolicy.replacementMethod 欄位：

PATCH /compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME
{
    "updatePolicy": {
        "type": "PROACTIVE",
        "maxUnavailable": { "fixed": 5 },
        "replacementMethod": "RECREATE"
    },
    "versions": [ {
        "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE"
    } ]
}

在您提出要求後，您可以監視更新以得知更新何時完成。

更新地區代管執行個體群組

地區 MIG 包含散布在單一地區內的多個區域中的 VM 執行個體，這與區域 MIG (只包含單一區域中的執行個體) 正好相反。地區性 MIG 可讓您將執行個體分散在多個區域中，以便改善應用程式的可用性，同時支援各種極端的情況 (例如某個區域的執行個體都無法使用，或是整個執行個體群組都停止回應)。

更新區域 MIG 與更新區域 MIG 的方式相同，但有幾點例外，如下所述。當您啟動對地區 MIG 的更新作業時，Updater 永遠都會按照比例，平均地更新各個區域的執行個體。您無法選擇要優先更新哪個區域中的哪些執行個體，也無法只更新單一區域中的執行個體。

更新區域性 MIG 與區域性 MIG 的差異

地區性 MIG 具有下列預設更新值：

maxUnavailable=NUMBER_OF_ZONES
maxSurge=NUMBER_OF_ZONES

NUMBER_OF_ZONES 是與區域 MIG 相關聯的可用區數量。地區 MIG 的預設區域數為 3。但你可能會選取其他號碼。

如果您在指定更新時使用固定數量，該數量必須為 0，或是等於或大於與該地區 MIG 相關聯的區域數量。舉例來說，如果群組分散在三個區域中，您就無法將 maxSurge 設定為 1 或 2，因為 Updater 必須分別在這三個區域中建立一個額外的執行個體。

在更新要求中使用固定數量或百分比

如果您在更新要求中指定固定數量，系統就會把您指定的數目字除以地區 MIG 中的區域數，然後平均分散。舉例來說，如果您指定 maxSurge=10，Updater 就會拿 10 除以該地區的區域數，然後根據計算所得的數字來建立執行個體。如果執行個體的數量無法平均分配給每個區域，Updater 就會把多出來的執行個體新增到某個隨機選出來的區域。因此，如果要讓 10 個執行個體分散在 3 個區域中，其中 2 個區域會有 3 個執行個體，而剩下的那個區域就會有 4 個執行個體。同樣的邏輯也適用於初期測試更新的 maxUnavailable 和 targetSize 參數。

只有在 MIG 包含至少 10 個 VM 執行個體時，才能指定百分比。百分比的處理方式則視情況會稍有不同：

如果您指定要讓某個百分比的 VM 執行個體進行初期測試更新，Updater 就會嘗試將執行個體平均分散到各個區域。每個區域中的餘數會無條件進位或無條件捨入，但每個群組的總差異不會大於 1 個 VM 執行個體。舉例來說，如果某個 MIG 有 10 個執行個體，且目標大小為 25%，系統就會對 2 到 3 個 VM 執行個體進行更新作業。
如果您為更新選項 (例如 maxSurge 和 maxUnavailable) 指定百分比，系統就會分別為每個區域將餘數四捨五入。

後續步驟

瞭解如何查看 MIG 和代管執行個體的相關資訊。
瞭解如何建立執行個體範本。
瞭解如何使用映像檔系列和滾動式取代，更新 MIG 中所有 VM 的 OS 映像檔。

自動套用 MIG 中的 VM 設定更新 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

事前準備

Console

gcloud

REST

限制

啟動基本的滾動式更新作業

這項工作需要的權限

主控台

gcloud

REST

設定更新的選項

更新類型

可擴充的 pod 數量上限

無法使用的 pod 數量上限

最短等待時間

最少動作

允許的最大干擾動作

替換方法

其他更新範例

初期測試更新

啟動初期測試更新

這項工作需要的權限

主控台

gcloud

REST

將初期測試更新向前推進

主控台

gcloud

REST

監控更新

群組狀態

這項工作需要的權限

主控台

gcloud

REST

確認更新發布作業是否已完成

檢查代管執行個體群組是否穩定

目前對執行個體的動作

這項工作需要的權限

gcloud

REST

復原更新內容

gcloud

REST

停止更新

控制滾動式更新的速度

控制滾動式更新期間的中斷程度

執行滾動式重新啟動或取代

主控台

gcloud

REST

其他的取代/重新啟動範例

保留執行個體名稱

gcloud

REST

更新地區代管執行個體群組

更新區域性 MIG 與區域性 MIG 的差異

在更新要求中使用固定數量或百分比

後續步驟

自動套用 MIG 中的 VM 設定更新