Now that rpm-ostree is close to supporting "live updates", one thing we could do is move crio/kubelet into a separate machine-os-kubelet container or so, and also move openvswitch as part of e.g. the SDN container.
But these would still be treated as "first class" bits because they'd still be underneath the readonly bind mount in /usr etc. The MCO would learn to pull down this machine-os-kubelet container and apply updates from it too; and we can generalize that to N container images with M RPMs inside (or...perhaps not RPMs at all).
Advantages:
The RHCOS bootimage is basically just RHEL, and this would greatly increase alignment with OKD since we'd use the same approach in both places.
On the bootstrap node, the crio/kubelet in use become exactly the same as the one shipped in cluster.
There wouldn't be anymore "CI -> shipping" gap for kubelet - when a PR merges to that repo it'd get rebuilt and shipped the same way all other containers do and not versioned with RHCOS at all.
Note in this we wouldn't be breaking at all the concept that the cluster owns and manages OS updates; we'd still be testing the OS and kubelet and cluster components all together as a unit in the end. The goal here is just internally split things up more so we can improve the process for CI and building; for example, the RHCOS version number would (mostly) just be a RHEL version number which would greatly increase clarity of how things work. We can be more agile with kubelet/crio etc.
Now that rpm-ostree is close to supporting "live updates", one thing we could do is move crio/kubelet into a separate
machine-os-kubeletcontainer or so, and also moveopenvswitchas part of e.g. the SDN container.But these would still be treated as "first class" bits because they'd still be underneath the readonly bind mount in
/usretc. The MCO would learn to pull down thismachine-os-kubeletcontainer and apply updates from it too; and we can generalize that to N container images with M RPMs inside (or...perhaps not RPMs at all).Advantages:
The RHCOS bootimage is basically just RHEL, and this would greatly increase alignment with OKD since we'd use the same approach in both places.
On the bootstrap node, the crio/kubelet in use become exactly the same as the one shipped in cluster.
There wouldn't be anymore "CI -> shipping" gap for kubelet - when a PR merges to that repo it'd get rebuilt and shipped the same way all other containers do and not versioned with RHCOS at all.
Note in this we wouldn't be breaking at all the concept that the cluster owns and manages OS updates; we'd still be testing the OS and kubelet and cluster components all together as a unit in the end. The goal here is just internally split things up more so we can improve the process for CI and building; for example, the RHCOS version number would (mostly) just be a RHEL version number which would greatly increase clarity of how things work. We can be more agile with kubelet/crio etc.