Fix cilium installation in GCloud beta "rapid" channel #9959
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
joestringer
added
pending-review
sig/k8s
|
Release note label not set, please set the appropriate release note. |
2 similar comments
|
Release note label not set, please set the appropriate release note. |
|
Release note label not set, please set the appropriate release note. |
joestringer
added
the
release-note/bug
joestringer
changed the title
If the nodeinit script runs somewhere where the BPFFS is already mounted, then it is highly likely that existing infrastructure handles the auto-mounting of the BPF filesystem to /sys/fs/bpf, for instance because they are running systemd 239 or later. In this case, don't always create the BPFFS mount unit configuration for systemd, otherwise systemd may reject it with: Failed to start sys-fs-bpf.mount: Unit sys-fs-bpf.mount has a bad unit file setting. This is because systemd has deemed the BPFFS mounting to be within its own domain of control, and that others should not configure it. This caused issues in beta gcloud environments where the nodeinit would fail because the systemd mount unit would not mount. This prevented configuration of the kubelet on each node, meaning that Cilium would not be configured as the CNI in the environment. However, the Cilium DS itself would run, leading to situations where pods would attempt to connect to remote services (eg kube-dns to the APIserver) and fail to connect in an environment where the Cilium agents themselves otherwise appear to be healthy. A cursory investigation of `cilium endpoint list` in such environments would clearly show that no pods are being managed by Cilium. Fixes: cilium#9556 Signed-off-by: Joe Stringer <joe@cilium.io>
joestringer
force-pushed
the
submit/fix-gke-rapid
branch
from
60f8497
to
79d2ef2
Compare
|
test-me-please EDIT: Only these failed: So, not consistently (1 per k8s version), and not related to BPFFS (restore etc). I'm not even sure where nodeinit is used in the CI. k8s tests with other versions all passed though so I think it's good from CI perspective. |
tgraf
approved these changes
Jan 24, 2020
maintainer-s-little-helper
bot
moved this from Needs backport from master
to Backport pending to v1.6
in 1.6.6
maintainer-s-little-helper
bot
moved this from Needs backport from master
to Backport pending to v1.6
in 1.6.6
maintainer-s-little-helper
bot
moved this from Backport pending to v1.6
to Backport done to v1.6
in 1.6.6
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If the nodeinit script runs somewhere where the BPFFS is already
mounted, then it is highly likely that existing infrastructure handles
the auto-mounting of the BPF filesystem to /sys/fs/bpf, for instance
because they are running systemd 239 or later.
In this case, don't always create the BPFFS mount unit configuration for
systemd, otherwise systemd may reject it with:
This is because systemd has deemed the BPFFS mounting to be within its
own domain of control, and that others should not configure it.
This caused issues in beta gcloud environments where the nodeinit would
fail because the systemd mount unit would not mount. This prevented
configuration of the kubelet on each node, meaning that Cilium would not
be configured as the CNI in the environment. However, the Cilium DS
itself would run, leading to situations where pods would attempt to
connect to remote services (eg kube-dns to the APIserver) and fail to
connect in an environment where the Cilium agents themselves otherwise
appear to be healthy. A cursory investigation of
cilium endpoint listin such environments would clearly show that no pods are being managed
by Cilium.
Fixes: #9556
This change is