將更新導入代管執行個體群組

代管執行個體群組 (MIG) 包含一或多個利用執行個體範本來控管的虛擬機器 (VM) 執行個體。如要更新代管執行個體群組中的執行個體，您可以利用 Managed Instance Group Updater 功能，把所有更新要求一起導入群組。

詳情請參閱執行個體群組。

Managed Instance Group Updater 能協助您將新版軟體部署至 MIG 中的執行個體，同時還能控制部署速度、服務受到干擾的程度，以及更新的範圍。Updater 提供兩個主要的優勢：

系統會根據您指定的規格自動發布更新，讓使用者在第一次提出要求之後就不必再輸入任何設定值。
您可以只針對一部分的執行個體發布更新，以達到測試的目的。

只要讓您能夠將新軟體部署到現有的代管執行個體群組內部，之後每次有新版本的軟體推出時，您就不必重新設定執行個體群組，或是重新連線負載平衡、自動調度資源或自動修復。如果沒有 Updater，要部署新版軟體的話，就必須建立具有新版軟體的代管執行個體群組 (這種方式每次都需要進行額外設定)，或由使用者逐一手動重新建立執行個體。這兩種方法操作時全程都需要大量的手動設定步驟。

事前準備

如要使用本指南中的指令列範例，請完成下列事項：
1. 安裝或更新至最新版的 gcloud 指令列工具。
2. 設定預設的地區和區域。
您擁有代管執行個體群組。
您擁有做為執行個體群組更新目標的執行個體範本。

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

滾動式更新是以逐一套用的方式更新群組中的所有執行個體。您可以控制滾動式更新的各種層面，例如要將多少個執行個體離線更新、執行個體的更新間隔、更新會影響全體或僅部分的執行個體等等。

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

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

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

主控台

前往 GCP Console 的「Instance Groups」(執行個體群組) 頁面。
前往「Instance groups」(執行個體群組) 頁面
選取您要更新的執行個體群組。
按一下頁面頂端的 [Rolling update] (滾動式更新)。
按一下 [Template] (範本) 下方的下拉式選單，然後選取要做為更新目標的新範本。
對於目標大小，請輸入「100%」來更新所有的執行個體。
(選用) 您可以切換設定選項，例如更新為主動式 (群組會主動替換執行個體) 還是隨機式 (群組不會主動替換執行個體，但會在系統透過其他方式替換執行個體時套用更新)。您也可以提供供應過度上限、無法使用數量的上限，以及最短等待時間。
按一下 [Update] (更新) 來開始更新。

gcloud

請使用 gcloud 指令列工具來執行 rolling-action start-update 指令：

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

其中：

[INSTANCE_GROUP] 是要更新的執行個體群組名稱。
[INSTANCE_TEMPLATE] 是做為執行個體群組更新目標的新執行個體範本。
這個執行個體群組的 [ZONE] 或 [REGION]。如果該執行個體群組為區域執行個體群組，請提供區域；如果為地區執行個體群組，請提供地區。

API

請在 API 中，對以下網址提出 PATCH 要求：

https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[MANAGED_INSTANCE_GROUP_NAME]

如果該執行個體群組是地區代管執行個體群組，請將 zones/[ZONE] 替換成 regions/[REGION]。

要求酬載包含：

做為該群組更新目標的執行個體範本。
要求的更新政策，以及其他更新選項。

以下範例是要在 API 中啟動更新的最低設定需求。

如果您沒有指定，maxSurge 和 maxUnavailable 屬性預設為 1 乘以受影響區域的數量，這代表 Updater 在更新期間，只會讓每個受影響區域有 1 個執行個體無法使用，且只會為每個區域建立 1 個額外的執行個體。

以下要求範例會把所有執行個體更新到新的執行個體範本。

{
  "instanceTemplate": "global/instanceTemplates/example-template",
  "updatePolicy": {
    "type": "proactive"
   }
 }

當您提出要求之後，即可監視更新作業以得知更新何時完成。

設定更新的選項

對於更複雜的更新，您可以為特定的更新要求設定其他選項。我們將在下方說明這些選項。

供應過度上限

請將 maxSurge 屬性設定為允許 Updater 在更新期間，暫時建立數量超出 targetSize 的新執行個體。舉例來說，如果您將 maxSurge 設定為 5，則代管執行個體群組會利用新的執行個體範本，建立最多超出目標大小 5 個的新執行個體。設定較高的 maxSurge 值可加快更新速度，但代價是會產生額外的執行個體，而我們會根據 Compute Engine 的價目表向您收取這些執行個體的費用。

如果您沒有設定 maxSurge 值，系統會採用預設值。對於區域代管執行個體群組，maxSurge 的預設值為 1。而對於地區代管執行個體群組，預設值則為 [NUMBER_OF_ZONES]，且 [NUMBER_OF_ZONES] 就是與地區代管執行個體群組相關聯的區域數目。

這個選項只有在搭配 REPLACE 最少動作時才有作用，但系統並不支援該選項與 RESTART 動作搭配使用。您可以指定固定數量，或是在代管執行個體群組至少有 10 個執行個體時指定百分比。如果您指定百分比，Updater 就會在必要時以無條件進位的方式來計算執行個體數量。

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

無法使用數量的上限

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

這個數量也包括因其他原因而無法使用的所有執行個體。舉例來說，如果執行個體群組正處於將規模調大的過程中，則建立中的執行個體可能會無法使用，因此這些執行個體就為計入 maxUnavailable 的數量中。您可以指定固定數量，或是在代管執行個體群組至少有 10 個執行個體時指定百分比。如果您指定百分比，Updater 就會在必要時以無條件捨去的方式來計算執行個體數量。

在區域代管執行個體群組中，maxUnavailable 的預設值為 1。而在地區代管執行個體群組中，[NUMBER_OF_ZONES] (已選取的區域數量) 的預設值為 3。

最短等待時間

請設定 minReadySeconds，以指定系統要等待多少時間之後，才會把新建立或重新啟動的執行個體視為已更新。請使用這個功能來控制更新的部署速率。計時器會在以下兩個條件皆符合時開始計時：

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

請注意，為了讓健康狀態檢查傳回健康狀態良好，Updater 將：

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

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

如果執行個體群組沒有健康狀態檢查，計時器就會在執行個體的狀態為 RUNNING 時開始計時。minReadySeconds 屬性的最大值為 3600 秒 (1 小時)。

最少動作

請設定最少動作屬性，以控制 Updater 為更新群組中的執行個體所必須執行的最少動作。例如，如果您將 REPLACE 設為最小動作，則所有受到影響的執行個體將會刪除，並取代成新的執行個體，無論是否需要。

設定最少動作可確保 Updater 至少會執行該動作。然而，如果 Updater 判斷您指定的最少動作不足以執行更新作業，就可能會執行干擾程度較大的動作。舉例來說，如果您將 RESTART 設為最少動作，Updater 就會嘗試重新啟動執行個體來執行更新作業。不過，如果更新作業需要某個干擾程度較大的動作才能完成，Updater 就會執行該動作。舉例來說，如果您要變更執行個體的作業系統，就必須要將執行個體重新啟動，好讓 Updater 能夠把執行個體群組中的執行個體替換成新的 VM 執行個體。

適用的動作有 REPLACE 或 RESTART：

RESTART：重新啟動實例 (會執行 stop 和 start 要求)。如果您的更新要求必須要替換執行個體才能變更成功 (舉例來說，當您要變更映像檔時，就必須要讓執行個體遭到刪除並取代)，Updater 就會強制執行 REPLACE。
REPLACE：刪除現有的執行個體，並利用目標範本建立新的執行個體。Updater 會建立具備所有新的執行個體屬性 (例如新的內部和外部 IP 位址) 的執行個體。

下圖說明這些選項會如何影響您的執行個體。

其他更新範例

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

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

舉例來說，如果您有 1000 個執行個體，且您執行了這項指令，Updater 就會在建立最多 100 個執行個體之後，才會開始移除執行舊執行個體範本的執行個體。

執行所有虛擬機器執行個體的滾動式更新，但同一時間最多只能建立超出目標大小 10% 的新執行個體

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

啟動初期測試更新

Instance Group Updater 功能可讓您執行初期測試更新，好讓您可以先針對隨機選擇的執行個體子集測試更新，再全面採用這個更新。

初期測試更新就是只會對執行個體群組中的部分執行個體執行的更新作業。初期測試更新可讓您對執行個體子集測試新的功能或升級，而非讓您對所有執行個體進行可能會干擾服務的更新作業。如果更新並不順利，您只需要復原小部分的執行個體，進而將對使用者的干擾降到最低。從伺服器的觀點來看，初期測試更新與標準的滾動式更新是一樣的，唯一的不同之處在於，初期測試更新要更新的執行個體數量，少於執行個體群組中的執行個體總數。如同標準滾動式更新，初期測試更新會對受影響的執行個體造成干擾，亦即受影響的執行個體會在更新期間遭到刪除並由新 VM 執行個體取代。

如何啟動初期測試更新：

您最多可以指定兩個版本的執行個體範本，通常一個是用於進行初期測試的新執行個體範本，另一個則是剩下的執行個體目前所用的執行個體範本。舉例來說，您可以指定有 20% 的執行個體是根據 new-instance-template 建立的，而剩下的執行個體則繼續根據 old-instance-template 來執行。您同一時間無法指定超過兩個的執行個體範本。
您必須要指定初期測試版本的目標大小 (targetSize)。如果您省略初期測試版本的目標大小，就無法啟動初期測試更新。舉例來說，如果您指定要把 10% 的執行個體用來執行初期測試，剩下 90% 就不會受到影響，且會使用目前的執行個體範本。

主控台

