KodeCloud CKAD Environment Variables

Links: 111 KodeCloud Index

---

Environment Variables

Using env

• Environment variables is an array.

  apiVersion: v1
  kind: Pod
  metadata:
      name: simple-webapp-color
  spec:
      containers:
      - name: simple-webapp-color
        image: simple-webapp-color
        ports:
          - containerPort: 8080
        env:
          - name: APP_COLOR
            value: pink
  

• Other ways of specifying env variables are using ConfigMaps & Secrets.

• The only difference is that instead of specifying value we specify valueFrom in case of Secrets & ConfigMaps
  • 
  • In the above examples we are only populating a specific environment variable (APP_COLOR) from the ConfigMap or Secret and not all the environment variables present in ConfigMap or Secret.

Using ConfigMaps

What is the use of ConfigMaps if we specify env variables in the definition file?

When we have a lot of pod definition files it becomes difficult to manage the environment data stored within these files. We can take this configuration out of the definition files and manage it centrally using ConfigMaps.

• There are two steps in using a ConfigMap

  • Create a ConfigMap: k apply -f config.yaml
  • Inject them into the pod.

• Sample ConfigMap

  apiVersion: v1
  kind: ConfigMap
  metadata:
      name: app-config
  data:
      APP_COLOR: blue
      APP_MODE: prod
  

• We can create as many ConfigMaps as we want.

• Getting the ConfigMaps: k get configmap

• Getting the data stored by the ConfigMaps: k describe configmap/<name-of-map>

• There are 3 ways of injecting ConfigMap to a pod.

  • 

• In the below example we inject all the values of the ConfigMap

  • 

• The short form of ConfigMaps is cm.

Using Secrets

• They are used to store sensitive information.
• They are similar to ConfigMap but the values are stored in an encoded format.
• As with ConfigMaps there are 2 steps involved in working with secrets.
  • Create the secret
  • Inject into pods
• All the secrets must be base64 encoded.
  • echo -n "some-string" | base64
• Get the secrets: k get secrets
• View the attributes of the secret: k describe secret/<secret-name>
• We can see the base64 encoded secrets using: k describe secret/<secret-name>
• Decoding base64 values: echo -n "<base64-encoded>" | base64 --decode

• Sample secret file:

  apiVersion: v1
  kind: Secret
  metadata:
      name: app-secret
  data:
      DB_Host: bXlzcWw= # base 64 encoded values
      DB_User: cm9vdA==
      DB_Password: cGFzd3Jk
  

• Different ways of injecting secrets in pods:

  • 

• If we mount the secret as volume then each attribute in the secret is created as a file with the value of secret as its content.

  • 

• The concept of safety of the Secrets is a bit confusing in Kubernetes. They are safer than storing in plain text as they reduce the risk of accidentally exposing passwords and other sensitive data. In my opinion it’s not the secret itself that is safe, it is the practices around it.

• Also the way k8s handles secrets. Such as:

  • A secret is only sent to a node if a pod on that node requires it.
  • Kubelet stores the secret into a tmpfs so that the secret is not written to disk storage.
  • Once the Pod that depends on the secret is deleted, kubelet will delete its local copy of the secret data as well.

• Having said that, there are other better ways of handling sensitive data like passwords in Kubernetes, such as using tools like Helm Secrets, HashiCorp Vault.

---

Last updated: 2023-05-03