-
Notifications
You must be signed in to change notification settings - Fork 526
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
Kubelet volume relabel fails for Dynatrace OneAgent CSI volumes #2556
Comments
Thanks for the issue. We'll take a closer look. In the meantime, if you are able to reach the admin container on the host, can you try retrieving system logs and checking what AVC denial messages show up? Here is one of the ways to gather logs on Bottlerocket: https://github.com/bottlerocket-os/bottlerocket#logs. |
These are the messages logged repeatedly:
Do you need the archive from |
What is the backing storage for OneAgent CSI volumes like this?
Based on the logs, I would guess that it might be backed directly by a host directory bind-mounted into the CSI driver, which is then bind-mounted onto the pod's mount point. Ideally the pod's CSI volume mount will need to start with a |
Your analysis is correct. The details to this are:
This saves (a) network bandwidth as agents get downloaded only once per node, and (b) disk storage (~800MB) per pod. Switching from
Is this configuration supposed to work? It does on AL2. |
Ideally the configuration would work on Bottlerocket. AL2 doesn't enable or enforce SELinux by default, and might not have a policy that covers this specific interaction, so it's not a 1:1 comparison.
That seems like progress of sorts, since that relabel transition is something that it might make sense for the SELinux policy to permit. A privileged subject ( Or in other words, allowing this type of relabel would make it so only containers within the pod could access the volume, or privileged containers, rather than any unprivileged pod on the system. Is this where I would change data-dir to an Also, is the |
Yes, you identified the right spot. The switch to Alternatives to
|
Ah, I had missed that overlayfs was in use. That explains one of the oddities - why even though However, the use of overlayfs makes me doubt that enabling the relabel operation to succeed is actually desirable here. Bottlerocket's kernel doesn't enable the "metadata only copy up" feature by default ( The better path might be to convince |
Making the mount read-only is be possible indeed. Would that be enough to stop kubelet from relabeling? What is necessary to stop kubelet from relabeling? |
From a quick look at the code, it isn't clear to me that kubelet would skip marking the volume for relabeling if it was read-only, but it seems like it'd be a bug in the CRI implementation in containerd if it actually tries to relabel a read-only volume. |
I've verified that It looks like this might only be true when the volume is marked as |
Can confirm that a read-only volume is not subject of relabeling. The proof of concept was successful. Thanks for your support. |
Image I'm using:
Bottlerocket OS 1.10.1 (aws-k8s-1.23)
What I expected to happen:
Dynatrace OneAgent CSI volumes work on Bottlerocket.
What actually happened:
Init:CreateContainerError
.Additional nodes:
How to reproduce the problem:
applicationMonitoring
:The text was updated successfully, but these errors were encountered: