Do we need an easier way to load kernel modules on boot?

[foersleo]

Currently, Bottlerocket provides an easy way to block kernel modules from loading through settings.kernel.modules.<name>.allowed. Since version v.1.13 we also support loading modules through bootstrap containers, which shows to be a viable solution to issues like #2409 .

However, the bootstrap container approach puts extra burden on the user. They now have to maintain an extra container images and the user data parts to ensure that container image is configured as a bootstrap container.

So far I am not aware of use cases other than the ipvs module loading in #2409, but there may be more.

Should we include extra code to "force-load" kernel modules by specifying them through user data similar to the blocklisting? For example this could look like:

[settings.kernel.modules.ip_vs_lc]
autoload = true

[Raboo]

I would prefer direct support for loading kernel modules without bootstrap containers.

[tommie]

I'm loading br_netfilter manually, because kubeadm init fails a preflight check without it. Filed #3052 for it.

[foersleo]

This has been implemented with #3460 and is part of Bottlerocket v1.15.0 and later.

[foersleo]

As has been pointed out by @dmitrii-didenko , this is in fact not part of 1.15.0, but will be part of 1.16.0 (to be released soon, track in #3469 ). I am sorry for causing the confusion. Will chase down where I mixed things up here.

[Raboo]

Hi, doesn't #3391 remove the need altogether? Meaning it will auto load if kube-proxy is set to ipvs mode?

[foersleo]

I think this really depends on the k8s version in use. If I recall correctly, starting with k8s-1.27 the ipvs modules are loaded automatically. For previous versions kubeproxy would not do that and rely on modules being loaded. (I'd have to verify that this characterization is actually true. If I recall correctly from previous research into that, the older kubeproxy code would merely check if the modules are loaded and error out when that was not the case).

That being said, there may be other use cases where one would want to autoload a module that has nothing to do with ipvs. The autoload setting is generic and can be configured for any module available on disk.

[dmitrii-didenko]

@foersleo sorry, it seems like it's not available in 1.15. Could you help me to understand the possible release date for that feature?

[foersleo]

I am sorry @dmitrii-didenko it looks like I was confusing two things here and went ahead a bit too early. It will be part of the 1.16.0 release, which can be tracked here: #3469

Interestingly our documentation on bottlerocket.dev already mentions it in the API documentation for the 1.15.x series. Let me check why this got out of sync and see that I can get this fixed.

[foersleo]

We fixed the wrong documentation on the project website for now: bottlerocket-os/bottlerocket-project-website#331

Again, I am super sorry for the confusion and making false promises. You will have to wait for 1.16.0 to enjoy the new autoload setting.