How can I have replicated pods with an init container that is run only once?

Question

If I want to run multiple replicas of some container that requires a one off initialisation task, is there a standard or recommended practice?

Possibilities:

• Use a StatefulSet even if it isn't necessary after initialisation, and have init containers which check to see if they are on the first pod in the set and do nothing otherwise. (If a StatefulSet is needed for other reasons anyway, this is almost certainly the simplest answer.)
• Use init containers which use leader election or some similar method to pick only one of them to do the initialisation.
• Use init containers, and make sure that multiple copies can safely run in parallel. Probably ideal, but not always simple to arrange. (Especially in the case where a pod fails randomly during a rolling update, and a replacement old pod runs its init at the same time as a new pod is being started.)
• Use a separate Job (or a separate Deployment) with a single replica. Might make the initialisation easy, but makes managing the dependencies between it and the main containers in a CI/CD pipeline harder (we're not using Helm, but this would be something roughly comparable to a post-install/post-upgrade hook).

Answer 1

We effectively ended up with a Job that does the initialization task and creates a secret that the Deployment replicas have mounted as a volume, blocking them until the Job has completed. We're using ArgoCD without sync waves. (There are complications with patching the Job name whenever its spec is updated because Jobs are immutable, but they aren't directly relevant to the original question.)

Answer 2

The fact that "replicas of some container" are dependent on "a one off initialisation task" means that the application architecture does not fit the Kubernetes paradigm well. That is why an involvement of a third-party manager on top of k8s like Helm has to be considered (as suggested by Eduardo Baitello and Matt).

To keep with pure Kubernetes approach, it'd be better to redesign your application so that get it components working as independent or loosely coupled microservices (including initialization tasks). A similar question has been discussed here recently.

As for the possibilities listed in the question, perhaps the first option with InitContainers and StatefulSets could be feasible in pure Kubernetes.