Support spec.replicas > 1 in podman play kube — allow multiple Deployment replicas

[marcoklaassen]

Feature request description

Summary

When a Deployment manifest specifies replicas: N, podman play kube should honor that and create N pods—rather than silently limiting it to one.

Motivation & References

• As of Podman 4.4, pods created via play kube are capped at one replica: “limits the replica count to 1”.
• Issue #16765 describes pod startup failures due to port binding conflicts when attempting duplicates.
• PR #16766 introduces random port assignment to mitigate such conflicts.
• PR #17082 warns users when attempting multi‑replica deployment with play kube.

Proposal

• Allow play kube to create multiple pods when spec.replicas > 1.
• Handle port conflicts gracefully—e.g., through randomized host ports or offset mapping.
• Maintain or improve user feedback: explicitly warn if scaling isn't feasible.
• Add example use cases or tests in CI/docs to demonstrate correct behavior.

Benefits

Better aligns podman play kube with real‑world Kubernetes workflows and streamlines local/demo usage—reducing manual steps and improving reliability.

Thank you for considering this feature!

Suggest potential solution

A clear and concise description of what you want to happen.

Have you considered any alternatives?

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

[arsenalzp]

Hello,
Can I work on it?

[arsenalzp]

/assign

[arsenalzp]

Hello @Luap99
Does this feature request make sense on your view?

[Luap99]

Yes this makes sense to me, though the question is how should we deal with conflicting ports? If the yaml ask for a specific host port then I think creating an error still makes sense over randomly picking a different port.

Also considering people may rely on the current behavior of ignoring the replica maybe we should make it opt in behind a new option? From a stability standpoint I don't think it is good to switch the defaults back and forth over and over.
So maybe it needs a bit more design discussion.

cc @mheon @baude @ygalblum @dcermak @vrothberg

[vrothberg]

Yes this makes sense to me, though the question is how should we deal with conflicting ports? If the yaml ask for a specific host port then I think creating an error still makes sense over randomly picking a different port.

I am also interested in that part. Replicas can't match the behavior of K8s given Podman is bound to a single host. So I am hesitant to pursue that feature.

Also considering people may rely on the current behavior of ignoring the replica maybe we should make it opt in behind a new option? From a stability standpoint I don't think it is good to switch the defaults back and forth over and over.
So maybe it needs a bit more design discussion.

An option makes sense. The default value of the option could then be changed in a future major release if desired.

[ygalblum]

Yes this makes sense to me, though the question is how should we deal with conflicting ports? If the yaml ask for a specific host port then I think creating an error still makes sense over randomly picking a different port.

This was the main reason why we added the limit on the number of replicas. Having said that, not all pods expose ports, so limiting the replicas does not make sense for them.
I guess a command line argument that allows multiple replicas is a good idea here as it explicitly moves the responsibility of using configurations that will work on Podman, to the user.

[arsenalzp]

Hello colleagues,

So what is the algorithm of publishing ports for multiple Pods?
There is --publish= CLI option which exposes container port to host port. It woks well for single Pod.
Should I either change its behavior to allow publishing for multiple Pod or introduce another option/command which does expose?