Starting cluster before adding another node separately, results in errors due to missing CNI

[yottapanda]

What Happened?

Reproduction steps:

• minikube start
• minikube node add
• minikube addons enable dashboard
• watch kubectl get -n kubernetes-dashboard -o wide pod
• 2 pods stay in CrashLoopBackOff on minikube-m02 (they should start on the added node)

There is also an error when adding the second node:

Cluster was created without any CNI, adding a node to it might cause broken networking.

However the minikube start command logs:

Configuring bridge CNI (Container Networking Interface) ...

which implies that a CNI has been setup (albeit a bridge one).

Alternatively using minikube start --cni kindnet, we still get told that:

Configuring CNI (Container Networking Interface) ..

however when adding another node we still get:

Cluster was created without any CNI, adding a node to it might cause broken networking.

despite the fact that the node now works perfectly and the dashboard comes up.

Solution Suggestions

• Check for and add a CNI when adding a node?
• Fix the inconsistent error message

Attach the log file

log.txt

Operating System

ArchLinux (reproducible in fresh installation with default networking in VM)

Driver

Docker

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[yottapanda]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale