Podman Desktop driver on Mac or Win (and Linux)

[afbjorklund]

We should test (and document) running the podman driver remotely, on non-Linux platforms.

Basically these platforms install podman-remote as podman, and run commands over varlink.

There is no documentation on how to set up the remote VM for Mac or Win, unfortunately...

The upstream install docs all assume that such a Linux host is already available over SSH:

https://podman.io/getting-started/installation

MacOS
Podman is a tool for running Linux containers. You can do this from a MacOS desktop as long as you have access to a linux box either running inside of a VM on the host, or available via the network. You need to install the remote client and then setup ssh connection information in the podman-remote.conf file.

Windows
Podman is a tool for running Linux containers. You can do this from a Windows desktop as long as you have access to a linux box either running inside of a VM on the host, or available via the network. You need to install the remote client and then setup ssh connection information in the podman-remote.conf file.

https://github.com/containers/libpod/blob/master/docs/source/markdown/podman-remote.conf.5.md

---

Theoretically using podman-machine should work, as long as you use the systemd one:

https://boot2podman.github.io/2018/12/07/fedora-iso-variant.html

It is also possible to do it yourself, using the hypervisor of your choice... (and a Fedora ISO)

There is a walkthrough here: https://itnext.io/podman-and-skopeo-on-macos-1b3b9cf21e60

We need to document some minikube-specific configuration, like switching over to cgroupfs

[afbjorklund]

There's some minor differences, that we need to handle in code

Error: unrecognized command `podman cp`

Probably just use the regular "tee" workaround for this scenario.

podman cp /foo minikube:/bar --> podman-remote exec -i minikube tee /bar < /foo

---

Added PR #8060 for this

This bug is containers/podman#4207

[afbjorklund]

There is also some other limitations, that we need to address:

        // DefaultBindIPV4 is The default IP the container will listen on.
        DefaultBindIPV4 = "127.0.0.1"

// GetExternalIP returns an IP which is accissble from outside
func (d *Driver) GetExternalIP() (string, error) {
        return oci.DefaultBindIPV4, nil
}

// GetSSHHostname returns hostname for use with ssh
func (d *Driver) GetSSHHostname() (string, error) {
        return oci.DefaultBindIPV4, nil
}

This assumes that we always set up tunnels for all ports on the VM.
Otherwise there is nothing transporting from the the host to the VM.

Like in: https://docs.docker.com/docker-for-mac/networking/#use-cases-and-workarounds

But unfortunately podman-remote does not do this at the moment.

[afbjorklund]

That is: if you bind to 127.0.0.1 and connect to 127.0.0.1 it will fail miserably :

podman-remote run -p 127.0.0.1:8000:80 -d nginx
curl http://localhost:8000

This is because there is nothing listening locally, where the podman client runs...
But if you log in to the podman server (with ssh), then you can view the webpage.

So if you bind to 0.0.0.0 and connect to the remote IP, it will work as expected :

podman-remote run -p 8000:80 -d nginx
curl http://192.168.99.103:8000

This works OK with Docker Desktop now:

 docker run -p 127.0.0.1:8000:80 -d nginx
 curl http://localhost:8000

But it does not work with Podman Remote.

Which means that the KIC networking needs to be revisited (it's hardcoded now),
if it is supposed to work remotely (i.e. without a docker VM forwarding the ports)

It doesn't really work with Docker on Mac or Win now either, since it's not reachable.
That is, only the ports that minikube forwards with docker can be reached - not k8s.

#7344 #7879

[afbjorklund]

Currently I am testing this locally, by renaming podman-remote to podman
And hacking all those various runtime.GOOS == "linux" tests into false.

Probably needs some better way of doing this globally, even if only for debugging.
For now we should just avoid using the "podman" driver outside of Linux...

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale