fix: Remove podman binary detection from podman-env command

[elasticdotventures]

Addresses feedback from reviewers by removing podman binary detection and clarifying the Docker client connectivity approach.

Key Changes

• Removed podman binary detection: Eliminates isPodmanAvailable() function and which podman checks per reviewer feedback
• Clarified service description: Now explicitly refers to "Podman Docker-compatible service" for precision
• Removed version specificity: Changed from "podman 4.9.2" requirement to "recent Podman version with Docker API compatibility"
• Focused on Docker client only: Documentation emphasizes only Docker client required, not podman binary

Addresses Review Feedback

• ✅ @afbjorklund: Removed podman detection, focuses purely on Docker socket connectivity
• ✅ Version specificity: Removed specific version requirements as requested
• ✅ Cleaner approach: No podman binary dependency, only Docker client against Docker-compatible API

Before/After

Before

# Command would check for podman binary availability
eval $(minikube podman-env)  # Could fail if podman binary not found

After

# No podman binary check - only connects Docker client to Podman's Docker-compatible service
eval $(minikube podman-env)
export DOCKER_HOST="tcp://192.168.49.2:2376" 
docker images   # Works with Docker client against Podman service

Foundation for Issue #9229

This implementation provides a clean foundation for the future SSH socket approach described in issue #9229, but keeps the current changes minimal and focused. The SSH socket implementation (#9229) would be a separate, more substantial project that can build on this foundation.

Testing

• Updated tests to remove podman detection expectations
• All existing Docker client functionality preserved
• Documentation updated to reflect new approach

This approach is more aligned with issue #9229's vision but represents a focused change that can be merged independently before tackling the larger SSH socket project.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: elasticdotventures / name: Brian Horakh (a1f2849, 7723b9f, 9457fa1, 2f07bfd, bfcdf26, 0dda539, e1e355c)

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: elasticdotventures
Once this PR has been reviewed and has the lgtm label, please assign prezha for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Welcome @elasticdotventures!

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 @elasticdotventures. 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]

can you plz post before/after this PR in the description

[afbjorklund]

I don't think we should look for podman, or suggest to people to use the podman --remote client. We should only give a path to a docker socket, for a docker client.

Podman Desktop does not use podman, and Podman Compose does not default to using podman-compose. Instead, they use the Docker API and docker-compose.

Using the podman-remote client, is what is causing these problems with using cri-o.

Error: unable to connect to Podman socket: server API version is too old. Client "4.0.0" server "3.4.4"

It is better to only use docker as a legacy client, and minikube image for the rest.

That is why it is called "compatibility socket", while the libpod client/connection keeps breaking the backwards API...

[elasticdotventures]

Update: Added Docker Runtime Support

I've added an enhancement that extends podman-env compatibility to support both crio and docker container runtimes

Changes in Latest Commit

• Extended runtime compatibility check to allow both constants.CRIO and constants.Docker
• Updated error message to reflect support for both runtimes
• Maintains the same Docker API compatibility approach for both runtime types

New Supported Configurations

1. Podman driver + crio runtime (original support)

   minikube start --driver=podman --container-runtime=crio
   eval $(minikube podman-env)

2. Podman driver + docker runtime (new support)

   minikube start --driver=podman --container-runtime=docker
   eval $(minikube podman-env)

Both configurations use the same Docker API compatibility approach that eliminates the SSH-based connectivity issues and API version mismatches.

Testing

Verified that both runtime configurations work correctly:

• Docker client connects successfully via podman-env
• docker version reports minikube's Docker daemon version (28.3.3)
• docker ps lists containers running in the cluster
• No API version compatibility errors

[elasticdotventures]

@afbjorklund I just wanted to say thanks for really great advice & feedback.
I took it all in and I worked up this solution which I'm now running on my local system successfully! You deserve all the credit.

I also submitted a separate issue in CRIO (my attempt to isolate the reviews)
#21252

[afbjorklund]

I don't think that it should use the legacy tcp socket for Podman, if anything the ssh socket should be used for Docker...

• Deprecate the old tcp port for docker-env #9229

As far as I know there is no support for it upstream, and if there are issues with ssh it would be better to use local unix*.

* probably tunneled over ssh, but anyway (like it is being done for Podman Desktop)

---

Future versions of minikube should not even start the docker daemon or the podman service, by default.

Instead they should be socket-activated on demand, and only containerd or crio needs to be running for CRI.

But it is better to fix the functionality in minikube image.

Kubernetes does not need to use Docker at all, any more.

[elasticdotventures]

@afbjorklund Thanks for the feedback. I've updated the PR to remove podman binary detection and version specificity as requested.

Issue #9229 is separate work that shouldn't be muddled with this change. Hopefully this cleaner foundation makes that future SSH socket implementation a bit smaller.

[k8s-ci-robot]

@elasticdotventures: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/ok-to-test

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.