Verbessern der Parallelitätssteuerung mit Entitätstags (eTags) in Azure Kubernetes Service

Um widersprüchliche Anforderungen in Azure Kubernetes Service (AKS) zu verhindern, dienen eTags (Entity Tags) als eindeutige Bezeichner, die die Parallelitätssteuerung aktivieren. Wenn eine Anforderung an den Cluster erfolgt, überprüft das System, ob das angegebene eTag mit der neuesten Version übereinstimmt, die in der Datenbank gespeichert ist. Wenn eine Diskrepanz auftritt, schlägt die Anforderung frühzeitig fehl, um sicherzustellen, dass keine unbeabsichtigten Überschreibungen erfolgen.

Verwenden von eTag-Headern

Es gibt zwei Optionen zum Anwenden von eTags über Kopfzeilen:

–-if-match Header: Stellt sicher, dass der Vorgang nur ausgeführt wird, wenn das vorhandene eTag mit dem in diesem Header angegebenen Wert übereinstimmt.

–-if-none-match Header: Stellt sicher, dass der Vorgang nur ausgeführt wird, wenn keiner der eTags mit dem in diesem Header angegebenen Wert übereinstimmt. Dieser Kopfzeilentyp kann nur leer oder ein * sein.

Suchen vorhandener ETags

Sie können entweder einen LIST- oder einen GET-Aufruf Ihres Clusters oder Knotenpools ausführen, um das vorhandene ETag anzuzeigen. Ein ETag sieht ungefähr wie im folgenden Beispiel aus:

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

Was würde vorhandene ETags ändern?

ETags können auf Cluster- und Agentpoolebene vorhanden sein. Je nach Umfang der ausgeführten Vorgänge können Sie das entsprechende eTag übergeben. Wenn Sie einen Vorgang auf Clusterebene ausführen, werden sowohl das eTag auf Clusterebene als auch das eTag des Agentpools aktualisiert. Wenn Sie eine Aktion im Agent-Pool ausführen, wird nur das eTag des Agent-Pools aktualisiert.

Einfügen von ETags in die Vorgangskopfzeilen

Kopfzeilen sind optional zu verwenden. Die folgenden Beispiele zeigen, wie Sie die Kopfzeilen –-if-match und -–if-none-match verwenden.

Beispiel 1: Der folgende CLI-Befehl löscht einen vorhandenen Cluster MyManagedCluster wenn das eTag übereinstimmt mit yvjvt

Angenommen, Sie möchten einen AKS-Cluster mithilfe des eTags löschen. (Ersetzen Sie "yvjvt" zur Veranschaulichung den tatsächlichen eTag-Wert, den Sie aus der Ressource abgerufen haben.)

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

Beispiel 2: Der folgende CLI-Befehl erstellt einen neuen Cluster. Wenn * im –if-none-match Header angegeben wird, bedeutet dies, dass überprüft werden soll, ob die Ressource nicht vorhanden ist.

Erstellen Sie zunächst eine Ressourcengruppe:

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

Erstellen Sie dann einen neuen AKS-Cluster mit einem zufälligen Suffix, um die Eindeutigkeit sicherzustellen:

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

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

Ergebnisse:

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

Konfigurationen und erwartetes Verhalten

In der folgenden Tabelle wird das erwartete Verhalten von HTTP-Vorgängen (PUT, PATCH und DELETE) basierend auf verschiedenen eTag-Konfigurationen und ressourcenbasiertem Vorhandensein beschrieben. Sie zeigen, wie sich das Vorhandensein von --if-match Oder --if-none-match Headern auf die Antwortstatuscodes auswirkt, um die Parallelitätssteuerung sicherzustellen und unbeabsichtigte Änderungen zu verhindern.

PUT Ressource ist nicht vorhanden Ressource ist vorhanden
--if-match = "" 201 – Erstellt 200 - Ok
--if-match = "*" 412 – Fehler bei der Vorbedingung 200 - OK
--if-match = "xyz" 412 – Fehler bei der Vorbedingung 200 - OK ODER 412 - Vorbedingung fehlgeschlagen
--if-none-match = "*" 201 – Erstellt 412 – Fehler bei der Vorbedingung
Patch Ressource ist nicht vorhanden Ressource ist vorhanden
--if-match = "" 404 - Nicht gefunden 200 - OK
--if-match = "*" 404 - Nicht gefunden 200 - OK
--if-match = "xyz" 404 - Nicht gefunden 200 - OK ODER 412 - Vorbedingung fehlgeschlagen
DELETE Ressource ist nicht vorhanden Ressource ist vorhanden
--if-match = "" 204 - Kein Inhalt 200 - OK
--if-match = "*" 204 - Kein Inhalt 200 - OK
--if-match = "xyz" 204 - Kein Inhalt 200 - OK ODER 412 - Vorbedingung fehlgeschlagen

Szenario 1: BadRequest – die --if-none-match Kopfzeile ist entweder nicht leer oder nicht auf * gesetzt.

Dies schlägt die Vorabvalidierungsprüfungen fehl. Der --if-none-match Header darf entweder leer sein oder den Wert * haben.

Szenario 2: BadRequest - --if-match Kopfzeile ist nicht leer UND kopfzeile ist --if-none-match*

Dies schlägt die Vorabvalidierungsprüfungen fehl. Beide Header können nicht gleichzeitig verwendet werden.

Szenario 3: PreConditionFailed - --if-none-match ist und die angegebene Ressource bereits vorhanden ist *

Die Anforderung wird abgelehnt, wenn ein * (Wildcard für beliebige Werte) in den --if-none-match-Header übergeben wird und die Ressource bereits vorhanden ist.

Szenario 4: PreConditionFailed – Der Wert der --if-match Kopfzeile stimmt nicht mit dem neuesten eTag-Wert der Ressource überein.

Die Anforderung wird abgelehnt, wenn der bereitgestellte Header nicht mit dem eTag-Wert übereinstimmt. Ein neuer GET-Vorgang ist erforderlich, um das neueste eTag für die Ressource abzurufen und den Headerwert in der Anforderung zu aktualisieren.

  • Zuletzt aktualisiert um