Open cadeniyi opened 1 year ago
This also brings a question of how to deal with HW/SW specific versions of container. At k8s level: less overhead at the container size, programable (via labeling but also requires more objects at k8s. HW discovery (that sets labeling) -> can it be in a container so we can run a container that will sets labels based on HW?
The newest versions of the CNI plugins use netlink features (that are only available in 4.12+ kernels. This results in failure to setup container networking when deploying standard pods onto the Jetson nano.
This affects platforms like the Jetson Nano which are stuck on a 4.9 kernel (newer versions of Jetpack with 5.0+ kernel do not support the Jetson Nano)
In the short-term I have pinned the version of CNI plugins that are built in the smarter-cni container image to the last known good version (v1.1.1 tagged on March 9 2022). This works but then we don't get the benefit of bug/security fixes on the plugins.
We could build both the older version of the plugins and the newest version into the smarter-cni container image and copy the "right" version when we install the CNI plugins.
We could build multiple smarter-cni container images and use Kubernetes labels to determine the right image to use for a particular platform.
But I guess first we need to decide how far we want to go to support platforms that we don't officially support and therefore might not test?
I have created an issue on the CNI plugins also.