Migliorare il controllo della concorrenza con tag di entità (eTag) nel servizio Azure Kubernetes

Per evitare richieste in conflitto nel servizio Azure Kubernetes, gli eTag (Tag di entità) fungono da identificatori univoci che abilitano il controllo della concorrenza. Quando viene effettuata una richiesta al cluster, il sistema controlla se l'eTag fornito corrisponde alla versione più recente archiviata nel database. Se c'è una discrepanza, la richiesta fallisce immediatamente, garantendo che non si verifichino sovrascrizioni impreviste.

Utilizzo delle intestazioni ETag

Esistono due opzioni per l'applicazione di eTag tramite intestazioni:

–-if-match Intestazione: garantisce che l'operazione venga eseguita solo se l'eTag esistente corrisponde al valore specificato in questa intestazione.

–-if-none-match Intestazione: garantisce che l'operazione venga eseguita solo se nessuno degli eTag corrisponde al valore specificato in questa intestazione. Questo tipo di intestazione può essere vuoto o *.

Trovare gli ETag esistenti

È possibile effettuare una chiamata LIST o GET al cluster o al pool di nodi per visualizzare l'ETag esistente. Un ETag è simile all'esempio seguente:

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

Cosa modificherebbe gli ETag esistenti

Gli ETag possono esistere sia a livello di cluster che di pool di agenti. A seconda dell'ambito delle operazioni eseguite, è possibile passare l'eTag corrispondente. Quando si esegue un'operazione a livello di cluster, vengono aggiornati sia l'eTag a livello di cluster che l'eTag del pool di agenti. Quando si esegue un'operazione del pool di agenti, viene aggiornato solo l'ETag del pool di agenti.

Includere ETag nelle intestazioni dell'operazione

L'uso delle intestazioni è facoltativo. Gli esempi seguenti mostrano come utilizzare le intestazioni –-if-match e -–if-none-match.

Esempio 1: il comando dell'interfaccia della riga di comando seguente elimina un cluster MyManagedCluster esistente se l'eTag corrisponde a yvjvt

Supponiamo di voler eliminare un cluster AKS usando il relativo eTag. Per illustrazione, sostituire "yvjvt" con il valore eTag reale che hai recuperato dalla risorsa.

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

Esempio 2: il seguente comando CLI crea un nuovo cluster. Se * viene specificato nell'intestazione –if-none-match, significa che si deve verificare che la risorsa non esista.

Creare prima di tutto un gruppo di risorse:

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

Quindi, crea un nuovo cluster AKS con un suffisso casuale per garantire l'univocità.

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

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

Risultati:

{
  "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",
  ...
}

Configurazioni e comportamento previsto

La tabella seguente illustra il comportamento previsto delle operazioni HTTP (PUT, PATCH e DELETE) in base a diverse configurazioni eTag e all'esistenza delle risorse. Mostrano in che modo la presenza delle intestazioni --if-match o --if-none-match influisce sui codici di stato della risposta, assicurando il controllo della concorrenza e impedendo modifiche impreviste.

PUT La risorsa non esiste Risorsa esistente
--if-match = "" 201 - Creato 200 - Ok
--if-match = "*" 412 - Precondizione non riuscita 200 - OK
--if-match = "xyz" 412 - Precondizione non riuscita 200 - OK O 412 - Precondizione non riuscita
--if-none-match = "*" 201 - Creato 412 - Precondizione non riuscita
PATCH La risorsa non esiste Risorsa esistente
--if-match = "" 404 - Non trovato 200 - OK
--if-match = "*" 404 - Non trovato 200 - OK
--if-match = "xyz" 404 - Non trovato 200 - OK O 412 - Precondizione non riuscita
ELIMINA La risorsa non esiste Risorsa esistente
--if-match = "" 204 - Nessun contenuto 200 - OK
--if-match = "*" 204 - Nessun contenuto 200 - OK
--if-match = "xyz" 204 - Nessun contenuto 200 - OK O 412 - Precondizione non riuscita

Scenario 1: : BadRequest l'intestazione --if-none-match non è vuota o non è impostata su *

In questo modo non vengono eseguiti i controlli di prevalidazione. L'intestazione --if-none-match può essere vuota o assumere il valore di *.

Scenario 2: BadRequest - --if-match l'intestazione non è vuota E --if-none-match l'intestazione è *

In questo modo non vengono eseguiti i controlli di prevalidazione. Non è possibile usare contemporaneamente entrambe le intestazioni.

Scenario 3: PreConditionFailed - --if-none-match è * e la risorsa specificata esiste già

La richiesta viene rifiutata se un * (carattere jolly di qualsiasi valore) viene passato nell'intestazione --if-none-match e la risorsa esiste già.

Scenario 4: - PreConditionFailed Il valore dell'intestazione --if-match non corrisponde al valore eTag più recente della risorsa

La richiesta viene rifiutata se l'intestazione specificata non corrisponde al valore eTag. È necessaria una nuova operazione GET per ottenere l'eTag più recente nella risorsa e aggiornare il valore dell'intestazione nella richiesta.

  • Last updated on