Flake KVM_Linux_crio multinode tests?

[prezha]

example: https://storage.googleapis.com/minikube-builds/logs/10683/41f77af/KVM_Linux_crio.html

all TestMultiNode tests on KVM_Linux_crio (jenkins) fail with the error:

❌  Exiting due to GUEST_START: adding node: cni apply: bridge CNI is incompatible with multi-node clusters

and that's because

minikube/pkg/minikube/cni/cni.go

Lines 112 to 126 in ff0e25a

	func chooseDefault(cc config.ClusterConfig) Manager {
	// For backwards compatibility with older profiles using --enable-default-cni
	if cc.KubernetesConfig.EnableDefaultCNI {
	klog.Infof("EnableDefaultCNI is true, recommending bridge")
	return Bridge{}
	}
	if cc.KubernetesConfig.ContainerRuntime != "docker" {
	if driver.IsKIC(cc.Driver) {
	klog.Infof("%q driver + %s runtime found, recommending kindnet", cc.Driver, cc.KubernetesConfig.ContainerRuntime)
	return KindNet{cc: cc}
	}
	klog.Infof("%q driver + %s runtime found, recommending bridge", cc.Driver, cc.KubernetesConfig.ContainerRuntime)
	return Bridge{cc: cc}
	}

will recommend bridge:

	* I0314 18:13:21.176662   12167 cni.go:74] Creating CNI manager for ""
	* I0314 18:13:21.176669   12167 cni.go:124] "kvm2" driver + crio runtime found, recommending bridge

but bc of

minikube/pkg/minikube/cni/bridge.go

Lines 81 to 85 in ff0e25a

	// Apply enables the CNI
	func (c Bridge) Apply(r Runner) error {
	if len(c.cc.Nodes) > 1 {
	return fmt.Errorf("bridge CNI is incompatible with multi-node clusters")
	}

it will err

blocking bridge cni with multinode cluster was introduced in pr #8545, probably bc of #8055 (only?)

i've tried locally with unblocking bridge cni for multinode - could successfully bring up the cluster and test dns w/o crashing anything, but the issue described in #8055 seems to remain, ie dns works for pods on master nodes but not on minion nodes

example of KVM_Linux_crio passing all multinode tests with unblocked bridge cni:
https://storage.googleapis.com/minikube-builds/logs/10683/a578121/KVM_Linux_crio.html

---

do we want to unblock bridge cni for multinode clusters and let people try to solve the issue with dns (eg, #8055 (comment)), or shall we disable respective tests that are set to fail (for reasons described above)?