-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Cilium no longer runs on Bottlerocket Linux as of 1.11.3 #19256
Comments
cc @aanm |
@alex-berger what's the output of |
@aanm bottlerocket has no tools on the host itself, not even |
Hey is this now a known issue? I'm experiencing errors install Cilium in a bottlerocket EKS node group as well and would like to know if I should debug harder or stop debugging because its broken. Thanks, |
I'm experiencing the same issue. @aanm is it a confirmed bug already? |
@ubaniabalogun @DamiaPoquet correct this is a confirmed bug |
You don't need
Edit:for completeness |
We expect to ship a fix for this in v1.13.2. |
This has been fixed as of 1.13.2, please refer to this comment for details: #15393 (comment) |
Is there an existing issue for this?
What happened?
With the changes introduced in #18897 the Cilium agent no longer starts on Bottlerocket Linux nodes.
This is because the node-init DaemonSet cannot write the timestamp to the
bootstrapFile
("/tmp/cilium-bootstrap-time") in https://github.com/cilium/cilium/blob/v1.11.3/install/kubernetes/cilium/files/nodeinit/startup.bash#L123 as there is nodate
command available on Bottlerocket Linux. Instead, it writes an emptybootstrapFile
, which in turn causes the test for a non-emptybootstrapFile
at https://github.com/cilium/cilium/blob/v1.11.3/install/kubernetes/cilium/templates/cilium-agent/daemonset.yaml#L386 to fail.Due to the above described problem, the agent is stuck forever waiting for the
bootstrapFile
to become non-empty, which will never happen.Cilium Version
1.11.3
Kernel Version
5.10.102
Kubernetes Version
1.21
Sysdump
No response
Relevant log output
Anything else?
Looks like this is related to #15393 and that the same work-around applies, disabling the node-init DaemonSet.
Code of Conduct
The text was updated successfully, but these errors were encountered: