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

代管執行個體群組包含一或多個使用執行個體範本控制的虛擬機器執行個體。若要更新代管執行個體群組中的執行個體，您可以使用 Managed Instance Group Updater 功能對整個群組提出更新要求。

如要進一步瞭解執行個體群組，請參閱執行個體群組總覽。

Managed Instance Group Updater 可讓您輕鬆地將新版軟體部署至您的代管執行個體群組中的執行個體，並能控制部署速度、服務中斷程度，以及更新的範圍。Updater 有兩個主要優點：

自動針對您的規則推出更新，使用者在提出初始要求後無須輸入內容。
您可以執行部分允許進行初期測試的推出項目。

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

事前準備

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

啟動基本滾動式更新程序

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

以下為進行滾動式更新的須知：

更新是基於意圖的。 當您提出初始更新要求時，API 會傳回成功回應來確認要求有效，但這不表示更新已順利完成。您必須查看代管執行個體群組的狀態，以判斷更新是否已成功部署。
Instance Group Updater API 是陳述式 API。API 預期會收到一項要求來指定代管執行個體群組所需的後置更新組態，而非明確的函式呼叫。
Updater 功能支援代管執行個體群組中最多兩個版本的執行個體範本。這表示您可以為您的代管執行個體群組指定兩個不同的執行個體範本版本，這對執行初期測試更新很有幫助。

如要啟動會將更新套用到群組中所有執行個體上的基本滾動式更新，請依照下列指示進行。

主控台

