You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
rebuilt my container images based on mcr.microsoft.com/windows/servercore:ltsc2022 instead of mcr.microsoft.com/windows/servercore:ltsc2019
I noticed my Windows pods can no longer mount volumes as containers-local D: or Z: drives.
My cluster PV-s are provisioned from Azure File shares and pods mount, but that should not be relevant here.
My current AKS is running containerd v 1.6.14, great, I should be able fine, but I'm not. Apparently, the bug is not being fixed until containerd 1.7 as per this containerd/containerd#6589 (comment)
After switching to containerd CRI, I expect to be still able to mount volumes as non-C: drives on my Windows pods.
Environment (please complete the following information):
Kubernetes version: 1.25.5
containerd version: 1.6.14
Additional context
There seem to be number of issues about this problem, but none reported directly here, to AKS repository - how on earth this cotainerd bug has slipped through AKS QA? IMHO, this makes containerd not ready to force it as default on latest AKS, does it?
It turns out the containerd trips over use of VOLUME directive used in Dockerfile of my custom images.
This was not caused any problems on AKS cluster based on Docker-based CRI:
# Document volume mount points typically mounted from Azure file shares.
VOLUME ["D:", "Z:"]
UPDATE: I submitted a bug report about it to conainerd here containerd/containerd#8171 and I'm closing this issue here. My apologies for the noise, but it took me rookie a while to track the problem down.
Describe the bug
Recently, after I have
mcr.microsoft.com/windows/servercore:ltsc2022
instead ofmcr.microsoft.com/windows/servercore:ltsc2019
I noticed my Windows pods can no longer mount volumes as containers-local
D:
orZ:
drives.My cluster PV-s are provisioned from Azure File shares and pods mount, but that should not be relevant here.
After a lengthy research, I found that the problem is most likely due to the known bug in
containerd
, namely mountPath behavior changed from docker to containerd on Windows #6589One comment in that bug report suggest the bug has been fixed in containerd 1.6.6, see containerd/containerd#6589 (comment)
My current AKS is running
containerd v 1.6.14
, great, I should be able fine, but I'm not. Apparently, the bug is not being fixed until containerd 1.7 as per this containerd/containerd#6589 (comment)To Reproduce
I believe it is not necessary to provide any steps here, as the containerd bug report should be sufficient confirmation, but here is a simple test deployment that is failing for me. I is based on slightly modified version of https://github.com/kubernetes-sigs/azurefile-csi-driver/tree/master/deploy/example/windows
Expected behavior
After switching to containerd CRI, I expect to be still able to mount volumes as non-
C:
drives on my Windows pods.Environment (please complete the following information):
Additional context
There seem to be number of issues about this problem, but none reported directly here, to AKS repository - how on earth this cotainerd bug has slipped through AKS QA? IMHO, this makes containerd not ready to force it as default on latest AKS, does it?
UPDATE: A workaround synthesized based on all those issue reports seems to be:
C:
drive, e.g.C:\D
subst
to associate those paths with drive letters, i.e.subst D: C:\D
C:
only.The text was updated successfully, but these errors were encountered: