kubeadm complains about bridge-nf-call and ip_forward if not using docker runtime #1062
Comments
neolit123
added
the
help wanted
|
Does not feel like a product bug, but documentation bug (just a missing manual). Current we have only pages on how to install kubernetes with kubeadm with docker as container runtime, we should have another one for cri-o. |
|
IMO kubeadm should at least do the modprobe itself. Whether it's the case for |
|
@vrothberg - what do you think? Should the above 2 conditions (modprobe and sysctl) be rectified automatically by kubeadm, or do you think this is something better handled in CRI-O? Docker does both automagically itself And if you think CRI-O proper shouldn't take care, where do you think the dirty hack should be carried in openSUSE? in the cri-o package or in the kubeadm package? ;) |
|
I think that’s something kubeadm package should do. After that, we can
check if that’s really an error or if it can be demoted to an info log.
Many things in K8s are still built around how Docker does things but
they’re not always necessary.
I am on vacation at the moment but will check mails here and then. Thanks
for the ping.
…On Wed 12. Sep 2018 at 10:30, Richard Brown ***@***.***> wrote:
@vrothberg <https://github.com/vrothberg> - what do you think? Should the
above 2 conditions (modprobe and sysctl) be rectified automatically by
kubeadm, or do you think this is something better handled in CRI-O?
Docker does both automagically itself
And if you think CRI-O proper shouldn't take care, where do you think the
dirty hack should be carried in openSUSE? in the cri-o package or in the
kubeadm package? ;)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1062 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALI4g1dRKf5vWXz_7H27VktuD8nP5tAsks5uaMYogaJpZM4V_W70>
.
|
|
This issue will be handled in openSUSE with the following changes: https://build.opensuse.org/package/rdiff/devel:kubic/kubernetes?linkrev=base&rev=9 I'm planning on submitting something similar in the upstream rpm packaging promptly |
…tables precheck error From this issue: kubernetes/kubeadm#1062 these files need to be added to prevent this precheck error (which occurs when running any container runtime that isn't docker). Also, save the machine config on the user's filesystem earlier so that the buildprovisioner can access it.
* Only restart docker service if container runtime is docker Only allow the buildroot provisioner to restart docker if the container runtime is docker. This change should fix the bug in #3424, since now docker will not be restarted if the container runtime is containerd. * Added files to fix FileContent--proc-sys-net-bridge-bridge-nf-call-iptables precheck error From this issue: kubernetes/kubeadm#1062 these files need to be added to prevent this precheck error (which occurs when running any container runtime that isn't docker). Also, save the machine config on the user's filesystem earlier so that the buildprovisioner can access it.
|
Restarting Docker did the trick...Thanks you |
|
I second adding this information to the setup page. I was seeing this error and it caused me at least 20 min of pain until I came across this thread. Thank you for sharing the solution. |
|
make sure that you follow the procedure then the error doesnt occour |
|
simply modprobe'ng things doesn't ensure they are running. If you reboot then everything breaks. It should tell you to make sure these things are enabled persistently. Which is does for the sysctl rules, but not the modules. When following the directions on stuff like this I don't like to read into things and try to take extra steps based on hunches. If it tells me to do something, I do it. If it doesn't I don't. I wait for things to break and go back and fix them. This way I have a better idea if it's bad documentation that is the problem instead of some random thing I did when things break. |
|
I probably need to rebuild my local Hyper-V node images. |
|
I just fresh installed a k8s 1.24 cluster with containerd as runtime engine, using latest kubeadm tooling and following step by step the installation procedure described in latest (1.24) k8s documentation; I experienced the problem reported in this issue when raising
So I understand this has not been solved yet ... P.S: It was an installation on Ubuntu-based Virtualbox VMs on a Windows10 host OS where Hyper-V has been fully disabled, so experienced issue is not related to any Hyper-V collision (not in my case). |
|
See https://kubernetes.io/docs/setup/production-environment/container-runtimes/#install-and-configure-prerequisites these are still required when setting up a CR that is k8s compatible. |
|
Thanks @neolit123 (yes, it is all there .. and I did not realize on it :-( |
The same pre-flight erros happened to me with kubeadm, cri-o, and kubelet on 1.22 For any one looking for a fast work around, this is the answer. |
|
thank u sir.......i am happy with ur solutions sir....tQ |
|
To make this boot-resistant, add Or into a dedicated file: This assumes you are using a Linux distribution with Systemd init, systemd-modules-load.service is responsible for loading these mentioned modules. |
|
Still getting the ip_forward error on Raspberry Pi OS (Debian 11) and Kube 1.26 Anyone got a boot-resistant solution for that one? |
|
An example from kubespray: https://github.com/kubernetes-sigs/kubespray/blob/36e5d742dc2b3f7984398c38009f236be7c3c065/Vagrantfile#L224. Another example in kubeadm blog: https://kubernetes.io/blog/2020/02/07/deploying-external-openstack-cloud-provider-with-kubeadm/#install-docker-and-kubernetes |
|
try |
Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug
What happened:
After booting a clean system, running
kubeadm initwith a CRI runtime other than docker configured produces the following pair of error messages:What you expected to happen:
Those two pre-flight checks to pass because they could be satisfied automatically.
Obviously, these are handled automatically by the starting of the
dockerdaemon normally, but for openSUSE Kubic we are investigating using CRI-O by default, where we do not have the luxury of an overbearing daemon to meddle with such things.Therefore this bug report is either an opportunity for kubeadm to handle things itself. I think there is a case to be that because kubeadm knows what it needs, kubeadm should
modprobe br_netfilterandecho '1' > /proc/sys/net/ipv4/ip_forwardautomatically rather than complaining about the issues.Alternatively, if this suggestion is not acceptable, I'd appreciate a suggestion as to how openSUSE Kubic should automatically address these issues in a way that will remain aligned with kubeadm's general expectations.
How to reproduce it (as minimally and precisely as possible):
--container-runtime=remote --container-runtime-endpoint=unix:///var/run/crio/crio.sock --runtime-request-timeout=15mkubeadm init --cri-socket /var/run/crio/crio.sockAnything else we need to know?:
Environment:
kubectl version): v1.11.2uname -a): 4.17.13The text was updated successfully, but these errors were encountered: