This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(172.8, 90%, 26%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECF%3C/text%3E%3C/svg%3E)
We created a new AKS cluster on Kubernetes 1.33.x in Azure Public Cloud. Although CSI drivers are the standard storage interface in AKS (in‑tree drivers deprecated from v1.26 onward) and should be enabled/managed by AKS automatically, our cluster never deploys the csi-azuredisk-controller in kube-system. Only the csi-azuredisk-node DaemonSet is present. As a result, volume attach/detach does not use CSI and we cannot attach managed disks located in a Resource Group different from the node RG. Microsoft Learn states CSI is the supported path on AKS and replaces in‑tree drivers; the controller is required for attach/detach, snapshots, and resizing.
An Azure service that provides serverless Kubernetes, an integrated continuous integration and continuous delivery experience, and enterprise-grade security and governance.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(300.8, 8%, 39%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EHS%3C/text%3E%3C/svg%3E)
Hello Cartier,
Based on the behavior observed, this is not expected by design for AKS and indicates a platform‑side issue with the CSI driver deployment.
Starting with Kubernetes v1.26, CSI drivers are the only supported storage path in AKS. In‑tree Azure Disk drivers are deprecated.
For a healthy AKS cluster, both components must be present in the kube-system namespace:
In your AKS v1.33.x cluster, only the node DaemonSet is deployed, while the CSI controller is missing.
The CSI controller is mandatory for:
Because the controller is not deployed, CSI‑based attach/detach does not function correctly.
Note: Manual installation of the Azure Disk CSI controller is not supported on AKS. CSI drivers on AKS are fully managed by the AKS control plane, and customers should not deploy or modify them manually.
Temporary Guidance (Until Resolved)
Avoid scenarios that require:
Additionally, we have reached out to you via Private Message, requesting some details related to your subscription to ensure your privacy is protected. Kindly review and share the details.
Microsoft documentation:
Hello Cartier,
Just checking if provided response was helpful! please let me know if you have any queries.Additionally, we have reached out to you via Private Message, requesting some details related to your subscription to ensure your privacy is protected. Kindly review and share the details.
Hello Cartier,
Based on the logs you have shared, these errors are caused by loss of connectivity to the Kubernetes API server, not by any specific workload or application issue.
The repeated connection refused, i/o timeout, and request canceled errors across Pods, Nodes, ConfigMaps, CSI components, and the scheduler indicate that cluster system components are unable to reach the Kubernetes API server endpoint (hcp-kubernetes.*.svc.cluster.local:443).
When the API server is unreachable, controllers and informers fail to list/watch resources, scheduler leader‑election locks cannot be renewed, and authentication configuration lookups fail.
I think u’ve hit a bad control‑plane seed… if the azuredisk‑ctrl never comes up on a clean 1.33, the addon state is stuck upstream; just re-create once to confirm and open support so they re‑stamp it, and check nodeRG disk perms after so u don’t hit the next attach error.