Do not wait for k8s-app pods when starting with CNI #3896
Conversation
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".
Reported-by: Michal Rostecki <mrostecki@opensuse.org>
Signed-off-by: Martynas Pumputis <m@lambda.lt>
k8s-ci-robot
added
the
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: brb If they are not already assigned, you can assign the PR to them by writing 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:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
size/S
|
Can one of the admins verify this patch? |
|
@minikube-bot OK to test |
|
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? |
|
PR looks good. Can merge once the example CNI command-line is added to Thank you again! |
|
@tstromberg Thanks for reviewing and merging. I will try to add the integration test next week. |
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:
This commit omits waiting for "k8s-app" pods if minikube is started with "network-plugin=cni".
Original bug report: cilium/cilium#7383