Onload™ Operator for Kubernetes® v3.0 has the following limitations:
-
A MACVLAN or IPVLAN of the network interface to be accelerated must be presented into application pods as a secondary interface using the Multus CNI. Traffic is not accelerated over the Kubernetes software defined network (SDN).
In particular, the following are not supported:
- Calico CNI
- MetalLB
- Pod-to-pod traffic within a node
- Upgrading from the Onload Operator v2.0 or earlier without first removing it
- The Onload Operator manages KMM
resources on your behalf but does not provide feature parity with KMM.
Examples of features not included are:
- In-cluster container image build signing
- Node version freezing during ordered upgrade (Onload Operator manages these labels)
- Miscellaneous DevicePlugin configuration
- Configuration of registry credentials (beyond existing cluster configuration)
- Customization of kernel module parameters and soft dependencies
- Customization of Namespace and Service Account for dependent resources (these are instead inherited from the Onload Custom Resource (CR))
Configuring
PreflightValidationcan be performed independently while the Onload Operator is running. - Reloading of the kernel modules
onload(and optionallysfc) occurs on first deployment and under certain reconfigurations.When using AMD Solarflare interfaces for Kubernetes control plane traffic, ensure node network interface configuration and workloads regain their correct configuration and cluster connectivity after reload.
- Interface names might change when switching from an in-tree to
out-of-tree
sfckernel module.This is due to changes in default interface names between versions 4 and 5 of
sfc. Ensure you take appropriate measures for any additional network configurations that depend on this information. - ef_vi is currently not tested, so Onload Operator for Kubernetes does not claim to support it.