前往 GCP Console 的「Instance Groups」(執行個體群組) 頁面。
前往「Instance groups」(執行個體群組) 頁面
選取您要更新的執行個體群組。
按一下頁面頂端的 [Rolling update] (滾動式更新)。
按一下 [Add template] (新增範本)，然後選擇要進行初期測試的新執行個體範本。
在「Target size」(目標大小) 下方，輸入您要用來對新的執行個體範本進行初期測試的執行個體數量百分比，或是固定的執行個體數量。
(選用) 您可以切換設定選項，例如更新為主動式 (群組會主動替換執行個體) 還是隨機式 (群組不會主動替換執行個體，但會在系統因其他理由建立執行個體時套用更新)。您也可以提供供應過度上限、無法使用數量的上限，以及最短等待時間。
按一下 [Update] (更新) 來開始更新。

gcloud

請利用 gcloud 指令列工具來提供目前的範本和新的範本，以便明確表示這兩個範本分別會有多少執行個體採用：

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

其中：

[CURRENT_TEMPLATE] 是執行個體群組目前正在執行的範本。
[NEW_TEMPLATE] 是您要進行初期測試的新範本。
[SIZE] 是您要套用此更新的執行個體數量或百分比。您必須將 target-size 屬性套用至 --canary-version 範本。如果執行個體群組至少有 10 個執行個體，您就只能設定百分比。
這個執行個體群組的 [ZONE] 或 [REGION]。如果該執行個體群組為區域執行個體群組，請提供區域；如果為地區執行個體群組，請提供地區。

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

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

API

請在 API 中，對以下 URI 提出 PATCH 要求：

https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/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_TEMPLATE]"
  }
 ]
}

其中：

[NEW_TEMPLATE] 是您要進行初期測試的新範本名稱。
[NUMBER|PERCENTAGE] 是您要用來為該更新進行初期測試的執行個體固定數量或百分比。如果執行個體群組至少有 10 個執行個體，您就只能設定百分比。否則，請提供固定數量。
[CURRENT_TEMPLATE] 是執行個體群組目前正在執行的範本名稱。

將初期測試更新向前推進

當您執行初期測試更新之後，即可決定是要讓整個執行個體群組都採用這個更新，還是要復原。

主控台

前往 GCP Console 的「Instance Groups」(執行個體群組) 頁面。
前往「Instance groups」(執行個體群組) 頁面
選取您要更新的執行個體群組。
按一下頁面頂端的 [Rolling update] (滾動式更新)。
在「Template」(範本) 下方，將初期測試範本的目標大小更新為「100%」，以便將範本向前滾動至所有的執行個體。或者，您可以使用初期測試範本取代主要範本，並將目標大小設定為 100%。接著，您可以將第二個範本欄位一併移除。
按一下 [Update] (更新) 來開始更新。

gcloud

如果您對初期測試更新的結果感到滿意，請將該更新向前推進，方法是提出相同的更新要求，但只設定 version，並去掉 --canary-version：請利用 gcloud 指令列工具執行下列指令：

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

API

請在 API 中，對以下 URI 提出 PATCH 要求：

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

請在要求主體中，利用 version 來指定新的執行個體範本，並把舊的執行個體範本從要求主體中去除。請去除目標大小規格，以便對 100% 的執行個體推出這個更新。舉例來說，您的要求主體看起來應該類似：

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

請將 [NEW_TEMPLATE] 替換成您要向前推進的新執行個體範本名稱。

啟動隨機式或主動式更新

根據預設，利用 gcloud 指令列工具執行的更新作業是主動式的，而在 API 中啟動的更新作業則為隨機式的。

對於主動式更新，Compute Engine 會在必要時，主動為會將所要求更新套用至執行個體的動作排定執行時程。在許多情況下，這通常代表系統會主動刪除並重新建立執行個體。

但如果主動式更新的干擾程度可能會過大，您也可以選擇執行隨機式更新。只有在您針對選定的執行個體手動啟動更新時，或是在新的執行個體是由代管執行個體群組所建立時，隨機式更新才適用。而代管執行個體群組只會在受到另一個服務 (例如自動配置器) 調整大小時，或是遭到某個使用者手動調整大小時，才會建立新的執行個體。Compute Engine 不會主動啟動會套用隨機式更新的要求。

隨機式更新在某些情況下是很有用的，因為您可不想造成可避免的系統不穩定問題。舉例來說，如果您有個可視需要套用、完全不緊急的非重要更新，且您有個資源會遭到系統主動地自動調度的代管執行個體群組，請執行隨機式更新作業，好讓 Compute Engine 不會主動拆散您現有的執行個體來套用更新。

如要選擇採用隨機式或主動式的更新，請利用 gcloud 指令列工具或 API，將類型屬性設定為 OPPORTUNISTIC 或 PROACTIVE。

主控台

前往 GCP Console 的「Instance Groups」(執行個體群組) 頁面。
前往「Instance groups」(執行個體群組) 頁面
選取您要更新的執行個體群組。
按一下頁面頂端的 [Rolling update] (滾動式更新)。
在「Template」(範本) 下方，選擇要做為執行個體群組更新目標的範本，然後選取該範本的目標大小。
在「Update mode」(更新模式) 下方，選擇 [Opportunistic] (隨機) 或 [Proactive] (主動) 更新。
按一下 [Update] (更新) 來開始更新。

gcloud

請利用 gcloud 指令列工具執行下列指令：

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

API

請在要啟動更新的要求酬載中，將 type 屬性納入您的 updatePolicy：

{
"updatePolicy": {
  "type": "PROACTIVE" # Performs a proactive update
},
"versions": [{
  "instanceTemplate": "global/instanceTemplates/[NEW_TEMPLATE]",
  }]
}

其中 [NEW_TEMPLATE] 是您要進行初期測試的新範本名稱。如果您要進行隨機式更新，請將 PROACTIVE 替換成 OPPORTUNISTIC。

更新已選取的執行個體

當您要啟動隨機式更新時，您必須等待，讓 Compute Engine 在機會到來時發布更新。不過，如果您想進一步掌控發布作業，也能以手動的方式，立刻針對代管執行個體群組中的特定執行個體啟動更新作業。

如果您手動啟動更新作業，就能夠：

選取您要更新的執行個體。
在套用更新時，盡可能讓完成更新作業所需的干擾降到最低。舉例來說，如果您只要更新中繼資料，可能就不必非得重新啟動執行個體才能完成更新。手動啟動更新時，系統會自動執行最小的必要動作。
強制執行個體重新啟動或重新建立 (即使套用更新不一定要執行這類動作)。舉例來說，就算您只是更新了 VM 的中繼資料，但因為訪客軟體在 VM 啟動時必須挑選新的中機資料，因此您可能會想要重新啟動 VM。
在完成更新所需的干擾程度超過您的承受範圍時，禁止執行該更新作業。
不受 maxSurge 和 maxUnavailable 條件約束對於發布作業的限制，立刻對所有已選取的執行個體執行更新作業。

最少動作和允許的最大干擾動作

視更新的性質而定，更新作業可能會干擾執行個體的狀態。舉例來說，如要變更執行個體的機器類型，就必須重新啟動 VM，而要變更執行個體的開機映像檔的話，就必須刪除並取代執行個體。

您可以利用 minimal-action 和 most-disruptive-allowed-action 標記來控制干擾程度：

minimal-action 可讓您強制執行干擾程度超出必要範圍的動作。
most-disruptive-allowed-action 可讓您在更新的干擾程度超出您的承受範圍時，禁止執行該更新作業。

當您要更新已選取的執行個體時，上述的兩個標記都接受下列動作：

動作	說明	可以更新哪些執行個體屬性？
`NONE`	完全不會干擾執行個體。	無。
`REFRESH`	不會停止執行個體。	次要磁碟、執行個體中繼資料、標籤。
`RESTART`	會停止執行個體，然後重新啟動。	機器類型。
`REPLACE`	會刪除執行個體，然後重新建立。	所有儲存在執行個體範本中的執行個體屬性。

minimal-action 的預設值為 NONE。如果您的更新作業需要執行干擾程度超出您利用此標記所設定的動作，Compute Engine 就會執行必要的動作來進行更新。

most-disruptive-allowed-action 的預設值為 REPLACE。如果您的更新作業需要執行干擾程度超出您利用此標記所設定的動作，更新要求就會失敗。舉例來說，如果您將「重新啟動」設定為允許的最大干擾動作，則嘗試更新開機磁碟映像檔的更新就會失敗，因為該更新作業需要重新建立執行個體，而這動作的干擾程度比重新啟動的干擾程度還要大。

您可以利用 gcloud 工具或 API 來更新已選取的執行個體。

gcloud

請在啟動隨機式更新之後，利用 update-instances 子指令將更新套用至特定的執行個體。

gcloud beta compute instance-groups managed update-instances [INSTANCE_GROUP] \
    --instances [INSTANCE_NAMES] \
    --most-disruptive-allowed-action [DISRUPTION_LEVEL] \
    --minimal-action [DISRUPTION_LEVEL]

其中：

[INSTANCE_GROUP] 是擁有待處理更新的執行個體群組名稱。
[INSTANCE_NAMES] 是要立刻更新的執行個體清單。
[DISRUPTION_LEVEL] 是最小或最大干擾程度：NONE、REFRESH、RESTART 或 REPLACE。
- minimal-action 的預設值為 NONE。
- most-disruptive-allowed-action 的預設值為 REPLACE。

如果您需要等待所有指定的執行個體都更新完畢，請查看群組的狀態，並等到群組進入穩定狀態為止。

API

請在啟動隨機式更新之後，向 Beta 版的 regionInstanceGroupManagers.applyUpdatesToInstances 方法建構 POST 要求。對於區域代管執行個體群組，請使用區域的 instanceGroupManagers.applyUpdatesToInstances 方法。

POST https://compute.googleapis.com/compute/beta/projects/[PROJECT]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/applyUpdatesToInstances
{
  "instances": "zones/[ZONE]/instances/[INSTANCE_NAME]","zones/[ZONE]/instances/[INSTANCE_NAME]"
  "minimalAction": [DISRUPTION_LEVEL],
  "mostDisruptiveAllowedAction": [DISRUPTION_LEVEL]
}

