How to avoid needing to rename data-services init job in a kustomize based k8s deployment?

Data Services
, ,
1

In a k8s deployment of an A12 application where the deployment descriptors are based on the A12 helm charts, how can I avoid manually renaming the data-services-init-job when upgrading the application?

For most of the upgrades the only things that need to be done is changing the image tags to reflect the new application version and to rename the data-services-init-job. The second step is needed because changing jobs is not allowed by the k8s api.

This second step is a source for errors because this tends to be forgotten about and then causes stress because a production deployment doesn’t go as smooth as it should be.

So how can I avoid the necessity of renaming the data-services init job during upgrades?

2

As far as I know, you can always delete jobs beforehand.

In a pipeline you could do:

  1. kubectl delete job data-services-init-job --ignore-not-found
  2. kubectl create -f data-services-init-job.yaml
  3. kubectl wait --for=condition=complete job/data-services-init-job --timeout=10m
  4. kubectl apply -f deployment.yaml

With many Kubernetes tools you could use hooks to archive the same:

Helm (source)

metadata:
  name: data-services-init-job
  annotations:
    "helm.sh/hook": "pre-install,pre-upgrade"
    "helm.sh/hook-delete-policy": "before-hook-creation,hook-succeeded"

Argo CD (source)

apiVersion: batch/v1
kind: Job
metadata:
  generateName: integration-test-
  annotations:
    argocd.argoproj.io/hook: PostSync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
3

Using ArgoCD hooks was not possible because using generateName caused a problem with the application of kustomize in the execution chain afterwards. The error message was along the lines of “panic: number of previous names, number of previous namespaces, number of previous kinds not equal”

I also got to know about the kustomize annotation

kustomize.config.k8s.io/needs-hash

However this turns out only to have an effect in kustomize plugins and hence is not usable in my scenario where I can only deal with k8s resources.