-
Notifications
You must be signed in to change notification settings - Fork 536
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
csi-rbdplugin not picking up mapOptions properly #3076
Comments
Cc @pkalever |
For the default mounter the mounter option will not be set in the storageclass and as it is not available in the storageclass same will not be set in the volume context, Because of this the mapOptions are getting discarded. If the mounter is not set assuming it's an rbd mounter. Note:- If the mounter is not set in the storageclass we can set it in the volume context explicitly, Doing this check-in node server to support backward existing volumes and the check is minimal we are not altering the volume context. fixes: ceph#3076 Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
For the default mounter the mounter option will not be set in the storageclass and as it is not available in the storageclass same will not be set in the volume context, Because of this the mapOptions are getting discarded. If the mounter is not set assuming it's an rbd mounter. Note:- If the mounter is not set in the storageclass we can set it in the volume context explicitly, Doing this check-in node server to support backward existing volumes and the check is minimal we are not altering the volume context. fixes: ceph#3076 Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
For the default mounter the mounter option will not be set in the storageclass and as it is not available in the storageclass same will not be set in the volume context, Because of this the mapOptions are getting discarded. If the mounter is not set assuming it's an rbd mounter. Note:- If the mounter is not set in the storageclass we can set it in the volume context explicitly, Doing this check-in node server to support backward existing volumes and the check is minimal we are not altering the volume context. fixes: ceph#3076 Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
I just had a similar error when setting up a K8s on a newer Flatcar server, because that one now uses ceph-csi/internal/util/pidlimit.go Line 39 in 1bd6297
/sys/fs/cgroup/pids any more.It's now /sys/fs/cgroup + *.scope + /pids.max
|
@Cytrian would you like to send a PR to fix this one? |
Ah so based on the PR for the mount issue I can see a workaround for now is to explicitly set the mounter parameter. Was able to get up and running with that for now! |
Yes that will be the workaround for now 👍 |
This isn't as simple as just changing the path; it should first detect whether we're using cgroups v1 or v2 (e.g. like here: https://github.com/containers/common/blob/a2ec40df56de42ebce03c1198495a79c2873b06e/pkg/cgroups/cgroups_supported.go#L28-L39 ), and use the correct path. |
For the default mounter the mounter option will not be set in the storageclass and as it is not available in the storageclass same will not be set in the volume context, Because of this the mapOptions are getting discarded. If the mounter is not set assuming it's an rbd mounter. Note:- If the mounter is not set in the storageclass we can set it in the volume context explicitly, Doing this check-in node server to support backward existing volumes and the check is minimal we are not altering the volume context. fixes: ceph#3076 Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
For the default mounter the mounter option will not be set in the storageclass and as it is not available in the storageclass same will not be set in the volume context, Because of this the mapOptions are getting discarded. If the mounter is not set assuming it's an rbd mounter. Note:- If the mounter is not set in the storageclass we can set it in the volume context explicitly, Doing this check-in node server to support backward existing volumes and the check is minimal we are not altering the volume context. fixes: #3076 Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
For the default mounter the mounter option will not be set in the storageclass and as it is not available in the storageclass same will not be set in the volume context, Because of this the mapOptions are getting discarded. If the mounter is not set assuming it's an rbd mounter. Note:- If the mounter is not set in the storageclass we can set it in the volume context explicitly, Doing this check-in node server to support backward existing volumes and the check is minimal we are not altering the volume context. fixes: #3076 Signed-off-by: Madhu Rajanna <madhupr007@gmail.com> (cherry picked from commit 7067456)
For the default mounter the mounter option will not be set in the storageclass and as it is not available in the storageclass same will not be set in the volume context, Because of this the mapOptions are getting discarded. If the mounter is not set assuming it's an rbd mounter. Note:- If the mounter is not set in the storageclass we can set it in the volume context explicitly, Doing this check-in node server to support backward existing volumes and the check is minimal we are not altering the volume context. fixes: #3076 Signed-off-by: Madhu Rajanna <madhupr007@gmail.com> (cherry picked from commit 7067456)
For the default mounter the mounter option will not be set in the storageclass and as it is not available in the storageclass same will not be set in the volume context, Because of this the mapOptions are getting discarded. If the mounter is not set assuming it's an rbd mounter. Note:- If the mounter is not set in the storageclass we can set it in the volume context explicitly, Doing this check-in node server to support backward existing volumes and the check is minimal we are not altering the volume context. fixes: #3076 Signed-off-by: Madhu Rajanna <madhupr007@gmail.com> (cherry picked from commit 7067456)
Describe the bug
I have a volume which is failing to mount, I believe because I have network encryption enabled on the cluster and the rbdplugin is not properly passing mapOptions through to the rbd command (to set
ms_mode=secure
).Environment details
fuse
orkernel
. for rbd itskrbd
orrbd-nbd
) : krbdSteps to reproduce
Steps to reproduce the behavior:
Actual results
The PersistentVolume was created, and has mapOptions set as expected in VolumeAttributes:
The PersistentVolumeClaim is created pointing to that PersistentVolume
However, the volume fails to mount to the pod:
Notably it is not passing
mapOptions
through to therbd
call here - which I believe to be required because I configured the cluster with network encryption enabled.Expected behavior
I expected the rbdplugin to pass the mapOptions through to the rbd map command and successfully mount the image.
Logs
RBD plugin logs:
The map errors repeat regularly as kubernetes continues attempting to mount the volume.
I don't think the PID limit error
E0503 03:53:25.631272 2218477 cephcsi.go:196] Failed to get the PID limit, can not reconfigure: could not find a cgroup for 'pids'
has anything to do with this, though I also had a hard time finding any information about what's going on there.Driver Registrar logs:
I couldn't find any dmesg logs that seemed at all related to the issue, and I also couldn't find any other logs that might indicate why the options weren't being populated.
Additional context
I also tried this with a few different configurations, including various combinations of:
kubeadm
created (single node as well) cluster with v1.23 of kuberetes(though I didn't have the foresight to record the specific version of the ceph-csi plugin image in some of the other cases)
To confirm that not passing the mapOptions was the issue, I connected to the rbdplugin pod:
Snagged a keyfile:
And ran the rbd map command which failed as per the logs, but with the missing
ms_mode=secure
option:Which succeeded
In case it's relevant or helpful (since this was setup with rook), here's more details on the rbdplugin pod:
The text was updated successfully, but these errors were encountered: