Allow to specify init container type when using play kube

[fugkco]

/kind feature

Description

It seems init container type (podman create ... --init-ctr=type) cannot be specified in the kubernetes manifest when using play kube (see https://github.com/containers/podman/blob/main/pkg/domain/infra/abi/play.go#L516).

This also doesn't match Kubernetes' default initContainers behaviour, which is closer to setting the type to once. In addition, when an init container fails, it repeatedly restarts the init container until it passes. The exception to this is when the pod's restartPolicy is set to Never, in which case on failure, the overall pod is failed.

It would be nice to either change the behaviour of this to be closer to Kubernetes, or allow for this to be changed so an init container can be set to run once within a manifest.

[vrothberg]

Thanks for reaching out, @fugkco!

@baude @rhatdan something to groom

[rhatdan]

I think it should follow the kubernetes behaviour.
@umohnani8 WDYT?

[umohnani8]

I agree, we should follow k8s behavior for type and restarts. We can add a flag --init-ctr to the play kube command so users can specify the type. If none is specified, we can default to once.

I can work on this.

[vrothberg]

@umohnani8 can you elaborate on why we need a flag? If specified in the YAML, I'd expect play kube to just use them as K8s does.

[fugkco]

Agreed. I think if anything this option should be managable on a per init container basis, not globally. But I don't see an obvious way of doing this based on K8s Container definition. Perhaps a label on the pod spec but that seems like a lot.

[rhatdan]

I agree no reason for a flag, we should work like Kubernetes does with init containers.

[umohnani8]

Kuberentes doesn't have a field to set the type of init container in the yaml, there is no once or always in kubernetes land. We can change the default to be once for play kube if that is what kubernetes does.

If we want to give the user the choice to decided if they want the init containers to be always or once, that would be a flag in play kube or we parse a label added to the podspec (this label will be only specific to podman). In both cases, the type will be set for all the init containers in the yaml, I don't think it makes sense to set it per init container - the type should be conisistent throughout all init containers imo.

[vrothberg]

We can change the default to be once for play kube if that is what kubernetes does.

That sounds like a good first step.

If we want to give the user the choice to decided if they want the init containers to be always or once, that would be a flag in play kube or we parse a label added to the podspec (this label will be only specific to podman). In both cases, the type will be set for all the init containers in the yaml, I don't think it makes sense to set it per init container - the type should be conisistent throughout all init containers imo.

A label/annotation sounds good. We do that for a number of Podman-specific features already and I see beauty in all these things being part of the YAML such that it works everywhere the same way.

[Syquel]

In my opinion the init container type "always" was the correct default.

Excerpt from the Kubernetes documentation:

If the Pod restarts, or is restarted, all init containers must execute again.

Excerpt from the podman-create documentation:

The always value means the container will run with each and every pod start, whereas the once value means the container will only run once when the pod is started and then the container is removed.

Although "always" does not replicate the Kubernetes init container behavior 100% because Podman init containers are not run when the pod is restarted, in my opinion it is more correct because the init container should run when a stopped pod is started.

[fugkco]

@Syquel I believe the issue that was fixed is that the initContainer kept restarting even when it ran successfully (without the pod restarting that is), which is not the correct behaviour compared to Kubernetes. If the issue is that restarting the pod doesn't rerun the initContainer, that's a different issue, and you should raise that as a separate issue for it to be triaged.