前往 GCP 主控台中的「執行個體」群組頁面。
前往「執行個體」群組頁面
選取您要更新的執行個體群組。
按一下頁面頂端的 [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 中，對以下 URL 提出 PATCH 要求：

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

如果執行個體是地區代管執行個體群組，請以 regions/[REGION] 取代 zones/[ZONE]。

要求酬載包含：

要更新群組的執行個體範本。
要求及其他更新選項的更新政策。

以下範例是在 API 中起始更新的最低設定需求。

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

本例要求將全部 (100%) 的執行個體更新為新的執行個體範本。

{
  "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 要求)。請注意，如果您的更新要求需要取代執行個體才能執行變更 (例如，必須刪除並取代執行個體，才會變更映像檔)，則會強制執行 REPLACE。
REPLACE：刪除現有的執行個體，並利用目標範本建立新的執行個體。Updater 會建立一個全新的執行個體，具備所有新的執行個體屬性，例如新的內部與外部 IP 位址。

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

其他更新範例

以下為含常見配置選項的指令列範例。

執行所有虛擬機器執行個體的滾動式更新，但一次建立最多 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 執行個體取代。

如何啟動初期測試更新：

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

主控台

前往 GCP 主控台中的「執行個體」群組頁面。
前往「執行個體」群組頁面
選取您要更新的執行個體群組。
按一下頁面頂端的 [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://www.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] 是執行個體群組目前正在執行的範本名稱。

向前滾動初期測試更新

在執行初期測試更新後，您可以決定要對 100% 的執行個體群組進行更新，或是復原。

主控台

前往 GCP 主控台中的「執行個體」群組頁面。
前往「執行個體」群組頁面
選取您要更新的執行個體群組。
按一下頁面頂端的 [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://www.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 主控台中的「執行個體」群組頁面。
前往「執行個體」群組頁面
選取您要更新的執行個體群組。
按一下頁面頂端的 [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] 是您要初期測試的新範本名稱。如果您要機會式更新，請以 OPPORTUNISTIC 取代 PROACTIVE。

更新選取的執行個體

如要啟動機會式更新，您必須等候 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://www.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 主控台中的「執行個體」群組頁面。
前往「執行個體」群組頁面
選取您要更新的執行個體群組。
按一下頁面頂端的 [滾動式重新啟動/取代]。
選擇要重新啟動或取代執行個體。如果重新啟動，就會在執行個體上執行 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://www.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://www.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"
  }
 ]
}

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

執行所有虛擬機器的滾動式重新啟動，一次兩個

此指令會重新啟動執行個體群組內的所有虛擬機器，一次兩個。請注意，系統不會指定任何新的執行個體範本。

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

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

地區代管執行個體群組包含分布在該地區內多個區域的虛擬機器執行個體，這與只包含一個區域中執行個體的區域代管執行個體群組相反。地區代管執行個體群組讓您能夠將您的執行個體分散在多個區域中，以改善您應用程式的可用性，並支援一個區域失敗或整個群組的執行個體停止回應等極端情況。

使用 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 個執行個體，一個區域會得到 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 即可知道對執行個體群組的更新是否已執行完畢。而查看 status.isStable==true 即可知道群組中的所有執行個體是否在執行中且健康狀態良好 (也就是說，每個代管執行個體的 currentAction 值都為 NONE)。請注意，代管執行個體群組的穩定性取決於 Updater 以外的群組設定；舉例來說，假設您的群組能自動調度資源且目前正在擴充資源，則因為自動配置器作業的關係，狀態值將顯示為 isStable==false。

您也可以透過主控台查看要更新的目前執行個體數和目標數量。

主控台

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

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

「詳細資料」頁面會顯示各執行個體範本的更新中執行個體目標目前數目與目標數目，並顯示更新參數。

gcloud

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

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

API

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

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

如果執行個體是地區代管執行個體群組，請以 regions/[REGION] 取代 zones/[ZONE]。

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

status.versionTarget.isReached

當群組中的所有 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 欄位值即可驗證。

status.isStable 設為 false 時，代表變更已生效、待處理或代管執行個體群組本身遭到修改。

status.isStable 設為 true 時則表示：

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

您可以透過多種方式來修改代管執行個體群組，例如：

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

完成所有動作後，該代管執行個體群組的 status.isStable 將再次設為 true。

您還可以使用帶有 gcloud beta compute instance-groups managed wait-until 標記的 --stable 指令，等候該群組的 status.isStable 設為 true：

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

目前對執行個體的動作

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

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           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://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/listManagedInstances

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

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.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：目前並未對執行個體執行任何動作。

執行個體成功更新後，其 instanceStatus 欄位會反映執行個體的目前狀態。

復原更新

目前沒有明確的指令可將更新復原回先前的版本，但如果您決定要復原更新 (無論是完全進行或初期測試更新)，則做法是提出新的更新要求，並傳遞您要復原回的那個執行個體範本。

例如，下列指令會儘快復原更新：

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://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

如果執行個體是地區代管執行個體群組，請以 regions/[REGION] 取代 zones/[ZONE]。

在要求內文中，將舊執行個體範本指定為 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 欄位。同時使用這兩個欄位會導致模稜兩可與混淆。

如果您在呼叫 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 欄位。

此外，這個方法會將 updatePolicy 設為 OPPORTUNISTIC。這可以防止代管執行個體群組主動部署 versions 欄位中未明確指定的執行個體範本。

後續步驟

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

事前準備

啟動基本滾動式更新程序

主控台

gcloud

API

設定更新的選項

供應過度上限

無法使用數量的上限

最短等待時間

最小動作

其他更新範例

啟動初期測試更新

主控台

gcloud

API

向前滾動初期測試更新

主控台

gcloud

API

啟動機會式或主動式更新

主控台

gcloud

API

更新選取的執行個體

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

gcloud

API

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

主控台

gcloud

API

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

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

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

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

監控更新

群組狀態

主控台

gcloud

API

status.versionTarget.isReached

status.isStable

目前對執行個體的動作

gcloud

API

復原更新

控制更新速度

停止更新

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

versions 欄位、instanceTemplate 欄位與 get() 欄位

versions 欄位和 setInstanceTemplate() 方法

後續步驟

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

`versions` 欄位、`instanceTemplate` 欄位與 `get()` 欄位

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