Can Kubernetes Cronjobs Reuse Environment Variables From Existing Deployment?

Question

I am using a Kubernetes Cronjob to run period database restores and post restore scripts which runs against the target environment which include tasks such as working with the database, redis, and file system.

The issue I am facing is that I have to re-define all the environment variables I use in my Deployment within the Cronjob (E.g., DATABASE_NAME, DATABASE_PASSWORD, REDIS_HOST etc.).

While repeating all the environment variables works, it is error prone as I have already forgotten to update the jobs which results in me having to re-run the entire process which takes 2-4 hours to run depending on what environment.

Is there a way to reference an existing Deployment and re-use the defined environment variables within my Cronjob?

i don't think you can refer to deployment but you can set env variables from secret, so you would refer to same secret in cron and deployment — Markownikow, Dec 03 '19 at 22:27
@Markownikow, yes that is true. I use that for my actual secrets such as `DATABASE_PASSWORD` but don't actually want to convert non-sensitive env vars into secrets within my deployment (as it makes it a little harder to troubleshoot when looking at files within SCM). Thank you for the feedback. — leeman24, Dec 03 '19 at 22:31
I see, how about config map where you could easily see values while debugging? — Markownikow, Dec 03 '19 at 22:43

score 2 · Accepted Answer · answered Dec 04 '19 at 08:16

2

You can use 'kind: PodPreset' object to define and inject comman env variables into multiple kuberentes objects like deployments/statefulsets/pods/replicasets etc.

Follow the link for help --> https://kubernetes.io/docs/tasks/inject-data-application/podpreset/

answered Dec 04 '19 at 08:16

P Ekambaram

15,499
7
34
59

Looks like a valid solution which would also allow my CronJob (and deployment) to use one label versus re-specifying each environment variable to use which i'd need to do with a ConfigMap or secret. I'd need to do some work around my helm chart but will add this to my backlog. – leeman24 Dec 04 '19 at 15:51

score -1 · Answer 2 · answered Dec 04 '19 at 08:58

I don't think so you can reuse environment variables until it is coming from secrets or configmaps.So if you don't want to use secrets for non sensitive data then you can use configmaps as like below

kubectl create configmap redis-uname --from-literal=username=jp

[root@master ~]# kubectl get cm redis-uname -o yaml
apiVersion: v1
data:
  username: jp
kind: ConfigMap
metadata:
  creationTimestamp: "2019-11-28T21:38:18Z"
  name: redis-uname
  namespace: default
  resourceVersion: "1090703"
  selfLink: /api/v1/namespaces/default/configmaps/redis-uname
  uid: 1a9e3cce-50b1-448b-8bae-4b2c6ccb6861
[root@master ~]#

[root@master ~]# echo -n 'K8sCluster!' | base64
SzhzQ2x1c3RlciE=

[root@master ~]# cat redis-sec.yaml
apiVersion: v1
kind: Secret
metadata:
 name: redissecret
data:
 password: SzhzQ2x1c3RlciE=
[root@master ~]#



[root@master ~]# kubectl apply -f redis-sec.yaml
secret/redissecret created

[root@master ~]# kubectl get secret redissecret -o yaml
apiVersion: v1
data:
  password: SzhzQ2x1c3RlciE=
kind: Secret
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"password":"SzhzQ2x1c3RlciE="},"kind":"Secret","metadata":{"annotations":{},"name":"redissecret","namespace":"default"}}
  creationTimestamp: "2019-11-28T21:40:18Z"
  name: redissecret
  namespace: default
  resourceVersion: "1090876"
  selfLink: /api/v1/namespaces/default/secrets/redissecret
  uid: 2b6acdcd-d7c6-4e50-bd0e-8c323804155b
type: Opaque
[root@master ~]#

apiVersion: v1
kind: Pod
metadata:
 name: "redis-sec-env-pod"
spec:
 containers:
 - name: redis-sec-env-cn
   image: "redis"
   env:
    - name: username
      valueFrom:
        configMapKeyRef:
          name: redis-uname
          key: username
    - name: password
      valueFrom:
        secretKeyRef:
          name: redissecret
          key: password

[root@master ~]# kubectl apply -f reddis_sec_pod.yaml
pod/redis-sec-env-pod created

[root@master ~]# kubectl exec -it redis-sec-env-pod sh
# env|grep -i user
username=jp
# env|grep -i pass
password=K8sCluster!
#

Can Kubernetes Cronjobs Reuse Environment Variables From Existing Deployment?

2 Answers2