在 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 進行驗證:

    選取這個頁面上範例的預計用途分頁:

    控制台

    使用 Google Cloud 控制台存取 Google Cloud 服務和 API 時,不需要設定驗證。

    gcloud

    1. 安裝 Google Cloud CLI。 完成後,執行下列指令來初始化 Google Cloud CLI:

      gcloud init

      如果您使用外部識別資訊提供者 (IdP),請先 使用聯合身分登入 gcloud CLI。

  • 設定預設區域和可用區。
  • REST

    如要在本機開發環境中使用本頁的 REST API 範例,請使用您提供給 gcloud CLI 的憑證。

      安裝 Google Cloud CLI。

      如果您使用外部識別資訊提供者 (IdP),請先 使用聯合身分登入 gcloud CLI。

    詳情請參閱 Google Cloud 驗證說明文件中的「使用 REST 進行驗證」。

限制

  • 如果您有有狀態的 MIG,且想使用自動滾動式更新,則替換執行個體時必須保留執行個體名稱,或將替換方法設為 RECREATE。
  • 動態網路介面 (NIC) 不支援 IP 位址的執行個體專屬設定。

開始基本滾動式更新

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

您可以控管滾動式更新的各個層面,例如可離線更新的執行個體數量、更新執行個體之間要等待多久、新範本是否會影響所有執行個體或僅影響部分執行個體等。

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

  • 更新是意圖式的。當您提出初始更新要求時,Compute Engine API 會傳回成功回應,確認要求有效,但這不代表更新成功。您必須檢查群組狀態,判斷更新是否部署成功。

  • Instance Group Updater API 是宣告式 API。API 預期要求會指定 MIG 更新後的所需設定,而不是明確的函式呼叫。

  • 自動更新功能最多支援 MIG 中的兩個執行個體範本版本。也就是說,您可以為群組指定兩個不同的執行個體範本版本,這有助於執行Canary 更新。

如要開始基本滾動式更新,將更新套用至群組中的所有執行個體,請選取下列任一選項:

控制台

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

    前往「Instance groups」(執行個體群組)

  2. 選取要更新的 MIG。

  3. 按一下 [編輯]。

  4. 按一下「執行個體範本和覆寫」展開該部分,然後新增測試用範本,如下所示:

    1. 按一下「新增測試用範本」。
    2. 在「Instance template for testing」(測試用執行個體範本) 清單中,選取新範本。

      如果沒有要測試的範本,請使用「建立新的執行個體範本」選項,然後按照提示建立範本。

    3. 在「目標執行」欄位中,輸入要套用新範本的執行個體數量或百分比。
    4. 在「執行個體或百分比」欄位中,選取「執行個體」或「百分比」,指出您在「目標執行」欄位中輸入的數字。

  5. 按一下「更新政策」展開該部分,然後執行下列操作:

    1. 選取「自動」(如果系統未預設選取的話)。
    2. 其他選項則保留預設值,或視需要修改。
  6. 按一下「儲存」即可開始更新。

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:您要用來在代管執行個體群組中建立執行個體的執行個體範本網址。網址可以包含執行個體範本的 ID 或名稱。請指定下列其中一個值:
    • 如果是區域執行個體範本:projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • 全域執行個體範本:INSTANCE_TEMPLATE_ID
  • ZONE:如果是可用區 MIG,請提供可用區
  • REGION:如果是區域 MIG,請提供區域

REST

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

舉例來說,如果是區域性 MIG,下列要求會顯示將 100% 的執行個體自動更新至新執行個體範本所需的最低設定。

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 會等待下列條件:

  1. 等待健康狀態檢查傳回 HEALTHY,等待時間最長為 MIG 的 autohealingPolicies.initialDelaySec 值所指定的時間長度。
  2. 然後,等待由 minReadySec 所指定的時間。

如果健康狀態檢查未在 initialDelaySec 內傳回 HEALTHY,更新程式就會將 VM 執行個體宣告為健康狀態不良,並可能停止更新。在 initialDelaySec 和 minReadySec 時間範圍內,VM 執行個體等待驗證時,執行個體的 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。更新時保留執行個體名稱。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]

