Open jspaleta opened 3 months ago
I should note the minikube is installing cilium v1.15.3, while kind is installing v1.15.5. I can't find a way to have minikube startup without a CNI present to do a traditional self install of cilium. So its not a perfect naranjas to oranges comparison between kind and minikube.
But I'm hoping the logic as to whether or not client3 deployment is attempted is something in cilium-cli logic, and it just needs to taste test the cluster node arrangement to figure out if it should be done.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Bug report
So this is an interesting corner case single node deployments, like the documented minikube install work fine as there is some logic in the cilium-cni code that detects that client3 shouldn't attempt to be installed.
But for 2 node kind cluster, with a control-plane and a single worker, the client3 deployment gets attempted and basically hangs and evetually times outs because it can't get scheduled.
A 2 node minikube cluster doesn't have the problem, its a bit of a head scratcher.
General Information
cilium version
)How to reproduce the issue
kind create cluster --config test-config.yaml
cilium install --version 1.15.5
minikube start --cni cilium -n 2