Fix start cluster when docker container is connected to several networks

[fredericgermain]

fixes #10079

I followed this tutorial and connected minikube to an extra network for metallb : https://www.hashicorp.com/blog/deploy-consul-cluster-peering-locally-with-minikube

• Before: request made in pkg/drivers/kic/oci/network.go by dockerContainerIP :

docker container inspect -f "{{range .NetworkSettings.Networks}}{{.IPAddress}},{{.GlobalIPv6Address}}{{end}}" dc1,

would display something like 192.168.121.2,172.68.0.2,.

• After: I just changed the request to just ask the ip of the main network

docker container inspect -f '{{with (index .NetworkSettings.Networks "dc1")}}{{.IPAddress}},{{.GlobalIPv6Address}}{{end}}' dc1

Now only the addresses of the main network are returned 192.168.121.2,.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: fredericgermain (1775aa1, dc70b5a, 45e47f5, f1d5516, 8d6b178, 274d5e0, b8872cb, 1f7c2a6, b57db32, 29ad523, c2b297a, ead9e4e, c6e8f7f, 8e1d062, 7e12e7e, 3d19470, 4325226, faf3698, 12d5b9b, 508e546, df6834a, ffa45f3, d07bee9, 91bbfc8, 73de293, c9b3261, ac32a10, b42087f, a95fbdf, 76de6d1)

[k8s-ci-robot]

Welcome @fredericgermain!

It looks like this is your first PR to kubernetes/minikube 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/minikube has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @fredericgermain. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[minikube-bot]

Can one of the admins verify this patch?

[medyagh]

@fredericgermain thank you very much for this contribution and sharing the tutorial,
do you mind sharing the Steps to to do to recreate the environment that the bug happens ?

I think this could be added as an integration test or maybe unit test, would you like to add an integration test for this ?

[medyagh]

/ok-to-test

[medyagh]

fredericgermain the Docker Linux test are failing and related to this PR https://storage.googleapis.com/minikube-builds/logs/18943/34582/Docker_Linux.html

it seems to be affecting the multi node minikube, can you please ensure this new feature doesnt break multi node minikube ,

you can start a multi node using
minikube start -n=2 (for two nodes)

[fredericgermain]

That's a lot of errors indeed!
I will try to have a look within the next two weeks.

[medyagh]

That's a lot of errors indeed! I will try to have a look within the next two weeks.

sounds good, please remove the WIP in the PR title once ready for review.

[fredericgermain]

Hi @prezha !

Again; thank you for your time to review this.

For PostMortemLogs, I aligned with the way it is do in image_test.go

I moved VerifyDeletedResources at the very end and it checks the external network is removed.

I didn't remove extnetValidateStop. Although I agree it shouldn't be really done in this test, a test for the stop status is not done in any other test.
But as suggested, I added a test to check that the network config is what expected after a restart.

[minikube-pr-bot]

kvm2 driver with docker runtime

+----------------+----------+---------------------+
|    COMMAND     | MINIKUBE | MINIKUBE (PR 18943) |
+----------------+----------+---------------------+
| minikube start | 70.0s    | 70.3s               |
| enable ingress | 14.9s    | 15.2s               |
+----------------+----------+---------------------+

Times for minikube start: 46.1s 46.9s 49.0s 159.0s 48.8s
Times for minikube (PR 18943) start: 47.0s 46.9s 46.1s 160.2s 51.2s

Times for minikube ingress: 14.4s 15.0s 15.0s 15.0s 15.0s
Times for minikube (PR 18943) ingress: 15.0s 15.9s 15.5s 14.9s 14.9s

docker driver with docker runtime

+----------------+----------+---------------------+
|    COMMAND     | MINIKUBE | MINIKUBE (PR 18943) |
+----------------+----------+---------------------+
| minikube start | 22.2s    | 22.9s               |
| enable ingress | 12.6s    | 12.9s               |
+----------------+----------+---------------------+

Times for minikube start: 23.4s 20.7s 24.0s 21.5s 21.6s
Times for minikube (PR 18943) start: 23.9s 20.7s 23.7s 23.6s 22.8s

Times for minikube ingress: 12.2s 13.2s 12.3s 12.3s 13.2s
Times for minikube (PR 18943) ingress: 13.2s 13.2s 12.3s 12.8s 12.8s

docker driver with containerd runtime

+----------------+----------+---------------------+
|    COMMAND     | MINIKUBE | MINIKUBE (PR 18943) |
+----------------+----------+---------------------+
| minikube start | 20.5s    | 20.5s               |
| enable ingress | 34.2s    | 30.7s               |
+----------------+----------+---------------------+

Times for minikube ingress: 39.2s 39.2s 22.8s 30.2s 39.3s
Times for minikube (PR 18943) ingress: 40.3s 22.7s 39.7s 27.7s 23.2s

Times for minikube start: 18.5s 22.1s 19.9s 21.8s 20.1s
Times for minikube (PR 18943) start: 19.3s 19.7s 19.3s 23.9s 20.4s

[minikube-pr-bot]

Here are the number of top 10 failed tests in each environments with lowest flake rate.

Environment	Test Name	Flake Rate
Docker_Cloud_Shell (6 failed)	TestAddons/parallel/Registry(gopogh)	20.29% (chart)
Docker_Linux_crio_arm64 (5 failed)	TestMultiControlPlane/serial/DeleteSecondaryNode(gopogh)	6.41% (chart)
Docker_Linux_crio_arm64 (5 failed)	TestMultiControlPlane/serial/RestartCluster(gopogh)	16.03% (chart)
Docker_Linux_crio_arm64 (5 failed)	TestAddons/parallel/Registry(gopogh)	24.36% (chart)
Docker_Linux_docker_arm64 (1 failed)	TestAddons/parallel/Registry(gopogh)	24.36% (chart)
KVM_Linux (1 failed)	TestAddons/parallel/Registry(gopogh)	24.18% (chart)
none_Linux (1 failed)	TestAddons/parallel/Registry(gopogh)	24.00% (chart)
Docker_Linux_crio (3 failed)	TestAddons/parallel/Registry(gopogh)	24.18% (chart)
Docker_Linux (1 failed)	TestAddons/parallel/Registry(gopogh)	24.36% (chart)

Besides the following environments also have failed tests:

• KVM_Linux_crio: 13 failed (gopogh)

• Hyperkit_macOS: 24 failed (gopogh)

• QEMU_macOS: 98 failed (gopogh)

• Docker_Linux_containerd_arm64: 2 failed (gopogh)

To see the flake rates of all tests by environment, click here.