Problembehandlung des SubnetIsFull-Fehlercodes beim AKS-Cluster-Upgrade

Zusammenfassung

In diesem Artikel wird erläutert, wie Sie den SubnetIsFull-Fehler identifizieren und beheben, der beim Upgrade des Azure Kubernetes Service (AKS)-Clusters auftritt. Es hilft Ihnen, das Upgrade erfolgreich abzuschließen.

Hier sehen Sie ein Beispiel für die Fehlermeldung:

Fehler beim Skalieren des Knotenpools <AGENT_POOL_NAME> im Kubernetes-Dienst "<NAME>". Fehler: Fehler beim Wiederholen von VMSSAgentPoolReconciler: Code='SubnetIsFull' Message='<SUBNETZNAME>\ mit Adresspräfix <PRÄFIX>\ hat nicht genügend Kapazität für IP-Adressen.' Details=[]

Voraussetzungen

Dieser Artikel erfordert Azure CLI Version 2.0.65 oder eine höhere Version. Führen Sie az --version aus, um die Versionsnummer zu finden. Wenn Sie Azure CLI installieren oder aktualisieren müssen, lesen Sie Wie installieren Sie die Azure CLI.

Ausführlichere Informationen zum Upgradeprozess finden Sie im Abschnitt "Upgrade eines AKS-Clusters" in Upgrade an Azure Kubernetes Service (AKS)-Cluster.

Symptome

Ein Upgrade des AKS-Clusters schlägt fehl, und es erscheint eine Fehlermeldung "SubnetIsFull".

Ursache

Dieser Fehler tritt auf, wenn Ihr Cluster nicht über genügend IP-Adressen verfügt, um einen neuen Knoten zu erstellen.

Berücksichtigen Sie beim Planen eines Upgrade- oder Skalierungsvorgangs die Anzahl der erforderlichen IP-Adressen. Wenn der im Cluster konfigurierte IP-Adressbereich nur eine feste Anzahl von Knoten unterstützt, schlägt der Upgrade- oder Skalierungsvorgang fehl. Weitere Informationen finden Sie unter IP-Adressplanung für Ihre Azure Kubernetes Service (AKS)-Cluster.

Überprüfen der verfügbaren IPs im Subnetz

Bevor Sie Korrekturmaßnahmen ergreifen, überprüfen Sie, wie viele IP-Adressen im Subnetz verfügbar sind, das Ihrem AKS-Cluster zugeordnet ist.

So überprüfen Sie die verfügbaren IP-Adressen im Azure-Portal:

1. Wechseln Sie zum Dienst "Virtuelle Netzwerke ".
2. Wählen Sie das virtuelle Netzwerk aus, das Ihrem AKS-Cluster zugeordnet ist.
3. Wählen Sie im Menü "Subnetze" aus.
4. Überprüfen Sie die Spalte "Verfügbare IPs " für das Subnetz, das Ihr Cluster verwendet.

Alternativ können Sie die folgenden Azure CLI Befehle ausführen, um die verfügbaren IPs zu überprüfen:

# Get the subnet resource ID for the node pool.
# For clusters that use a custom VNet, the subnet ID is stored in the agent pool profile:
SUBNET_ID=$(az aks show \
    --resource-group <RESOURCE_GROUP> \
    --name <CLUSTER_NAME> \
    --query "agentPoolProfiles[0].vnetSubnetId" \
    --output tsv)

# If the cluster uses a managed VNet (SUBNET_ID is empty),
# retrieve the subnet from the node resource group instead:
if [[ -z "$SUBNET_ID" ]]; then
    NODE_RESOURCE_GROUP=$(az aks show \
        --resource-group <RESOURCE_GROUP> \
        --name <CLUSTER_NAME> \
        --query "nodeResourceGroup" \
        --output tsv)

    SUBNET_ID=$(az network vnet list \
        --resource-group "$NODE_RESOURCE_GROUP" \
        --query "[0].subnets[0].id" \
        --output tsv)
fi