其中：

[INSTANCE_GROUP_NAME] 是擁有待處理更新的執行個體群組名稱。
[ZONE] 是要立刻更新的執行個體所在區域。
[INSTANCE_NAME] 是要立刻更新的執行個體名稱。
[DISRUPTION_LEVEL] 是最小或最大干擾程度：NONE、REFRESH、RESTART 或 REPLACE。
- minimalAction 的預設值為 NONE。
- mostDisruptiveAllowedAction 的預設值為 REPLACE。

applyUpdatesToInstances 與其他的代管執行個體群組方法類似，都是意圖式的，這代表該方法會傳回作業回應。在作業狀態變成為 DONE 之後，listManagedInstances 會包含 currentAction 欄位已變更成 REFRESHING、RESTARTING 或 RECREATING 的執行個體清單。如果作業失敗 (例如因為同時有不同的作業要變更群組)，系統會把失敗記錄在 lastAttempt.errors 欄位中。

如果您需要等待所有指定的執行個體都完成更新，請查看群組的狀態，並等到群組進入穩定狀態為止。

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

您也可以利用 restart 或 replace 指令，對代管執行個體群組中的 VM 執行個體進行滾動式重新啟動作業或滾動式取代作業。就跟 start-update 指令類似，您可以為重新啟動作業或取代作業指定任何設定選項。滾動式重新啟動作業或取代作業不會改變執行個體群組的任何設定，包括執行個體範本。它只會使用您選擇的方式重新整理群組中的執行個體。

為何要滾動式取代或滾動式重新啟動的原因有許多種。舉例來說，您偶爾可能會想要重新整理 VM 執行個體：

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

如何執行取代作業，讓所有執行個體都遭到刪除，並被新的執行個體取代：

主控台

前往 GCP Console 的「Instance Groups」(執行個體群組) 頁面。
前往「Instance groups」(執行個體群組) 頁面
選取您要更新的執行個體群組。
按一下頁面頂端的 [Rolling restart/replace] (輪動式重新啟動/取代)。
選擇您要重新啟動，還是要取代執行個體。如果您選擇重新啟動，系統就會在執行個體上執行 stop 和 start 方法，而取代作業會主動刪除並建立執行個體。
(選用) 您可以切換設定選項，例如供應過度上限、無法使用數量的上限，以及最短等待時間。
按一下 [Restart] (重新啟動) 或 [Replace] (取代) 按鈕來開始更新。

gcloud

gcloud compute instance-groups managed rolling-action replace [INSTANCE_GROUP]

這個指令會取代代管執行個體群組中的所有執行個體，一次處理一個。如果完全取代的干擾程度過大，您可以改為指定滾動式重新啟動；這種方法不會刪除任何執行個體，只會把每個執行個體都重新啟動而已。

gcloud compute instance-groups managed rolling-action restart [INSTANCE_GROUP]

您可以藉由用於更新的相同選項 (例如 maxSurge、maxUnavailable、min-ready)，進一步自訂上述兩個指令。

API

請在 API 中，為群組提出 PATCH 要求，並設定主動式 updatePolicy，其中的 minimalAction 可以是 RESTART 或 REPLACE，全視您要執行滾動式取代 (每個執行個體都會遭到刪除，並被新的新執行個體取代)，還是滾動式重新啟動 (每個執行個體都會停止並重新啟動) 而定。無論您是選擇 RESTART 還是 REPLACE，都必須提供 versions.instanceTemplate 和 versions.name 屬性 (例如 v2) 以觸發動作。

滾動式取代作業看起來會像是：

PATCH https://compute.googleapis.com/compute/v1/projects/myproject/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

{
 "updatePolicy": {
  "minimalAction": "REPLACE",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/example-template",
   "name": "v2"
  }
 ]
}

而滾動式重新啟動作業會像是：

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/example-template",
   "name": "v2"
  }
 ]
}

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

針對所有 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 執行個體，這與區域代管執行個體群組 (只包含單一區域中的執行個體) 正好相反。地區代管執行個體群組能讓您將自己的執行個體分散在多個區域中，以便改善應用程式的可用性，同時支援各種極端的情況 (例如某個區域的執行個體都無法使用，或是整個執行個體群組都停止回應)。

利用 Instance Group Updater 功能來更新地區代管執行個體群組，與針對區域代管執行個體群組執行更新作業的方法是相同的，但有幾點例外，如下所述。當您啟動對地區執行個體群組的更新作業時，Updater 永遠都會按照比例，平均地更新各個區域的執行個體；您無法選擇要優先更新哪個區域中的哪些執行個體，也無法只更新單一區域中的執行個體。

更新地區代管執行個體群組與更新區域代管執行個體群組之間的差異

在您啟動地區代管執行個體群組的更新作業之前，必須要瞭解這與區域代管執行個體群組的更新作業之間有幾點不同之處：

