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

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

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

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

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

如要將更新後的設定套用至現有虛擬機器，您可以設定自動更新 (也稱為主動更新類型)。MIG 會自動為群組中的所有虛擬機器或部分虛擬機器推出設定更新。您可以控制部署速度、服務中斷程度，以及透過初期測試版本更新，決定 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. After installing the Google Cloud CLI, initialize it by running the following command:

     gcloud init

     If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  2. Set a default region and zone.

  REST

  To use the REST API samples on this page in a local development environment, you use the credentials you provide to the gcloud CLI.

  After installing the Google Cloud CLI, initialize it by running the following command:

  gcloud init

  If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  For more information, see Authenticate for using REST in the Google Cloud authentication documentation.

限制

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

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

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

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

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

• 更新是意圖式的。當您第一次提出更新要求時，Compute Engine API 會傳回成功的回應，向您確認要求是有效的，但這不代表更新已順利完成。您必須查看群組的狀態，才能判斷更新是否已成功部署。

• Instance Group Updater API 是宣告式 API。API 預期會收到一項要求，用於指定所需的 MIG 後置更新組態，而非明確的函式呼叫。

• 自動更新功能支援 MIG 中最多兩個版本的執行個體範本。這表示您可以為群組指定兩個不同的執行個體範本版本，這對執行初期測試更新很有幫助。

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

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

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 大小時，系統會建立新的執行個體。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 會等待下列條件：

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

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

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

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

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

最少動作

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

如果您的更新作業需要執行干擾程度高於透過此標記設定的動作，Compute Engine 會執行必要的動作來進行更新。舉例來說，如果您將重新啟動設為最小動作，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：透過更新保留執行個體名稱。舊 VM 關閉時，Compute Engine 會釋出執行個體名稱。接著，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% 就不會受到影響，且會使用目前的執行個體範本。

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]

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%

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

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

提出要求後，您可以監視更新，瞭解更新何時完成。

將初期測試更新向前推進

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

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

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 主控台查看目前正在更新中和計劃要更新的執行個體數量。

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

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

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 為 false 時，代表變更已生效、待處理，或是系統正在修改 MIG。

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

• MIG 中沒有任何執行個體遭到任何類型的變更，且所有執行個體的 currentAction 都顯示 NONE。
• MIG 中的執行個體沒有任何待處理的變更。
• MIG 本身不會經過修改。

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

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

完成所有動作後，該 MIG 的 status.isStable 會再次設為 true。

目前對執行個體的動作

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

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

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

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

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

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

如要查看有效的 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 compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=OLD_INSTANCE_TEMPLATE_NAME \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

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_NAME" # Old instance template
    }
  ]
}

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

停止更新

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

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

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

如果您在把更新從主動式轉換到隨機式之後，想要完全停止更新，請依照以下步驟進行：

1. 提出要求以判斷系統已經更新多少個執行個體：

   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
   

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

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

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

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

控制滾動式更新的速度

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

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

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

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

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

• 最少動作：使用這個選項可盡可能減少干擾，或套用干擾程度高於必要動作的動作。

  • 為盡可能減少中斷情形，請將最小動作設為 REFRESH。如果您的更新作業需要執行干擾程度較大的動作，Compute Engine 就會執行必要的動作來進行更新。
  • 如要套用干擾程度超出必要範圍的動作，請將最少動作設為 RESTART 或 REPLACE。舉例來說，Compute Engine 不需要重新啟動 VM 即可變更中繼資料。不過，如果應用程式只會在重新啟動 VM 時讀取執行個體中繼資料，您可以將最小動作設為 RESTART，以便擷取中繼資料變更。

• 允許的最大干擾動作：如果更新作業需要執行的干擾程度超過您能承受的範圍，請使用這個選項禁止更新。如果您的更新作業需要執行干擾程度超出您利用此標記所設定的動作，更新要求就會失敗。舉例來說，如果您將允許的最大干擾動作設為 RESTART，則嘗試更新開機磁碟映像檔的更新就會失敗，因為該更新作業需要取代執行個體，而這動作的干擾程度比重新啟動還要大。

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

允許的最大干擾動作所造成的干擾程度，不能小於最小動作。

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

• 預設的最低限動作為 REPLACE。如要避免不必要的干擾，請將最小動作設為較不干擾的動作。
• 預設的最大干擾動作是 REPLACE。如果您無法容忍這種干擾，請將允許的最大干擾動作設為較不干擾的動作。

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

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

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

輪轉重新啟動會停止並重新啟動所有例項，而輪轉取代會根據取代方法選項取代例項。滾動式重新啟動或取代作業不會改變群組的任何其他設定，包括執行個體範本。

您可能會因為許多原因而需要滾動式重新啟動或滾動式取代。舉例來說，您可能會因為下列其中一個原因，不時重新啟動或取代 VM 執行個體：

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

請使用 Google Cloud 控制台、Google Cloud CLI 或 REST 執行重新啟動或取代作業。

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME

PATCH https://compute.googleapis.com/compute/v1/projects/example-project/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME

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

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

針對所有 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 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]

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 上更新作業系統映像檔。