Azure AKS集群从1.8.1升级至1.8.6失败求助

Let me break down what's going on here and walk you through actionable steps to resolve this failed upgrade. It's odd that the KubernetesVersion shows 1.8.6 but the ProvisioningState is stuck on Failed—this usually means the control plane might have upgraded successfully, but the agent pool nodes hit a snag, or there's a state sync issue on Azure's end.

First, Dig Into the Exact Failure Reason #

The correlation ID you provided (09312a25-04f3-4e35-8f79-6b2337bb7f19) is key here. Let's pull the detailed activity logs to see what went wrong during the upgrade:

az monitor activity-log list --resource-group myresourcegr --correlation-id 09312a25-04f3-4e35-8f79-6b2337bb7f19 --output json

Look for entries with status.value: Failed—they'll usually include a detailed error message (like node upgrade timeouts, insufficient resources, or image pull failures).

Check Agent Pool and Node Health #

Next, verify the state of your agent pool and nodes:

1. Check the agent pool's provisioning state:

   az aks show --name myaks --resource-group myresourcegr --query agentPoolProfiles[0].provisioningState
   

2. If you can still access the cluster, check node statuses:

   kubectl get nodes
   

   Look for nodes marked NotReady or Unknown—these are often the culprits.

Actionable Fixes to Try #

1. Force Agent Pool Sync (Same K8s Version) #

Since the control plane already reports 1.8.6, try re-syncing the agent pool nodes with a node-image-only upgrade (this won't change the K8s version but will trigger a fresh configuration sync):

az aks upgrade --name myaks --resource-group myresourcegr --kubernetes-version 1.8.6 --node-image-only

2. Fix Stuck Nodes #

If nodes are stuck in an unhealthy state:

• Delete the problematic node(s) using kubectl—AKS will automatically provision replacement nodes:

  kubectl delete node <node-name>
  

• Alternatively, scale the node pool down then back up to force a refresh:

  # Get your node pool name first
  az aks show --name myaks --resource-group myresourcegr --query agentPoolProfiles[0].name -o tsv
  # Replace <nodepool-name> and <current-count> below
  az aks scale --name myaks --resource-group myresourcegr --node-count $((<current-count>-1)) --nodepool-name <nodepool-name>
  az aks scale --name myaks --resource-group myresourcegr --node-count <current-count> --nodepool-name <nodepool-name>
  

3. Verify VMSS Health #

AKS uses Virtual Machine Scale Sets (VMSS) for agent nodes. Check if the VMSS itself is in a failed state:

# Get the VMSS name from your agent pool
VMSS_NAME=$(az aks show --name myaks --resource-group myresourcegr --query agentPoolProfiles[0].name -o tsv)
az vmss show --resource-group myresourcegr --name $VMSS_NAME --query provisioningState

If the VMSS is failed, you can try reimaging the instances:

az vmss reimage --resource-group myresourcegr --name $VMSS_NAME --instance-id <instance-id>

4. Reach Out to Azure Support #

If none of the above steps resolve the issue, this is likely a backend state synchronization problem. Open a support ticket with Azure, providing:

• The correlation ID 09312a25-04f3-4e35-8f79-6b2337bb7f19
• Output from az aks show and az aks get-versions
• The activity log details you pulled earlier

内容的提问来源于stack exchange，提问作者agalisteo