-
Notifications
You must be signed in to change notification settings - Fork 366
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
Talos Linux support #5707
Comments
I think we can take care of this by adding the right configuration options to the Helm chart. I see that Talos has installation instructions for Cilium, which includes the correct Helm values to provide: https://www.talos.dev/v1.5/kubernetes-guides/network/deploying-cilium/ 2 things I am not sure about:
|
|
When running on some K8s distributions, users may want to adjust the securityContext for antrea-agent containers. This is reserved for "power users", and most users should not modify the default values. When modifying the securityContext, some Antrea functions may break. For antrea-io#5707 Signed-off-by: Antonin Bas <abas@vmware.com>
When running on some K8s distributions, users may want to adjust the securityContext for antrea-agent containers. This is reserved for "power users", and most users should not modify the default values. When modifying the securityContext, some Antrea functions may break. For antrea-io#5707 Signed-off-by: Antonin Bas <abas@vmware.com>
When running on some K8s distributions, users may want to adjust the securityContext for antrea-agent containers. This is reserved for "power users", and most users should not modify the default values. When modifying the securityContext, some Antrea functions may break. For #5707 Signed-off-by: Antonin Bas <abas@vmware.com>
An update on this:
Footnotes
|
In order to support some specialized distributions, we may need to provide users with the ability to skip loading kernel modules. In particular, this is required to support Talos Linux (see antrea-io#5707). Signed-off-by: Antonin Bas <abas@vmware.com>
In order to support some specialized distributions, we may need to provide users with the ability to skip loading kernel modules. In particular, this is required to support Talos Linux (see antrea-io#5707). The Antrea Agent may try to load modules in 2 places: 1. in the install-cni initContainer: we try to load modules, mostly as a sanity check. If loading the openvswitch module fails, the container fails. 2. in the antrea-ovs container: this is outside of our direct control, but the ovs-ctl start script will try to load the openvswitch module if not detected. For install-cni, we introduce an environment variable, SKIP_LOADING_KERNEL_MODULES. If set, we do not run modprobe at all. For antrea-ovs, we introduce a new flag, `--skip-kmod`, to the start_ovs script. If provided, we ensure that ovs-ctl will not try to run modprobe, by replacing the ovs-kmod-ctl utility script by a no-op. To simplify usage, we introduce a new Helm configuration value, `agent.dontLoadKernelModules`. If set to true, we will take care of both configurations above. Note that even when skipping "explicit" Kernel module loading, the module will still be automatically loaded on the host when starting OVS if needed. This seems to be expected for recent Linux Kernel versions. With this change, Antrea can run on Talos Linux (confirmed with both the Docker and QEMU provisioners). Signed-off-by: Antonin Bas <abas@vmware.com>
In order to support some specialized distributions, we may need to provide users with the ability to skip loading kernel modules. In particular, this is required to support Talos Linux (see antrea-io#5707). The Antrea Agent may try to load modules in 2 places: 1. in the install-cni initContainer: we try to load modules, mostly as a sanity check. If loading the openvswitch module fails, the container fails. 2. in the antrea-ovs container: this is outside of our direct control, but the ovs-ctl start script will try to load the openvswitch module if not detected. For install-cni, we introduce an environment variable, SKIP_LOADING_KERNEL_MODULES. If set, we do not run modprobe at all. For antrea-ovs, we introduce a new flag, `--skip-kmod`, to the start_ovs script. If provided, we ensure that ovs-ctl will not try to run modprobe, by replacing the ovs-kmod-ctl utility script by a no-op. To simplify usage, we introduce a new Helm configuration value, `agent.dontLoadKernelModules`. If set to true, we will take care of both configurations above. Note that even when skipping "explicit" Kernel module loading, the module will still be automatically loaded on the host when starting OVS if needed. This seems to be expected for recent Linux Kernel versions. With this change, Antrea can run on Talos Linux (confirmed with both the Docker and QEMU provisioners). As part of this change, we also introduce the `agent.antreaOVS.extraEnv` Helm value, to inject arbitrary environment variables in the antrea-ovs container. This is for parity with other antrea-agent containers, and is not strictly required. Signed-off-by: Antonin Bas <abas@vmware.com>
In order to support some specialized distributions, we may need to provide users with the ability to skip loading kernel modules. In particular, this is required to support Talos Linux (see #5707). The Antrea Agent may try to load modules in 2 places: 1. in the install-cni initContainer: we try to load modules, mostly as a sanity check. If loading the openvswitch module fails, the container fails. 2. in the antrea-ovs container: this is outside of our direct control, but the ovs-ctl start script will try to load the openvswitch module if not detected. For install-cni, we introduce an environment variable, SKIP_LOADING_KERNEL_MODULES. If set, we do not run modprobe at all. For antrea-ovs, we introduce a new flag, `--skip-kmod`, to the start_ovs script. If provided, we ensure that ovs-ctl will not try to run modprobe, by replacing the ovs-kmod-ctl utility script by a no-op. To simplify usage, we introduce a new Helm configuration value, `agent.dontLoadKernelModules`. If set to true, we will take care of both configurations above. It will also cause the host's /lib/modules not not be mounted any more. Note that even when skipping "explicit" Kernel module loading, the module will still be automatically loaded on the host when starting OVS if needed. This seems to be expected for recent Linux Kernel versions. With this change, Antrea can run on Talos Linux (confirmed with both the Docker and QEMU provisioners). As part of this change, we also introduce the `agent.antreaOVS.extraEnv` Helm value, to inject arbitrary environment variables in the antrea-ovs container. This is for parity with other antrea-agent containers, and is not strictly required. Signed-off-by: Antonin Bas <abas@vmware.com>
Starting with Antrea v1.15, Antrea can be used as the CNI for Talos clusters. This requires custom Helm values. This support was tested using both the Docker provisioner and the QEMU provisioner. Fixes antrea-io#5707 Signed-off-by: Antonin Bas <abas@vmware.com>
Starting with Antrea v1.15, Antrea can be used as the CNI for Talos clusters. This requires custom Helm values. This support was tested using both the Docker provisioner and the QEMU provisioner. Fixes antrea-io#5707 Signed-off-by: Antonin Bas <abas@vmware.com>
Starting with Antrea v1.15, Antrea can be used as the CNI for Talos clusters. This requires custom Helm values. This support was tested using both the Docker provisioner and the QEMU provisioner. Fixes antrea-io#5707 Signed-off-by: Antonin Bas <abas@vmware.com>
Starting with Antrea v1.15, Antrea can be used as the CNI for Talos clusters. This requires custom Helm values. This support was tested using both the Docker provisioner and the QEMU provisioner. Fixes #5707 Signed-off-by: Antonin Bas <abas@vmware.com>
Talos Linux does not have modprobe, which leads to the install-cni.sh script not working correctly, which prevents the installation of CNI, although the necessary module is already built directly into the kernel.
At the same time, CAP_SYS_MODULE is blocked in Talos Linux, which also makes it impossible to install CNI in the standard configuration.
Also, due to the fact that the file system in Talos Linux is read-only, installing the binary files required in the install-cni.sh script into the system is impossible.
Is it possible to solve this problem?
The text was updated successfully, but these errors were encountered: