다음을 통해 공유

Azure Kubernetes Service에서 eTags(엔터티 태그)를 사용하여 동시성 제어 향상

AKS(Azure Kubernetes Service)에서 충돌하는 요청을 방지하기 위해 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 명령은 기존 클러스터 MyManagedCluster 를 삭제합니다. yvjvt

eTag를 사용하여 AKS 클러스터를 삭제하려는 경우를 가정해 보겠습니다. (리소스에서 가져온 실제 eTag 값으로 "yvjvt"를 대체하세요.)

az aks delete -g $RG_NAME -n $CLUSTER_NAME --if-match "yvjvt"

예제 2: 아래 CLI 명령은 새 클러스터를 만듭니다. 헤더에 * 제공된 경우 –if-none-match 이는 리소스가 존재하지 않는지 확인하는 것을 의미합니다.

먼저 리소스 그룹을 만듭니다.

export RANDOM_SUFFIX=$(head -c 3 /dev/urandom | xxd -p)
export RG_NAME="my-resource-group$RANDOM_SUFFIX"
export REGION="eastus2"

az group create --name $RG_NAME --location $REGION

그런 다음, 고유성을 보장하기 위해 임의의 접미사가 있는 새 AKS 클러스터를 만듭니다.

export CLUSTER_NAME="my-managed-cluster$RANDOM_SUFFIX"

az aks create -g $RG_NAME -n $CLUSTER_NAME --location $REGION --if-none-match "*"

결과:

{
  "aadProfile": null,
  "addonProfiles": null,
  "agentPoolProfiles": [
    {
      "eTag": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      ...
    }
  ],
  "apiServerAccessProfile": null,
  "autoScalerProfile": null,
  ...
  "name": "my-managed-clusterxxx",
  ...
  "provisioningState": "Succeeded",
  ...
  "resourceGroup": "my-resource-groupxxx",
  ...
}

구성 및 예상 동작

아래 표에서는 다양한 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 - 사전 조건 실패
PATCH 리소스가 없습니다. 리소스가 있음
--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 is * 및 지정된 리소스가 이미 있음

* (언제든지 사용할 수 있는 와일드카드) 값이 --if-none-match 헤더로 전달되고 리소스가 이미 존재하는 경우 요청이 거부됩니다.

시나리오 4: PreConditionFailed 헤더 값이 리소스의 --if-match 최신 eTag 값과 일치하지 않음

제공된 헤더가 eTag 값과 일치하지 않으면 요청이 거부됩니다. 리소스에 대한 최신 eTag를 가져와서 요청의 헤더 값을 업데이트하려면 새 GET 작업이 필요합니다.