對所有 VM 執行個體執行滾動式更新,但一次建立的新執行個體數量最多不得超過目標大小的 10%

舉例來說,如果您有 1,000 個執行個體並執行下列指令,Updater 最多會建立 100 個執行個體,然後開始移除執行先前執行個體範本的執行個體。

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

初期測試更新

初期測試更新是指套用至群組中部分執行個體的更新。透過初期測試更新,您可以在隨機選取的執行個體子集中測試新功能或升級,不必將可能造成中斷的更新全面套用至所有執行個體。如果更新作業不順利,您只需要回溯部分執行個體,盡量減少對使用者的影響。

除了更新的執行個體數量少於執行個體群組的總大小之外, Canary 更新與標準滾動式更新相同。與標準的滾動式更新一樣,您可以設定其他選項,控管服務受中斷的程度。

開始初期測試版本更新

如要啟動初期測試版本更新,請指定最多兩個執行個體範本版本,通常是初期測試版本的新執行個體範本,以及其餘執行個體的現行執行個體範本。舉例來說,您可以指定根據 NEW_INSTANCE_TEMPLATE 建立 20% 的執行個體,其餘執行個體則繼續在 OLD_INSTANCE_TEMPLATE 上執行。一次最多只能指定兩個執行個體範本。NEW_INSTANCE_TEMPLATE可以是與 MIG 位於相同區域的區域執行個體範本,也可以是全域執行個體範本。

您一律必須為 Canary 版本指定目標大小 (targetSize)。如果省略 Canary 版本的目標大小,就無法啟動 Canary 更新。舉例來說,如果您指定 10% 的執行個體用於 Canary 測試,其餘 90% 的執行個體將不受影響,並使用目前的執行個體範本。

控制台

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

    前往「Instance groups」(執行個體群組)

  2. 選取要更新的代管執行個體群組。

  3. 按一下 [編輯]。

  4. 按一下「執行個體範本和覆寫」展開該部分。

    1. 按一下「新增測試用範本」。
    2. 在「Instance template for testing」(測試用執行個體範本) 清單中,選取新範本。

      如果沒有要測試的範本,請使用「建立新的執行個體範本」選項,然後按照提示建立範本。

    3. 在「目標執行」欄位中,輸入要套用新範本的執行個體數量或百分比。
    4. 在「執行個體或百分比」欄位中,選取「執行個體」或「百分比」,指出您在「目標執行」欄位中輸入的數字。

  5. 選用:如要設定更新的其他選項,請按一下「更新政策」展開該部分。視需要修改欄位。

  6. 按一下「儲存」即可開始更新。

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,請提供區域。

舉例來說,下列指令會執行 Canary 更新,將 example-template-B 推出至群組中 10% 的執行個體:

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

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:要進行 Canary 測試的新範本名稱。
  • NUMBER|PERCENTAGE:要以 Canary 測試這項更新的執行個體固定數量或百分比。只有在群組包含 10 個以上的執行個體時,才能設定百分比。否則請提供固定號碼。
  • CURRENT_INSTANCE_TEMPLATE:群組目前使用的執行個體範本。

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

提出要求後,您可以監控更新進度,瞭解更新何時完成。

將初期測試更新向前推進

執行Canary 更新後,您可以決定是否要將更新提交至 100% 的 MIG,或是將其復原。

控制台

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

    前往「Instance groups」(執行個體群組)

  2. 選取要更新的代管執行個體群組。

  3. 按一下 [編輯]。

  4. 針對您選取用於測試的執行個體範本,將測試範本的「Target running」(目標執行) 值更新為「100%」,將測試範本轉移至所有執行個體。

    或者,您也可以將原始範本替換為測試範本,並刪除測試用的執行個體範本。

  5. 按一下「儲存」即可開始更新。

gcloud

如要確定使用 Canary 更新,請發出另一個 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
   }
 ]
}

監控更新

啟動更新後,新設定可能需要一段時間,才會全面套用至所有受影響的執行個體。如要監控更新進度,請檢查下列項目:

群組狀態

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

控制台

