在 MIG 中套用新的 VM 設定


本頁面說明如何在代管執行個體群組 (MIG) 中設定虛擬機器 (VM) 執行個體,以及如何將設定套用至群組中現有的 VM。

您可以使用下列 VM 設定元件,為 MIG 中的 VM 指定預期設定:

  • 必要條件:執行個體範本
  • 選用:適用於所有執行個體的設定
  • 選用:有狀態設定

只要您使用這些元件更新預期的設定,Compute Engine 就會自動將更新後的設定套用至群組中新增的 VM。

如要將更新後的設定套用至現有 VM,請使用本頁所述的方法:

  • 自動推出功能時,可設定中斷預算,並選擇是否為新範本提供測試版更新
  • 僅針對特定 VM 手動更新,盡量減少中斷時間
  • 重新建立特定 VM

您也可以設定 MIG,在 VM 修復期間將最新可用的設定套用至 VM。詳情請參閱「在修復期間套用設定更新」。

如果您只需要調整 MIG 大小,請參閱說明文件,瞭解如何在 MIG 中新增或移除 VM。如要瞭解如何設定 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 中 VM 的設定元件

您可以透過下列元件設定 MIG 中的 VM:

元件屬性用途
執行個體範本 機器類型、開機磁碟映像檔、標籤、啟動指令碼和其他 VM 屬性 必填:使用執行個體範本,為群組中的所有 VM 定義必要和選用執行個體屬性。

選用:如要 Canary 測試第二個 VM 設定,您可以將第二個執行個體範本新增至群組,並套用至群組中的 VM 子集。
適用於所有執行個體的設定 標籤和中繼資料 選用:使用全執行個體設定,快速覆寫群組中所有 VM 的執行個體範本屬性。
有狀態設定 有狀態磁碟、IP 位址和中繼資料 選用:如要支援有狀態的工作負載,請為群組中的 VM 新增有狀態設定。

如果您透過這些元件更新群組的任何設定,必須將更新後的設定套用至群組中的現有 VM,才能讓更新後的設定生效。

將新設定套用至現有 VM 的方法

更新 MIG 的 VM 設定後,您可以使用下列方法,將新設定套用至群組中的現有 VM:

  • 自動 (預防性):如果您希望 MIG 自動將新設定套用至群組中的所有現有 VM,或其中的一部分,請使用這項方法。對執行中的 VM 造成的干擾程度取決於您設定的更新政策。您可以使用這個方法來測試更新新的執行個體範本。如要使用這個方法,請將 MIG 的更新類型設為「主動式」。
  • 選擇性 (隨機):如果您想手動套用更新,或想一次更新群組中所有現有的 VM,請使用這個方法。您可以指定任何或所有 VM 更新為最新設定。如要使用這個方法,請將 MIG 的更新類型設為「投機」。
  • 重新建立 VM:重新建立特定 VM 以套用新設定。

如要進一步瞭解如何設定 MIG 的更新類型,請參閱設定主動或投機更新

自動 (主動)

自動更新類型也稱為主動式更新類型。將 MIG 的更新類型設為主動式後,MIG 會視需要自動將更新後的設定套用至 VM。

將 MIG 的更新類型設為主動式有兩個主要優點:

  • 系統會根據您指定的規格自動發布更新,讓使用者在第一次提出要求之後就不必再輸入任何設定值。您可以指定部署速度、服務中斷程度和更新範圍。
  • 您可以自動執行部分推出作業,以便進行初期測試。

如要瞭解如何設定 MIG 的更新類型,請參閱「設定主動式或隨機式更新」一文。

如要進一步瞭解自動推播,請參閱「在 MIG 中自動套用 VM 設定更新」。

選擇性 (機會主義)

選取更新類型也稱為隨機更新類型。將 MIG 的更新類型設為隨機時,只有在您選擇要更新的特定 VM 時,MIG 才會將新設定套用至現有 VM。

將 MIG 的更新類型設為投機可提供下列優點:

  • 您可以選取要更新的 VM。
  • 您可以控制更新的時間和順序。
  • 您可以使用 gcloud CLI 或 REST 立即更新所有執行個體。

在某些情況下,選擇性更新類型很實用,因為您不想造成可避免的系統不穩定問題。舉例來說,請考慮以下情況:

  • MIG 中的其中一個 VM 發生故障,需要進行修復,但您不想變更其設定。如果您將 MIG 的更新類型設為機會型,且未強制在修復期間套用更新,則 Compute Engine 會使用用於建立該 VM 的相同設定來修復 VM,即使原始執行個體範本已不存在也一樣。

  • 您有自動調度資源的 MIG,且想套用非重大更新,但不急著要套用。為確保 Compute Engine 不會拆除現有的 VM 來套用更新,請將 MIG 的更新類型設為投機。縮減資源時,自動配置器會優先終止使用舊版設定的 VM。當群組擴展時,群組會使用最新的設定建立 VM。

如要瞭解如何設定 MIG 的更新類型,請參閱「設定主動式或隨機式更新」一文。

如要進一步瞭解如何有選擇地更新 VM,請參閱「在 MIG 中有選擇地套用 VM 設定更新」。

重新建立 VM

您可以重新建立 MIG 中的任何 VM。這樣一來,MIG 就會套用尚未套用至該 VM 的任何更新設定。詳情請參閱「在 MIG 中重新建立 VM」。

設定主動式或隨機式更新

如要自動將新設定套用至現有虛擬機器,請將 MIG 的更新類型設為「主動」。如要只在選取要更新的 VM 時,將新設定套用至現有 VM,請將 MIG 的更新類型設為「投機」。

使用 Google Cloud 控制台、Google Cloud CLI 或 REST。

主控台

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

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

  2. 選取要更新的 MIG。

  3. 按一下頁面頂端的「更新虛擬機器」

  4. 如要為群組設定其他範本,請在「新範本」下方,選取要使用的執行個體範本。

  5. 在「更新設定」下方,選擇自動或選擇性更新。

gcloud

使用 rolling-action start-update 指令,並將 --type 旗標設為 opportunisticproactive

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --type=TYPE

您也可以使用 beta update 指令,並加入 --update-policy-type 標記。

gcloud beta compute instance-groups managed update INSTANCE_GROUP_NAME \
    --update-policy-type=TYPE

更改下列內容:

  • INSTANCE_GROUP_NAME:群組名稱
  • NEW_TEMPLATE:群組的新範本名稱
  • TYPE:更新類型,opportunisticproactive

REST

區域區域 MIG 資源上呼叫 patch 方法。

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

{
  "updatePolicy": {
    "type": "TYPE" # Choose an opportunistic or proactive update
  },
  "versions": [{
    "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
    }]
}

更改下列內容:

  • PROJECT_ID:MIG 所在的專案。
  • REGION:MIG 所在的區域。如果是區域 MIG,請將 regions/REGION 替換為 zones/ZONE
  • INSTANCE_GROUP_NAME:群組名稱。
  • NEW_TEMPLATE:群組的新範本名稱。
  • TYPE:更新類型,OPPORTUNISTICPROACTIVE

如要進一步瞭解如何設定新範本,然後將該範本套用至 MIG 中的新 VM 和現有 VM,請參閱下列網頁:

查看群組的更新政策類型

您可以使用 gcloud CLI 或 REST,查看 MIG 目前設定的更新政策類型 (「投機」或「主動」) 和其他更新政策設定

gcloud

使用 describe 指令並加入 --format 旗標,即可只列出 updatePolicy 設定。

gcloud beta compute instance-groups managed describe INSTANCE_GROUP_NAME \
    --format="(updatePolicy)"

REST

針對可用區區域 MIG 提出 GET 要求,然後查看 updatePolicy 欄位。

GET https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

如要變更政策類型,請參閱設定主動式或隨機式更新

已暫停和已停止的 VM 更新

如果您在 MIG 中擁有已暫停和已停止的 VM 集區,可以選擇性地 (機會性地) 更新已暫停或已停止的 VM,就像更新其他執行中的 VM 一樣。如果您設定自動 (主動) 更新,MIG 會依照以下順序更新虛擬機器:

  1. 執行、已暫停和已停止的 VM
  2. 狀態為 SUSPENDINGSTOPPING 的 VM

針對自動更新,MIG 只會根據執行中的 VM 目標數量計算最大激增最大無法使用,不會考慮待機集區中的 VM。

如果自動更新需要取代群組中的 VM,MIG 會執行以下操作:

  1. 刪除已暫停和已停止的 VM。
  2. 使用新的執行個體範本建立新的 VM。
  3. 執行初始化程序。
  4. 暫停或停止 VM。

如果自動更新只需要重新整理或重新啟動群組中的 VM,MIG 會執行以下操作:

  1. 繼續或啟動 VM。
  2. 在 VM 執行時執行更新。
  3. 執行初始化程序。
  4. 暫停或停止 VM。

Canary 版更新

如果您想在已暫停或停止 VM 的 MIG 中啟動初期測試更新,請遵循下列規定:

  • manual 待機政策模式中,MIG 只會根據您要套用更新的 VM 數量或百分比,更新執行中的 VM。已暫停和停止的 VM 仍會保留在舊版中。
  • scale-out-pool 待機政策模式中,您無法在 MIG 中啟動初期測試更新。

versionsinstanceTemplate 欄位之間的關係

如果您使用 REST,建議您使用 instanceGroupManagers.versionsregionInstanceGroupManagers.versions 欄位,為區域和區域 MIG 設定執行個體範本。

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

為了回溯相容性,MIG 仍會繼續支援設定頂層 instanceTemplate 欄位,但我們建議您改為只使用 versions 欄位。同時使用最高層級的 instanceTemplate 欄位和 versions 欄位,會導致模稜兩可與混淆的情況發生。

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

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

    這是有效的要求,在這種情況下,系統不會造成模稜兩可的情況,且會將新的執行個體範本套用至 MIG。

    舉例來說,在下列要求中,最高層級的 instanceTemplateversions 欄位會指定同一個執行個體範本,且這個範本與代管執行個體群組中目前的範本不相同,因此 MIG 會更新為新的執行個體範本:

    {
     "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • 您為這兩個欄位設定的值並不相符,且其中只有一個值與 MIG 中目前的執行個體範本不相同。

    這是有效的要求,系統會將不同於目前設定的欄位視為預期的值。舉例來說,您可以呼叫 update() 方法並提供這兩個欄位,但只更新一個欄位:

    {
     "instanceTemplate": "global/instanceTemplates/CURRENT_TEMPLATE",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • 您把這兩個欄位設定成不相符的值,且這兩個值都與 MIG 中的目前執行個體範本不相同。

    這是無效的設定,會讓系統因要求沒有明確意圖而傳回錯誤。

    {
     "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() 方法的行為會與先前的相同,讓您能變更 MIG 用來建立 VM 的範本。當您呼叫這個方法時,系統會以您用 setInstanceTemplate() 方法所指定的執行個體範本覆寫 versions 欄位。

setInstanceTemplate() 方法也會把 updatePolicy 設定為 OPPORTUNISTIC。這可以防止 MIG 主動部署您沒有在 versions 欄位中明確指定的執行個體範本。

後續步驟