saschagrunert
commented
4 days ago I'm not sure if we should remove the config. Maybe putting it into a recommended extra package. But that seems to be a lot for a single config file.
@cri-o/cri-o-maintainers what are your thoughts on that?
CRI-O now bundles a bridge CNI conflist at install time (presumably to make CRI-O work out-of-the-box for local pods). This causes an issue in Kubernetes because Kubernetes generally requires a multi-node CNI (such as Calico), which is typically installed as a group of Kubernetes pods.
If there is no CNI installed, Kubernetes will block scheduling of CNI-networked pods, allowing for the CNI itself to bootstrap first and then provision the CNI config. However, with the bridge CNI pre-installed, some pods can get scheduled before the intended CNI has bootstrapped, resulting in some pods being provisioned on the local bridge network, instead of, say, Calico.
There may be more moving parts; I'm not 100% sure which pods can and cannot be scheduled before the intended CNI comes up (Kubernetes also has a "NetowrkUnavilable" taint that the CNI or cloud provider is supposed to remove). However, a user of Calico reported that some of Calico's pods were getting scheduled on the CRIO bridge network where normally they would wait for Calico to bootstrap.
Old issue with similar problem: https://github.com/cri-o/cri-o/issues/5799#issuecomment-1168763294 I think it was resolved by removing the bridge config, but that seems to have been regressed.