使用 Azure Kubernetes 服务中的实体标记（eTags）增强并发控制

为了防止 Azure Kubernetes 服务（AKS）中的冲突请求，eTags（实体标记）充当启用并发控制的唯一标识符。 发出对群集的请求时，系统会检查提供的 eTag 是否与数据库中存储的最新版本匹配。 如果出现不匹配的情况，请求会提前失败，从而确保不会发生非预期的覆盖。

利用 eTag 标头

有两个选项来通过标头应用 eTag：

–-if-match 标头：仅当现有的ETag与此标头中提供的值匹配时，才执行该操作。

–-if-none-match 标头：确保只有当 eTag 与此标头中提供的值不匹配时才执行此操作。 此标头类型只能为空或一个 *。

查找现有 ETag

可以对群集执行 LIST 调用或对节点池执行 GET 调用，以查看现有的 ETag。 ETag 类似于以下示例：

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

修改现有 ETag 的内容

ETag 可以同时存在于群集和代理池级别。 根据所执行的操作的范围，可以传入相应的 eTag。 执行群集级作时，会同时更新群集级 eTag 和代理池 eTag。 执行代理池操作时，系统只会更新代理池 eTag。

在操作标头中包含 ETag

标头的使用不是必需的。 以下示例演示如何使用 –-if-match 和 -–if-none-match 标头。

示例 1：如果 eTag 与现有群集匹配，则可以通过下面的 CLI 命令删除该群集MyManagedClusteryvjvt

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 标头如何影响响应状态代码，确保并发控制并防止意外修改。

常见问题和建议的缓解措施

应用场景 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，并更新请求中的标头值。