地區代管執行個體群組的預設更新參數是 maxUnavailable=[NUMBER_OF_ZONES] 和 maxSurge=[NUMBER_OF_ZONES]，其中 [NUMBER_OF_ZONES] 是您為該地區代管執行個體群組所選取的區域數量，預設值為 3。
如果您在指定更新時使用固定數量，該數量必須為 0，或是等於或大於與該地區代管執行個體群組相關聯的區域數量。舉例來說，如果執行個體群組分散在三個區域中，您就無法將 maxSurge 設定為 1 或 2，因為 Updater 必須分別在這三個區域中建立一個額外的執行個體。

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

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

如果您的代管執行個體群組至少有 10 個 VM 執行個體，您就只能指定百分比。百分比的處理方式則視情況會稍有不同：

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

監控更新

當您啟動滾動式更新之後，更新作業需要花點時間才能完成。您可以監控更新作業的進度，方法是查看代管執行個體群組的 status，或是查看代管執行個體群組中每個執行個體的 currentAction。

群組狀態

Compute Engine 會在群組層級將值填入名為 status 的唯讀欄位，該欄位包含 versionTarget.isReached 標記和 isStable 標記。您可以利用 gcloud 工具或 API 來存取這些標記。

如要確認執行個體群組的更新是否已執行完畢，請查看 status.versionTarget.isReached==true。如要確認群組中的所有執行個體是否都在執行中，且健康狀態良好 (也就是說，每個代管執行個體的 currentAction 都是 NONE)，請查看狀態值是否為 status.isStable==true。請注意，代管執行個體群組的穩定性取決於超出 Updater 處理範圍的群組設定；舉例來說，如果您的群組可自動調度資源，且目前正在擴充資源，狀態值就會由於自動配置器作業的緣故而顯示為 isStable==false。

您也可以利用主控台，查看目前正在更新中和計劃要更新的執行個體數量。

主控台

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

前往 GCP Console 的「Instance Groups」(執行個體群組) 頁面。
前往「Instance groups」(執行個體群組) 頁面
選取要監控的執行個體群組。執行個體群組的「Overview」(總覽) 頁面會顯示每個執行個體使用的範本。
如要檢視詳細資料，請按一下 [Details] (詳細資料) 分頁標籤。

「Details」(詳細資料) 頁面會針對每個執行個體範本顯示目前正在更新中和計劃要更新的執行個體數量，還會顯示更新參數。

gcloud

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

gcloud 工具會傳回執行個體群組的詳細資訊，包括 status.versionTarget.isReached 和 status.isStable 欄位。

API

請在 API 中，對以下 URI 提出 POST 要求：

POST https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/get

如果該執行個體群組是地區代管執行個體群組，請將 zones/[ZONE] 替換成 regions/[REGION]。

API 會傳回執行個體群組的詳細資訊，包括 status.versionTarget.isReached 和 status.isStable 欄位。

status.versionTarget.isReached (Beta 版)

當群組中的所有 VM 執行個體都已經是目標版本，或是正在建立成目標版本時，就代表更新已發布完畢。在已全面發布的情況下，所有執行個體都將設為使用新的執行個體範本。而在部分發布的情況下，系統會根據不同執行個體範本之間的指定拆分目標值來設定執行個體。

只要查看 instanceGroupManagers (或 regionInstanceGroupManagers) 資源的 status.versionTarget.isReached 欄位值，即可確認更新是否已發布完畢。

如果所有 VM 執行個體都已經是目標版本，或是正在建立成目標版本 (versions[])，status.versionTarget.isReached 就會是 true。
但在至少有一個 VM 尚未使用目標版本 (versions[]) 時，status.versionTarget.isReached 會是 false。或者，在初期測試更新期間，當使用目標版本 (versions[].instanceTemplates) 的 VM 數量與該更新的目標大小 (versions[].targetSize) 不相符時，status.versionTarget.isReached 就會是 false。

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

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

status.isStable

如要確認代管執行個體群組是否正在執行中，且健康狀態良好，請查看 instanceGroupManagers 或 regionInstanceGroupManagers 資源的 status.isStable 欄位值。

您也可以利用 gcloud 指令列工具來執行搭配 --stable 標記的 wait-until 指令來等待，直到該群組的 status.isStable 變成 true 為止：

gcloud beta compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --stable \
    [--zone [ZONE] | --region [REGION]]

當 status.isStable 為 false 時，代表變更已生效、待處理，或是系統正在修改代管執行個體群組。

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

在代管執行個體群組中，沒有任何執行個體遭到任何類型的變更，且所有執行個體的 currentAction 都顯示 NONE。
代管執行個體群組中的執行個體沒有任何待處理的變更。
系統並沒有在修改這個代管執行個體群組。

修改代管執行個體群組的方式有許多種，例如：

您提出要求，以便發布新的執行個體範本。
您提出要求，以便建立、刪除，或更新群組中的執行個體，或是調整這些執行個體的大小。
自動配置器要求調整群組的大小。
自動修復程式資源正在取代代管執行個體群組中一或多個健康狀態不良的執行個體。
在地區代管執行個體群組中，有部分執行個體正遭到重新分配。

當所有動作都執行完畢之後，該代管執行個體群組的 status.isStable 會再次變成 true。

執行個體目前在執行的動作

如要查看代管執行個體群組中的每個執行個體正在執行的 currentAction，以及每個執行個體的 status，請使用 gcloud 指令列工具或 API。

完成該工作所需的權限

如要執行該工作，您必須擁有以下權限。

執行個體群組的 compute.instanceGroupManagers.get 權限
執行個體群組的 compute.instanceGroupManagers.list 權限

gcloud

gcloud compute instance-groups managed list-instances [INSTANCE_GROUP_NAME] [--filter="zone:([ZONE])" | --filter="region:([REGION])"]

gcloud 會傳回執行個體群組中的執行個體清單，以及每個執行個體的狀態和目前在執行的動作，例如：

NAME               ZONE           STATUS    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

API

請在 API 中，對 regionInstanceGroupManagers.listManagedInstances 方法提出 POST 要求：對於區域代管執行個體群組，請使用 instanceGroupManagers.listManagedInstances 方法。

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name/listManagedInstances

API 會傳回群組的執行個體清單，其中包含每個執行個體的 instanceStatus 和 currentAction。

{
 "managedInstances": [
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  }
 ]
}

對於代管執行個體群組中的每個執行個體，執行個體的狀態會由自己的 instanceStatus 欄位來描述。如要查看有效的 instanceStatus 欄位值清單，請參閱檢查執行個體狀態。

如果執行個體正在經歷某種類型的變更，系統就會把下列某個動作填入 currentAction 欄位，以協助您追蹤變更的進度。否則，currentAction 欄位就會是 NONE。

可能的 currentAction 值：

ABANDONING：系統正在將該執行個體從代管執行個體群組中移除。
CREATING：系統正在建立該執行個體。
CREATING_WITHOUT_RETRIES：系統正在建立該執行個體，且不會重試；如果系統在首次嘗試建立執行個體時失敗，代管執行個體群組就不會再次嘗試取代該執行個體。
DELETING：系統正在刪除該執行個體。
RECREATING：系統已刪除該執行個體，目前正在取代該執行個體中。
REFRESHING：系統正在將該執行個體從它目前的目標集區中移除，並將該執行個體讀入目前的目標集區清單中 (該清單可能會與現有的目標集區相同或不同)。
RESTARTING：系統正在使用 stop 和 start 方法重新啟動該執行個體。
VERIFYING：系統已建立該執行個體，目前正在驗證該執行個體中。
NONE：系統目前沒有針對該執行個體執行任何動作。

將更新復原

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

舉例來說，下列指令會盡快將復原更新：

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

請將 [OLD_INSTANCE_TEMPLATE] 替換成做為復原目標的執行個體範本名稱。

請在 API 中，對以下 URI 提出 PATCH 要求：

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

如果該執行個體群組是地區代管執行個體群組，請將 zones/[ZONE] 替換成 regions/[REGION]。

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

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

如果這個地區代管執行個體群組的執行個體不到 10 個，您就必須在 maxUnavailable 中使用固定值，並將該值設定為群組中的執行個體數量：

{ "updatePolicy":
  {
    "maxUnavailable":
    {
      "fixed": [NUMBER_OF_INSTANCES_IN_GROUP]
    }
  },
 "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/[OLD_TEMPLATE]" # Old instance template
    }
   ]
}

Instance Group Updater 服務會把上述要求視為一般的更新要求，因此在本文件中所述的所有更新選項，都能在您的要求中使用。

控制更新速度

根據預設，當您提出更新要求時，服務就會盡快執行更新作業。如果您不確定自己要不要全面套用更新，或是只想測試一下變更，您可利用下列方法來控制更新的速度。

啟動初期測試更新，而非全面更新。
設定較大的 minReadySeconds 值。當您設定這個值之後，服務就會先等待這個秒數的時間，才會把執行個體視為已更新完畢，然後繼續更新下一個執行個體。
啟用健康狀態檢查，讓服務會先等待應用程式啟動並回報健康狀態良好之後，才會把執行個體視為已更新完畢，然後繼續更新下一個執行個體。
設定較小的 maxUnavailable 和 maxSurge 值，這可確保系統一次只會更新少數的執行個體。
針對特定的執行個體來手動啟動更新，以便立刻更新這些執行個體。

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

停止更新

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

如要把更新從主動式變更成隨機式，請執行下列指令：

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 工具會傳回回應，其中包含執行個體群組中的執行個體清單，以及每個執行個體目前的狀態：

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

在以上範例中，系統已經更新兩個執行個體。

接著，提出要求來執行新的「更新」，但傳遞已更新的執行個體數目來做為目標大小：
```
gcloud compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=my-old-template \
    --canary-version template=my-new-template,target-size=2 \
    [--zone [ZONE] | --region [REGION]]
```
對 Updater 服務來說，這個更新作業看來「已完成」，因此不會再更新任何執行個體，進而有效地停止了更新。

代管執行個體群組的版本與 instanceTemplate 屬性之間的關係

