Do not wait for k8s-app pods when starting with CNI

[brb]

Previously, minikube was waiting for some pods labeled with "k8s-app" (e.g. "kube-dns") to be ready before indicating that "minikube start" was successful. However, in the case of
"network-plugin=cni", network of such pods is managed by a CNI plugin which is usually started after "minikube start" has returned making the waiting for the pods to fail with:

Error starting cluster: wait: waiting for k8s-app=kube-dns: timed out
waiting for the condition

This commit omits waiting for "k8s-app" pods if minikube is started with "network-plugin=cni".

Original bug report: cilium/cilium#7383

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: brb
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: balopat

If they are not already assigned, you can assign the PR to them by writing /assign @balopat in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[minikube-bot]

Can one of the admins verify this patch?

[tstromberg]

@minikube-bot OK to test

[tstromberg]

Excellent change - thank you for cleaning up after my mess.

So that we don't break this again, could you also add an integration test for CNI support. There is a handy list of 'start' commands we test here:

https://github.com/kubernetes/minikube/blob/master/test/integration/start_stop_delete_test.go#L39

Alternatively - is it viable to wait for CNI first?

[tstromberg]

PR looks good. Can merge once the example CNI command-line is added to start_stop_delete_test.go.

Thank you again!

[brb]

@tstromberg Thanks for reviewing and merging. I will try to add the integration test next week.