如要監控群組的滾動式更新,請前往群組的詳細資料頁面。

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

    前往「Instance groups」(執行個體群組)

  2. 選取要監控的代管執行個體群組。群組的總覽頁面會顯示每個執行個體使用的範本。

  3. 如要檢視詳細資料,請按一下 [Details] (詳細資料) 分頁標籤。

  4. 在「執行個體範本」部分,您可以查看每個執行個體範本的目前和目標執行個體數量。

  5. 如要查看更新設定,請點按「更新參數」展開。

gcloud

使用 describe 指令。

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

您也可以使用 gcloud compute instance-groups managed wait-until 指令搭配 --version-target-reached 標記,等待群組的 status.versionTarget.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 尚未採用目標版本。如果是 Canary 更新,則false表示使用目標版本的 VM 數量與目標大小不符。

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

檢查群組的 status.isStable 欄位值,確認代管執行個體群組中的所有執行個體都正在執行且健康狀態良好。

status.isStable 設為 false 表示變更有效、待處理,或 MIG 本身正在修改。

當 status.isStable 為 true 時,則代表:

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

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

  • 由您發出推出新執行個體範本的要求。
  • 您要求在 MIG 中建立、刪除、調整大小或更新執行個體。
  • 自動調度器要求調整 MIG 大小。
  • 自動修復資源正在代管執行個體群組中,替換一或多個健康狀態不良的執行個體。
  • 在區域性 MIG 中,部分執行個體正在重新分配。

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

目前對執行個體的動作

如要查看 MIG 中執行個體的詳細資料,包括狀態和群組目前執行的任何動作,請使用 Google Cloud CLI 或 REST。

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 執行個體生命週期。

如果執行個體正在進行某種變更,MIG 會將執行個體的 currentAction 欄位設為下列其中一項動作,協助您追蹤變更進度。否則,currentAction 欄位會設為 NONE。

可能的 currentAction 值:

  • ABANDONING。系統會從 MIG 移除執行個體。
  • CREATING:執行個體目前正在建立。
  • CREATING_WITHOUT_RETRIES。系統會建立執行個體,但不會重試;如果第一次嘗試建立執行個體失敗,MIG 就不會再次嘗試替換執行個體。
  • DELETING:執行個體目前正在刪除。
  • RECREATING。系統正在更換執行個體。
  • REFRESHING:執行個體正從其目前目標集區中移除,並正讀入至現有的目標集區清單中 (此清單可能會與現有目標集區相同或不同)。
  • RESTARTING:系統正在使用 stop 和 start 方法重新啟動該執行個體。
  • RESUMING。例項在暫停後正在恢復。
  • STARTING。執行個體停止後,正在啟動程序中。
  • STOPPING。正在停止執行個體。
  • SUSPENDING。執行個體正在暫停。
  • VERIFYING:執行個體已建立,目前正受到驗證。
  • NONE:目前並未對執行個體執行任何動作。

復原更新內容

沒有明確的指令可將更新復原為先前的版本,但如果您決定復原更新 (完全提交的更新或 Canary 更新),可以提出新的更新要求,並傳遞要復原的執行個體範本。

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

如果區域 MIG 的執行個體少於 10 個,您必須為 maxUnavailable 使用固定值,並將值設為群組中的執行個體數量。

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 \
       --canary-version template=NEW_INSTANCE_TEMPLATE,target-size=2 \
       [--zone=ZONE | --region=REGION]

    對更新工具而言,這項更新已完成,因此不會更新其他執行個體,進而停止更新。

控制滾動式更新的速度

根據預設,當您提出更新要求時,Updater 會盡快執行更新。如果您不確定是否要完全套用更新,或是暫時測試變更,可以使用下列方法控制更新速度。

  1. 啟動初期測試更新,而非完全更新。
  2. 設定較大的 minReadySec 值。設定這個值會導致更新程式等待這段時間,才會將執行個體視為更新成功,並繼續處理下一個執行個體。
  3. 啟用健康狀態檢查,讓更新程式等待應用程式啟動並回報健康狀態信號,再將執行個體視為更新成功,然後接續處理下一個執行個體。
  4. 設定較低的 maxUnavailable 和 maxSurge 值。確保一次只更新最少數量的執行個體。
  5. 在 MIG 中選擇性更新執行個體,而非使用自動更新。

