Automatic restart for kind containers

[benoitf]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

Using kind, I'm able to deploy a kubernetes cluster.
But when restarting the podman machine, the control-plane container is not restarted, meaning that my cluster is not up so the experience is not nice.

There is an existing issue on kind kubernetes-sigs/kind#2272 but it says that

podman lacks automatic restart for containers and lacks sufficient networking features to design robust restart. Node addresses will be random and restart support will be a roll of the dice

so it would be nice if Podman fixes the issue in order to have kind clusters restart being done properly.

Steps to reproduce the issue:

1. enable podman experimental support in kind export KIND_EXPERIMENTAL_PROVIDER=podman

2. create cluster with kind create cluster

3. stop podman machine (for example on macOS) and restart the machine

Describe the results you received:
control-plane container is not restarted

Describe the results you expected:
control-plane container is restarted

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

(paste your output here)

Output of podman info:

(paste your output here)

Package info (e.g. output of rpm -q podman or apt list podman or brew info podman):

(paste your output here)

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes/No

Additional environment details (AWS, VirtualBox, physical, etc.):

[Luap99]

It is not clear to me what they are doing but with --restart always the container can be started on boot when podman-restart.service is enabled, which is the default going forward (#16672)

[benoitf]

and about Node addresses will be random and restart support will be a roll of the dice. ?

[Luap99]

and about Node addresses will be random and restart support will be a roll of the dice. ?

I have absolutely no idea what they are referring to.

[benoitf]

and there is a comment saying

You have to use podman restart kind-control-plane.
podman start does not reattach the port forwarding.

[Luap99]

I need to know the extract podman commands to reproduce, I have no interest in debugging kind and I am not aware of any port forwarding problems with podman start.

[aojea]

kind developer here, the problems are explained in the kind issue, is not a problem of allowing restart in podman only or really a bug in podman,, kind relies on some behaviors on the network and podman architecture is different to the docker one and are features that are not compatible, that means that s/docker/podman/ doesn't work in kind automatically, some of the issues are:

• podman port-forwarding changed the API, that was a long time ago and that is fixed now podman inspect format doesn' t work for Container Port bindings #8444
• lack of centralized dns, I don't know how it is done now in podman, but previously there was a autodns plugin or something like that and cni - netavark change impacts this https://discussion.fedoraproject.org/t/how-to-get-podman-dns-plugin-container-name-resolution-to-work-in-fedora-coreos-36-podman-plugins-podman-dnsname/39493/5
• podman restart-always is based on systemd Containers with --restart=always policy does not restart services automatically after system reboot. #10539

[Luap99]

lack of centralized dns, I don't know how it is done now in podman

We use https://github.com/containers/aardvark-dns/ now, this is much closer to what docker is doing so it might already work for your use case if not I am happy to hear what is missing.

[aojea]

yeah, things and projects are converging ... but users always wants things to happen immediately ;)

[vrothberg]

Thanks for sharing, @aojea! Does it work with aardvark? If there are missing pieces, please let us know and we'll tackle them.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

Since we never heard a response, I am closing reopen if you have more feedback.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.