# Display the subnet details and calculate available IPs
az network vnet subnet show \
    --ids "$SUBNET_ID" \
    --query "{SubnetName:name, AddressPrefix:addressPrefix, UsedIPs:length(ipConfigurations || \`[]\`)}" \
    --output json | jq -r '
    .AddressPrefix as $prefix |
    ($prefix | split("/")[1] | tonumber) as $prefixLen |
    pow(2; 32 - $prefixLen) as $totalIPs |
    5 as $reserved |
    (.UsedIPs // 0) as $used |
    ($totalIPs - $reserved - $used) as $available |
    ["SubnetName", "AddressPrefix", "TotalIPs", "UsedIPs", "AzureReserved", "AvailableIPs"],
    [.SubnetName, $prefix, ($totalIPs | tostring), ($used | tostring), ($reserved | tostring), ($available | tostring)]
    | @tsv' | column -t

Die Ausgabe ähnelt dem folgenden Beispiel:

SubnetName  AddressPrefix  TotalIPs  UsedIPs  AzureReserved  AvailableIPs
aks-subnet  xx.xxx.x.x/16  65536     327      5              65204

Wenn die Anzahl der verfügbaren IPs niedrig ist (z. B. weniger als die Anzahl der Knoten, die Sie während des Upgrades hinzufügen), fahren Sie mit der Lösung im nächsten Abschnitt fort.

Lösung

Reduzieren Sie die Clusterknoten, um IP-Adressen für das Upgrade zu reservieren.

Wenn die Skalierung nicht eine Option ist und Ihr virtueller Netzwerk-CIDR über genügend IP-Adressen verfügt, versuchen Sie, einen Knotenpool mit einem eindeutigen Subnetz hinzuzufügen:

1. Fügen Sie einen neuen Benutzerknotenpool im virtuellen Netzwerk in einem größeren Subnetz hinzu.
2. Wechseln Sie den ursprünglichen Knotenpool zu einem Systemknotenpooltyp.
3. Skalieren Sie den Benutzerknotenpool.
4. Skalieren Sie den ursprünglichen Knotenpool nach unten.

Wiederherstellung, wenn sich der Knotenpool im Status "Fehlgeschlagene Bereitstellung" befindet

Wenn ein Upgrade mit SubnetIsFull fehlschlägt, können der betroffene AKS-Knotenpool und die zugrunde liegende VMSS (Virtual Machine Scale Set) im Bereitstellungsstatus Failed verbleiben. Führen Sie Folgendes aus, um den Status zu überprüfen:

az aks nodepool show \
    --resource-group <RESOURCE_GROUP> \
    --cluster-name <CLUSTER_NAME> \
    --name <NODEPOOL_NAME> \
    --query "provisioningState" \
    --output tsv

Nachdem sich der Knotenpool in diesem Zustand befindet:

• Weitere Vorgänge für denselben Knotenpool (z. B. az aks nodepool scale, az aks nodepool upgrade oder ein erneuter Versuch des ursprünglichen Upgrades) sind nicht garantiert erfolgreich, selbst nachdem durch das Herunterskalieren anderer Knotenpools IP-Adressen freigegeben wurden.
• Das Freigeben von IP-Adressen nach dem Ausfall ist für sich genommen kein zuverlässiger Wiederherstellungsmechanismus.

Der empfohlene Wiederherstellungspfad besteht darin, einen neuen Knotenpool in einem Subnetz mit ausreichender IP-Kapazität hinzuzufügen und Workloads aus dem fehlgeschlagenen Pool zu verschieben:

1. Fügen Sie einen neuen Knotenpool in einem Subnetz hinzu, das über genügend freie IPs für die Anzahl und maxPods Einstellung des Zielknotens verfügt. Siehe Hinzufügen eines Knotenpools mit einem eindeutigen Subnetz.
2. Knoten absperren und Workloads aus dem ausgefallenen Knotenpool evakuieren, damit sie im neuen Knotenpool neu eingeplant werden.
3. Löschen Sie den fehlgeschlagenen Knotenpool mithilfe von az aks nodepool delete.
4. Planen Sie zukünftige Upgrades mithilfe der IP-Adressplanung für AKS-Cluster , um Wiederholungen zu vermeiden.

Resources

• UngenügendeSubnetzGröße-Fehlercode