您也可以結合使用這些方法,控制更新頻率。

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

視更新性質而定,更新可能會中斷執行個體的生命週期狀態。舉例來說,如要變更執行個體的開機磁碟,必須替換執行個體。您可以設定下列選項,控制滾動式更新期間的中斷程度:

  • 最小動作:使用這個選項可盡量減少干擾,或套用比必要動作更具干擾性的動作。

    • 為盡可能減少中斷,請將最小動作設為 REFRESH。如果更新需要採取較具干擾性的動作,Compute Engine 會執行必要動作來執行更新。
    • 如要採取比必要行動更具干擾性的動作,請將最小動作設為 RESTART 或 REPLACE。舉例來說,Compute Engine 不必重新啟動 VM 即可變更其元資料。不過,如果應用程式只會在 VM 重新啟動時讀取執行個體中繼資料,您可以將最小動作設為 RESTART,以便擷取中繼資料變更。
  • 允許的中斷程度最高動作:如果更新造成的中斷程度超出可接受範圍,請使用這個選項避免更新。如果更新需要比您使用這個旗標設定的更具破壞性的動作,更新要求就會失敗。舉例來說,如果將允許的最具破壞性動作設為 RESTART,則更新開機磁碟映像檔的嘗試會失敗,因為該更新需要替換執行個體,這比重新啟動更具破壞性。

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

值 說明 可以更新哪些執行個體屬性?
REFRESH 請勿停止執行個體。 額外磁碟、Dynamic Network Interface (NIC)、執行個體中繼資料、標籤、標記
RESTART 會停止執行個體,然後重新啟動。 額外的磁碟、動態 NIC、執行個體中繼資料、標籤、標記、機型
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,代管執行個體群組會將類型變更為 AUTOMATIC。
  • MIG 會更新每個執行個體的 versions.name。

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

控制台

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

    前往「Instance groups」(執行個體群組)

  2. 選取要重新啟動或替換 VM 的代管執行個體群組。

  3. 按一下「重新啟動/替換 VM」。

  4. 在「作業」部分,選取「重新啟動」或「更換」。

  5. 如要啟動作業,請按一下「重新啟動 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 不會執行重新啟動或取代作業。

  • 將 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 的更新時,更新程式一律會按比例更新每個可用區的執行個體,您無法選擇要先更新哪個可用區的執行個體,也無法只更新一個可用區的執行個體。

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

區域 MIG 的預設更新值如下:

  • maxUnavailable=NUMBER_OF_ZONES
  • maxSurge=NUMBER_OF_ZONES

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

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

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

如果您在更新要求中指定固定數量,系統會將您指定的數量除以區域性 MIG 中的可用區數量,然後平均分配。舉例來說,如果您指定 maxSurge=10,Updater 會將 10 除以區域中的可用區數量,並根據該數字建立執行個體。如果執行個體數量無法平均分配到各個可用區,Updater 會將剩餘執行個體新增至隨機可用區。因此,如果三個可用區共有 10 個執行個體,其中兩個可用區會各取得 3 個執行個體,另一個可用區則會取得 4 個執行個體。maxUnavailable 和 targetSize 參數也採用相同的邏輯,用於 Canary 更新。

只有在 MIG 包含 10 個以上的 VM 執行個體時,才能指定百分比。 視情況而定,百分比的處理方式略有不同:

  • 如果您指定要讓某個百分比的 VM 執行個體進行初期測試更新,Updater 就會嘗試將執行個體平均分散到各個區域。每個區域中的餘數會無條件進位或無條件捨入,但每個群組的總差異不會大於 1 個 VM 執行個體。舉例來說,如果 MIG 有 10 個執行個體,且目標大小百分比為 25%,則更新會推出至 2 到 3 個 VM 執行個體。

  • 如果您為 maxSurge 和 maxUnavailable 等更新選項指定百分比,系統會分別將各區域的百分比四捨五入。

後續步驟