Google 建議您利用 versions 欄位來設定代管執行個體群組的執行個體範本。

舊版的 instanceTemplate 欄位在功能上與 versions 欄位重疊，因為這兩個欄位都可讓您指定要讓代管執行個體群組使用哪個執行個體範本來建立新的執行個體。不過只有 versions 欄位能讓您指定較進階的兩個範本 (初期測試) 設定。

即使我們建議您改為只使用 versions 欄位，但為了回溯相容性，代管執行個體群組仍會繼續支援設定最高層級的 instanceTemplate 欄位。同時使用最高層級的 instanceTemplate 欄位和 versions 欄位，會導致模稜兩可與混淆的情況發生。

如果您在呼叫 update() 或 patch() 方法時，同時指定 instanceTemplate 欄位與 versions 欄位，就可能會發生下列三種情況：

您把這兩個欄位都設定成相同的值。

這是有效的要求，不會造成模稜兩可的情況，且系統會把新的執行個體範本套用至代管執行個體群組。

舉例來說，在下列要求中，最高層級的 instanceTemplate 和 versions 欄位會指定同一個執行個體範本，且這個範本與代管執行個體群組中目前的範本不相同。代管執行個體群組將會更新為新的執行個體範本：
```
{
 "instanceTemplate": "global/instanceTemplates/new-template",
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/new-template"
  }
 ],
 "updatePolicy": {
   "type": "PROACTIVE"
 }
}
```
您為這兩個欄位設定的值並不相符，且其中只有一個值與代管執行個體群組中目前的執行個體範本不相同。

這是有效的要求，系統會將不同於目前設定的欄位視為預期的值。舉例來說，您可以呼叫 get() 方法，變更這兩個欄位中的其中一個，然後只搭配那個已變更欄位來呼叫 update()：
```
{
 "instanceTemplate": "global/instanceTemplates/current-template",
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/new-template"
  }
 ],
 "updatePolicy": {
   "type": "PROACTIVE"
 }
}
```
您把這兩個欄位設定成不相符的值，且這兩個值都與代管執行個體群組中目前的執行個體範本不相同。

這是無效的設定，會讓系統因要求沒有明確意圖而傳回錯誤。
```
{
 "instanceTemplate": "global/instanceTemplates/new-template",
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/a-different-new-template"
  }
 ],
 "updatePolicy": {
   "type": "PROACTIVE"
 }
}
```

`versions` 欄位、`instanceTemplate` 欄位，以及 `get()` 方法

如果您只指定一個執行個體範本，無論是透過最高層級的 instanceTemplate 欄位或 versions 欄位來指定，或是同時透過這兩個欄位來指定，get() 方法都會在回應中傳回這兩個欄位。這會讓新的 versions 欄位有回溯相容性。只要您在這兩個欄位中的任何一個指定單一執行個體範本，get() 在 instanceTemplate 欄位中傳回的內容就不會改變。

如果您在 versions 欄位指定了兩個執行個體範本，get() 方法傳回的最高層級 instanceTemplate 欄位就會是空白的。目前沒有任何方法可在最高層級的 instanceTemplate 欄位中明確地表示初期測試 (雙執行個體範本) 的設定，因此這個欄位不會在初期測試更新期間使用。

`versions` 欄位和 `setInstanceTemplate()` 方法

為了回溯相容性，setInstanceTemplate() 方法的行為會與先前的相同，讓您能變更代管執行個體群組用來建立新執行個體的範本。當您呼叫這個方法時，系統會以您用 setInstanceTemplate() 方法所指定的執行個體範本覆寫 versions 欄位。

setInstanceTemplate() 方法也會把 updatePolicy 設定為 OPPORTUNISTIC。這能避免讓代管執行個體群組主動部署您沒有在 versions 欄位中明確指定的執行個體範本。

後續步驟

進一步瞭解執行個體群組。
進一步瞭解執行個體範本。

事前準備

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

主控台

gcloud

API

設定更新的選項

供應過度上限

無法使用數量的上限

最短等待時間

最少動作

其他更新範例

啟動初期測試更新

主控台

gcloud

API

將初期測試更新向前推進

主控台

gcloud

API

啟動隨機式或主動式更新

主控台

gcloud

API

更新已選取的執行個體

最少動作和允許的最大干擾動作

gcloud

API

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

主控台

gcloud

API

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

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

更新地區代管執行個體群組與更新區域代管執行個體群組之間的差異

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

監控更新

群組狀態

主控台

gcloud

API

status.versionTarget.isReached (Beta 版)

status.isStable

執行個體目前在執行的動作

完成該工作所需的權限

gcloud

API

將更新復原

控制更新速度

停止更新

代管執行個體群組的版本與 instanceTemplate 屬性之間的關係

versions 欄位、instanceTemplate 欄位，以及 get() 方法

versions 欄位和 setInstanceTemplate() 方法

後續步驟

傳送您對下列選項的寶貴意見...

`versions` 欄位、`instanceTemplate` 欄位，以及 `get()` 方法

`versions` 欄位和 `setInstanceTemplate()` 方法