After the userns PR got merged:
https://github.com/kubernetes/kubernetes/pull/111090
gnufied decided it might be safer if we feature gate this part of the
code, due to the kubelet volume host type assertion.
That is a great catch and this patch just moves the code inside the
feature gate if.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
This commit only changes the UID/GID if user namespaces is enabled. When
it is enabled, it changes it so the hostUID and hostGID that are mapped
to the currently used UID/GID. This is needed so volumes are created
with the hostUID/hostGID and the user inside the container can read
them.
If user namespaces are disabled for this pod, this is a no-op: there is
no user namespace mapping, so the hostUID/hostGID are the same as inside
the container.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
This resolves a couple of issues for CSI volume reconstruction.
1. IsLikelyNotMountPoint is known not to work for bind mounts and was
causing problems for subpaths and hostpath volumes.
2. Inline volumes were failing reconstruction due to calling
GetVolumeName, which only works when there is a PV spec.
klog.Infof expects a format string as first parameter and then
expands format specifies inside it. What gets passed here
is the final string that must be logged as-is, therefore
klog.Info has to be used.
Signed-off-by: yuswift <yuswift2018@gmail.com>
This patch aims to simplify decoupling "pkg/scheduler/framework/plugins"
from internal "k8s.io/kubernetes" packages. More described in
issue #89930 and PR #102953.
Some helpers from "k8s.io/kubernetes/pkg/controller/volume/persistentvolume"
package moved to "k8s.io/component-helpers/storage/volume" package:
- IsDelayBindingMode
- GetBindVolumeToClaim
- IsVolumeBoundToClaim
- FindMatchingVolume
- CheckVolumeModeMismatches
- CheckAccessModes
- GetVolumeNodeAffinity
Also "CheckNodeAffinity" from "k8s.io/kubernetes/pkg/volume/util"
package moved to "k8s.io/component-helpers/storage/volume" package
to prevent diamond dependency conflict.
Signed-off-by: Konstantin Misyutin <konstantin.misyutin@huawei.com>
If unmount device succeeds but somehow unmount operation
fails because device was in-use elsewhere, we should mark the
device mount as uncertain because we can't use the global
mount point at this point.
In the following code pattern, the log message will get logged with v=0 in JSON
output although conceptually it has a higher verbosity:
if klog.V(5).Enabled() {
klog.Info("hello world")
}
Having the actual verbosity in the JSON output is relevant, for example for
filtering out only the important info messages. The solution is to use
klog.V(5).Info or something similar.
Whether the outer if is necessary at all depends on how complex the parameters
are. The return value of klog.V can be captured in a variable and be used
multiple times to avoid the overhead for that function call and to avoid
repeating the verbosity level.
During volume detach, the following might happen in reconciler
1. Pod is deleting
2. remove volume from reportedAsAttached, so node status updater will
update volumeAttached list
3. detach failed due to some issue
4. volume is added back in reportedAsAttached
5. reconciler loops again the volume, remove volume from
reportedAsAttached
6. detach will not be trigged because exponential back off, detach call
will fail with exponential backoff error
7. another pod is added which using the same volume on the same node
8. reconciler loops and it will NOT try to tigger detach anymore
At this point, volume is still attached and in actual state, but
volumeAttached list in node status does not has this volume anymore, and
will block volume mount from kubelet.
The fix in first round is to add volume back into the volume list that
need to reported as attached at step 6 when detach call failed with
error (exponentical backoff). However this might has some performance
issue if detach fail for a while. During this time, volume will be keep
removing/adding back to node status which will cause a surge of API
calls.
So we changed to logic to check first whether operation is safe to retry which
means no pending operation or it is not in exponentical backoff time
period before calling detach. This way we can avoid keep removing/adding
volume from node status.
Change-Id: I5d4e760c880d72937d34b9d3e904ecad125f802e
This cleans up a log message that looks like:
I0312 14:36:50.280018 12866 operation_generator.go:869] UnmountDevice succeeded for volume "my-volume" %!(EXTRA string=UnmountDevice succeeded for volume "my-volume" (UniqueName: "kubernetes.io/csi/smb.csi.k8s.io^my-volume") on node "my-node")
should mark volume mount in actual state even if volume expansion fails so that
reconciler can tear down the volume when needed. To avoid pods start
using it, mark volume as uncertain instead of mounted.
Will add unit test after the logic is reviewed.
Change-Id: I5aebfa11ec93235a87af8f17bea7f7b1570b603d
