Condividi tramite

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 oppure un *.

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 gli ETag nelle intestazioni dell'operazione

Le intestazioni sono facoltative. Gli esempi seguenti mostrano come utilizzare le intestazioni –-if-match e -–if-none-match.

Esempio 1: il seguente comando CLI aggiorna un cluster esistente MyManagedCluster se l'eTag corrisponde a yvjvt

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

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

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

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. Entrambe le intestazioni non possono essere usate contemporaneamente.

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

La richiesta viene rifiutata se viene passato un valore jolly qualsiasi 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.