helm - run pods and dependencies with a predefined flow order

Question

I am using K8S with helm.

I need to run pods and dependencies with a predefined flow order.

How can I create helm dependencies that run the pod only once (i.e - populate database for the first time), and exits after first success?

Also, if I have several pods, and I want to run the pod only on certain conditions occurs and after creating a pod.

Need to build 2 pods, as is described as following:

I have a database.

1st step is to create the database.

2nd step is to populate the db.

Once I populate the db, this job need to finish.

3rd step is another pod (not the db pod) that uses that database, and always in listen mode (never stops).

Can I define in which order the dependencies are running (and not always parallel).

What I see for helm create command that there are templates for deployment.yaml and service.yaml, and maybe pod.yaml is better choice?

What are the best charts types for this scenario?

Also, need the to know what is the chart hierarchy.

i.e: when having a chart of type: listener, and one pod for database creation, and one pod for the database population (that is deleted when finished), I may have a chart tree hierarchy that explain the flow.

The main chart use the populated data (after all the sub-charts and templates are run properly - BTW, can I have several templates for same chart?).

What is the correct tree flow

Thanks.

Answer 1

There is a fixed order with which helm with create resources, which you cannot influence apart from hooks.

Helm hooks can cause more problems than they solve, in my experience. This is because most often they actually rely on resources which are only available after the hooks are done. For example, configmaps, secrets and service accounts / rolebindings. Leading you to move more and more things into the hook lifecycle, which isn't idiomatic IMO. It also leaves them dangling when uninstalling a release.

I tend to use jobs and init containers that blocks until the jobs are done.

---
apiVersion: v1
kind: Pod
metadata:
  name: mysql
  labels:
    name: mysql
spec:
  containers:
    - name: mysql
      image: mysql
---
apiVersion: batch/v1
kind: Job
metadata:
  name: migration
spec:
  ttlSecondsAfterFinished: 100
  template:
    spec:
      initContainers:
        - name: wait-for-db
          image: bitnami/kubectl
          args:
            - wait
            - pod/mysql
            - --for=condition=ready
            - --timeout=120s
      containers:
        - name: migration
          image: myapp
          args: [--migrate]
      restartPolicy: Never
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  selector:
    matchLabels:
      app: myapp
  replicas: 3
  template:
    metadata:
      labels:
        app: myapp
    spec:
      initContainers:
        - name: wait-for-migration
          image: bitnami/kubectl
          args:
            - wait
            - job/migration
            - --for=condition=complete
            - --timeout=120s
      containers:
        - name: myapp
          image: myapp
          args: [--server]

Moving the migration into its own job, is beneficial if you want to scale your application horizontally. Your migration need to run only 1 time. So it doesn't make sense to run it for each deployed replica.

Also, in case a pod crashes and restarts, the migration doest need to run again. So having it in a separate one time job, makes sense.

The main chart structure would look like this.

.
├── Chart.lock
├── charts
│   └── mysql-8.8.26.tgz
├── Chart.yaml
├── templates
│   ├── deployment.yaml    # waits for db migration job
│   └── migration-job.yaml # waits for mysql statefulset master pod
└── values.yaml