共用方式為

使用 Azure Kubernetes Service 中的實體標籤 （eTags） 增強並行控制

若要防止 Azure Kubernetes Service （AKS） 中的衝突要求，eTags （實體標籤） 可作為啟用並行控制的唯一標識碼。 對叢集提出要求時，系統會檢查提供的 eTag 是否符合資料庫中儲存的最新版本。 如果不相符，要求會提早失敗，確保不會發生非預期的覆寫。

使用 eTag 標頭

透過標頭套用 eTag 有兩個選項：

–-if-match 標頭：確保只有在現有的 eTag 符合此標頭中提供的值時，才會執行作業。

–-if-none-match 標頭：確保只有在沒有任何一個 eTag 符合此標頭中提供的值時，才會執行作業。 這個標頭類型只能是空的 或 *。

尋找現有的 ETag

您可以對叢集或節點集區執行 LIST 或 GET 呼叫，以查看現有的ETag。 ETag 看起來像下列範例：

"agentPoolProfiles": [
    {"eTag": "5e5ffdce-356b-431b-b050-81b45eef2a12"}
]

可能會修改現有的ETags

ETag 可以同時存在於叢集和代理程式集區層級。 視您執行的作業範圍而定，您可以傳入對應的 eTag。 當您執行叢集層級作業時，會同時更新叢集層級 eTag 和代理程式集區 eTag。 當您執行代理程式集區的操作時，只有代理程式集區的eTag會被更新。

在作業標頭中包含ETag

標題是可選用的。 下列範例示範如何使用 –-if-match 和 -–if-none-match 標頭。

範例 1：如果 eTag 與yvjvt相符，則下列 CLI 命令會操作現有的叢集MyManagedCluster

az aks delete -g MyResourceGroup -n MyManagedCluster --if-match "yvjvt"

範例 2：下列 CLI 命令會建立名為 MyManagedCluster的新叢集。 如果在*標頭中提供–if-none-match，表示驗證資源不存在。

az aks create -g MyResourceGroup -n MyManagedCluster --if-none-match "*"

組態和預期的行為

下表根據不同的 eTag 組態和資源存在，概述 HTTP 作業的預期行為（PUT、PATCH 和 DELETE）。 它們會顯示標頭 --if-match 或 --if-none-match 的存在如何影響響應狀態代碼，確保並發控制並防止非預期的修改。

PUT 資源不存在 資源存在
--if-match = "" 201 – 已建立 200 - 確定
--if-match = "*" 412 - 前置條件失敗 200 - 正常
--if-match = "xyz" 412 - 前置條件失敗 200 - 確定或 412 - 前置條件失敗
--if-none-match = "*" 201 - 已建立 412 - 前置條件失敗
補丁 資源不存在 資源存在
--if-match = "" 404 - 找不到 200 - 正常
--if-match = "*" 404 - 找不到 200 - 正常
--if-match = "xyz" 404 - 找不到 200 - 確定或 412 - 前置條件失敗
刪除 資源不存在 資源存在
--if-match = "" 204 - 無內容 200 - 正常
--if-match = "*" 204 - 無內容 200 - 正常
--if-match = "xyz" 204 - 無內容 200 - 確定或 412 - 前置條件失敗

案例 1： BadRequest – --if-none-match 標題不是空的或未設定為 *

預先驗證檢查未通過。 標頭只能是空的 --if-none-match，或者具有*值。

案例 2：BadRequest - --if-match標頭不是空的，標頭為--if-none-match*

這無法進行預先驗證檢查。 這兩個標頭無法同時使用。

案例 3： PreConditionFailed - --if-none-match 是 * 且指定的資源已經存在

如果在--if-none-match標頭中傳遞*（任何通配符）值且該資源已經存在，則將拒絕該請求。

案例 4： PreConditionFailed - 標頭的值 --if-match 不符合資源的最新 eTag 值

如果提供的標頭與 eTag 值不符，則會拒絕要求。 需要新的 GET 作業，才能取得資源的最新 eTag，並更新要求中的標頭值。