After restarting Kind Cluster disappears from Podman-Desktop Resources

[Hygens]

Bug description

I have created one Kind Cluster and after restart MacOSX no more found the cluster created and for that not possible start the cluster. If I install the kind command and create new cluster via command line the cluster before created on appear and is possible start and delete the new cluster created via command line. This is my workatound to work for while not corrected that issue.

Operating system

masOS Sonoma

Installation Method

Brew (macOS)

Version

next (development version)

Steps to reproduce

Create kind cluster on podman-desktop => Restart macosx Sonoma 15.1 => Open Podman-Desktop/Resources => No more Kind Cluster.

To appear kind cluster: Install kind cli => Execute kind create cluster => Return to Podman-Desktop/Resources => The kind cluster created on Podman-Desktop appear newly.

Relevant log output

Additional context

No response

[benoitf]

related data: https://podman-desktop.io/docs/kind/restarting-your-kind-cluster#workaround

and: https://github.com/kubernetes-sigs/kind/issues/2272

[Hygens]

related data: https://podman-desktop.io/docs/kind/restarting-your-kind-cluster#workaround

and: kubernetes-sigs/kind#2272

Sorry, that is not same problem. The problem is not restart but Podman-Desktop not show more the cluster created. If I attempt the commands on other posts i get that:

[benoitf]

could you list all the containers using the command line ?

before you reboot and after you reboot ?

$ podman ps

and

$ KIND_EXPERIMENTAL_PROVIDER=podman kind get clusters

[Hygens]

could you list all the containers using the command line ?

before you reboot and after you reboot ?

$ podman ps and

$ KIND_EXPERIMENTAL_PROVIDER=podman kind get clusters

Before:

After:

Creating new cluster observe the image below - show the legacy cluster before created on Resources pane:

[benoitf]

@Hygens do you have a custom ~/.config/containers/containers.conf file ?

[Hygens]

@Hygens do you have a custom ~/.config/containers/containers.conf file ?

No. I haven't.

But have that:

cat /private/etc/containers/registries.conf.d/999-podman-machine.conf
# For more information on this configuration file, see containers-registries.conf(5).
#
# NOTE: RISK OF USING UNQUALIFIED IMAGE NAMES
# We recommend always using fully qualified image names including the registry
# server (full dns name), namespace, image name, and tag
# (e.g., registry.redhat.io/ubi8/ubi:latest). Pulling by digest (i.e.,
# quay.io/repository/name@digest) further eliminates the ambiguity of tags.
# When using short names, there is always an inherent risk that the image being
# pulled could be spoofed. For example, a user wants to pull an image named
# `foobar` from a registry and expects it to come from myregistry.com. If
# myregistry.com is not first in the search list, an attacker could place a
# different `foobar` image at a registry earlier in the search list. The user
# would accidentally pull and run the attacker's image and code rather than the
# intended content. We recommend only adding registries which are completely
# trusted (i.e., registries which don't allow unknown or anonymous users to
# create accounts with arbitrary names). This will prevent an image from being
# spoofed, squatted or otherwise made insecure.  If it is necessary to use one
# of these registries, it should be added at the end of the list.
#
# # An array of host[:port] registries to try when pulling an unqualified image, in order.
unqualified-search-registries = ["registry.fedoraproject.org", "registry.access.redhat.com", "docker.io"]
#
# [[registry]]
# # The "prefix" field is used to choose the relevant [[registry]] TOML table;
# # (only) the TOML table with the longest match for the input image name
# # (taking into account namespace/repo/tag/digest separators) is used.
# #
# # If the prefix field is missing, it defaults to be the same as the "location" field.
# prefix = "example.com/foo"
#
# # If true, unencrypted HTTP as well as TLS connections with untrusted
# # certificates are allowed.
# insecure = false
#
# # If true, pulling images with matching names is forbidden.
# blocked = false
#
# # The physical location of the "prefix"-rooted namespace.
# #
# # By default, this equal to "prefix" (in which case "prefix" can be omitted
# # and the [[registry]] TOML table can only specify "location").
# #
# # Example: Given
# #   prefix = "example.com/foo"
# #   location = "internal-registry-for-example.net/bar"
# # requests for the image example.com/foo/myimage:latest will actually work with the
# # internal-registry-for-example.net/bar/myimage:latest image.
# location = "internal-registry-for-example.com/bar"
#
# # (Possibly-partial) mirrors for the "prefix"-rooted namespace.
# #
# # The mirrors are attempted in the specified order; the first one that can be
# # contacted and contains the image will be used (and if none of the mirrors contains the image,
# # the primary location specified by the "registry.location" field, or using the unmodified
# # user-specified reference, is tried last).
# #
# # Each TOML table in the "mirror" array can contain the following fields, with the same semantics
# # as if specified in the [[registry]] TOML table directly:
# # - location
# # - insecure
# [[registry.mirror]]
# location = "example-mirror-0.local/mirror-for-foo"
# [[registry.mirror]]
# location = "example-mirror-1.local/mirrors/foo"
# insecure = true
# # Given the above, a pull of example.com/foo/image:latest will try:
# # 1. example-mirror-0.local/mirror-for-foo/image:latest
# # 2. example-mirror-1.local/mirrors/foo/image:latest
# # 3. internal-registry-for-example.net/bar/image:latest
# # in order, and use the first one that exists.
#
# short-name-mode="enforcing"

[[registry]]
location="localhost:5000"
insecure=true

[rostalan]

Reproducible on MacOS 14.5.

[feloy]

Hi @Hygens could you please show the result of the command:

podman ps -a

and also the page 'Containers' in Podman Desktop?

(after restarting your machine)

[Hygens]

Hello @feloy, I constantly change my machine so the status may vary but at the moment this is the situation:

Hi @Hygens could you please show the result of the command:

podman ps -a

and also the page 'Containers' in Podman Desktop?

(after restarting your machine)

[feloy]

As a first workaround, you can restart the container from the Containers page (by pressing the > on the right). The cluster should then appear again in the Resources page (as started)

[Hygens]

As a first workaround, you can restart the container from the Containers page (by pressing the > on the right). The cluster should then appear again in the Resources page (as started)

I was starting from the terminal but thanks I can use that too.

Best,

[feloy]

It seems to me that the problem comes from Kind extension relying only on the containerEngine.onEvent to get the Kind containers (and at init time, on getting the list of containers, but because the podman machine is generally not started yet when the extension is initialized, this call returns nothing).

When you start the podman machine, all containers are stopped, and there is little chance you get any container's events (because they are all stopped). But as soon as you start a container (no matter which one, it can be a non-kind one), the clusters appears in the Settings > Resource page.

https://github.com/user-attachments/assets/a1b1bdfe-8c35-4cb8-bded-9bd0f7beec42

cc @odockal

[odockal]

@feloy So this is reproducible after restart of the podman machine as well. I managed to reproduce on Windows.

Now the first question:

• Is this behavior happening by design or not? It seems we need to fix in in any case (adding it to the next sprint).
• How it should behave after machine restart? I think that it should get into OFF state since kind control plane container (and others) are stopped as well.

Workaround for now is to start kind control plane container manually.

[feloy]

No, I don't think it is by design.

Yes, we need to fix it, to display it in the list of Kind clusters in the Settings > Resources > Kind, so the user can start it (still manually) from there, instead of from the Container's list