Configuration, Secrets and Storage in Kubernetes

In the last lesson your pods learned to find each other. Now they need three more things. They need settings (which log level? which database host?). They need passwords (the database password, an API key). And some of them need disk space that does not disappear when the pod is replaced.

Kubernetes has a separate object for each of these. This lesson explains them one by one, with small examples. We also open the box and look at where a Secret really lives, because that is the part most people get wrong.

This is lesson 6 of the series (lessons run from 0 to 9). It builds on Services, Ingress and Networking in Kubernetes. The next lesson, Scaling, Rollouts and Reliability, makes these pods safe to update and scale. If you want the Docker-only version of this topic first, Volumes, Networks and Running Containers Safely covers volumes, bind mounts and environment variables on one machine.

Words used in this lesson

• ConfigMap is an object that stores non-secret settings as key and value pairs.
• Secret is an object that stores sensitive values (passwords, tokens, keys). It looks like a ConfigMap but is handled with more care.
• base64 is a way to write bytes as plain letters. It is not encryption. Anyone can reverse it.
• Environment variable is a named value that a process reads when it starts, like LOG_LEVEL=info.
• Volume is a folder that is mounted into a container. In Kubernetes it belongs to the pod, not to one container.
• emptyDir is a scratch volume that is created empty with the pod and deleted with the pod.
• PersistentVolume (PV) is a piece of real storage in the cluster, such as a cloud disk.
• PersistentVolumeClaim (PVC) is a pod's request for storage: "I need 5 GiB, read-write". Kubernetes finds or creates a PV to match.
• StorageClass is a recipe for making storage on demand, such as "fast SSD, delete when released".
• Provisioner is the program that creates the real disk for a StorageClass.
• Access mode says who may mount a volume, for example ReadWriteOnce (one node at a time).
• StatefulSet is like a Deployment, but each pod gets a stable name and its own disk.
• etcd is the database where Kubernetes stores every object, including Secrets.
• Encryption at rest means data is encrypted on disk, so that a stolen disk or backup is not readable.

The idea: one image, many environments

In lesson 1 we built an image. The rule for a good image is: build once, run anywhere. The same image should run on your laptop, in testing and in production. If you bake the database address into the image, you need a different image for each place. That is slow, and you are no longer testing what you ship.

So the image contains the code. The settings come from outside, when the container starts. That is what ConfigMaps and Secrets are for.

ConfigMaps: settings as an object

A ConfigMap is an object with a data section. The data is just names and values (strings). The name of the ConfigMap and the keys inside it are for you to choose.

There are three easy ways to create one. Let me use kubectl create ... --dry-run=client -o yaml. This does not talk to a cluster. It only prints the YAML that kubectl would send. First I made a small file app.json with one line, then I ran:

kubectl version --clientkubectl create configmap notes-config \  --from-literal=LOG_LEVEL=info \  --from-literal=PAGE_SIZE=20 \  --from-file=app.json=files/app.json \  --dry-run=client -o yaml

Client Version: v1.34.0Kustomize Version: v5.7.1apiVersion: v1data:  LOG_LEVEL: info  PAGE_SIZE: "20"  app.json: |    { "pageSize": 20, "cacheSeconds": 60 }kind: ConfigMapmetadata:  name: notes-config

Look at what happened. --from-literal made one short key per flag. --from-file made a key called app.json whose value is the whole content of the file. A ConfigMap does not care if a value is one word or a whole JSON file. Also notice that PAGE_SIZE got quotes: "20". That is on purpose, and it leads to our first trap.

Trap: every value in a ConfigMap is a string

Here is a ConfigMap that looks fine to a human:

apiVersion: v1kind: ConfigMapmetadata:  name: notes-configdata:  PAGE_SIZE: 20  DEBUG: true

YAML reads 20 as a number and true as a boolean. A ConfigMap wants strings. I checked this file with kubeconform (strict mode, Kubernetes 1.34.0 schemas):

bad-number.yaml - ConfigMap notes-config is invalid: problem validating schema. Check JSON formatting: jsonschema validation failed with 'https://raw.githubusercontent.com/yannh/kubernetes-json-schema/master/v1.34.0-standalone-strict/configmap-v1.json#' - at '/data/DEBUG': got boolean, want null or string - at '/data/PAGE_SIZE': got number, want null or string

The real API server says the same thing when you try to apply it (the object already existed in my test, so the message is about a patch):

The request is invalid: patch: Invalid value: "map[data:map[DEBUG:true ...]]": cannot convert int64 to string

The fix is to put quotes around every value: PAGE_SIZE: "20", DEBUG: "true". Your app then converts the string to a number or boolean itself. In Node.js that means Number(process.env.PAGE_SIZE). Remember that environment variables are always strings, even in Docker.

The ConfigMap file I use for the rest of this lesson:

# configmap.yamlapiVersion: v1kind: ConfigMapmetadata:  name: notes-configdata:  LOG_LEVEL: "info"  PAGE_SIZE: "20"  app.json: |    { "pageSize": 20, "cacheSeconds": 60 }

Two limits to know. A ConfigMap can hold at most 1 MiB of data. And a ConfigMap is not secret. The Kubernetes docs say this in a warning box: a ConfigMap gives no secrecy or encryption. Passwords go in a Secret (next section).

Three ways to use a ConfigMap in a pod

The ConfigMap by itself does nothing. A pod has to refer to it. The pod and the ConfigMap must be in the same namespace. There are three common ways to use it.

1. One key as one environment variable (valueFrom with configMapKeyRef):

env:  - name: LOG_LEVEL    valueFrom:      configMapKeyRef:        name: notes-config        key: LOG_LEVEL

2. All keys as environment variables (envFrom). Every key in the ConfigMap becomes a variable. This is short, but you can pull in names you did not expect, so I use it only for small ConfigMaps that I own.

envFrom:  - configMapRef:      name: notes-config

3. Keys as files (a volume). Each key becomes a file, and the value becomes the file content. This fits config files like app.json or nginx.conf.

volumeMounts:  - name: config    mountPath: /etc/notes    readOnly: truevolumes:  - name: config    configMap:      name: notes-config      items:        - key: app.json          path: app.json

Without items, every key becomes a file (here: LOG_LEVEL, PAGE_SIZE and app.json). With items, only the keys you list become files, and path is the file name. So this mount gives your app one file: /etc/notes/app.json.

Here is a full Deployment that uses all of this, plus a Secret. It is the notes-api Deployment from the earlier lessons, with config added.

# deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: notes-apispec:  replicas: 2  selector:    matchLabels:      app: notes-api  template:    metadata:      labels:        app: notes-api    spec:      containers:        - name: api          image: notes-api:1.0          ports:            - name: http              containerPort: 3000          env:            - name: LOG_LEVEL              valueFrom:                configMapKeyRef:                  name: notes-config                  key: LOG_LEVEL            - name: DB_PASSWORD              valueFrom:                secretKeyRef:                  name: notes-db                  key: DB_PASSWORD          envFrom:            - secretRef:                name: notes-db                optional: false          volumeMounts:            - name: config              mountPath: /etc/notes              readOnly: true      volumes:        - name: config          configMap:            name: notes-config            items:              - key: app.json                path: app.json

What happens when the ConfigMap changes?

This is a very common interview trap, so slow down here. The Kubernetes docs say:

• A ConfigMap used as files (a volume) is updated eventually. The kubelet checks it on its normal sync loop, so the delay can be around a minute. Your app has to re-read the file to notice the change.
• A ConfigMap used as environment variables is never updated in a running container. The environment is fixed when the container starts. You need a new pod.
• A ConfigMap mounted with subPath also never gets updates.

(This table is from the Kubernetes docs. I could not watch it happen, because it needs a kubelet. Reviewed, not run on a cluster here.)

So how do you roll out a config change? The simplest way is to make Kubernetes replace the pods:

kubectl rollout restart deployment/notes-api

The pods are replaced one by one (a rolling update, which we study in the next lesson), and the new pods read the new values. Another popular way is to put a hash of the config into a pod annotation. When the config changes, the hash changes, the pod template changes, and Kubernetes starts a rollout by itself. Tools like Helm and Kustomize do this for you.

Immutable ConfigMaps

You can mark a ConfigMap (or a Secret) as immutable: true. After that, nobody can change its data. You must make a new one with a new name. The benefits: nobody can break running pods by a bad edit, and the cluster has less work to do, because the kubelet does not need to watch it for changes.

apiVersion: v1kind: ConfigMapmetadata:  name: notes-config-v2immutable: truedata:  LOG_LEVEL: "debug"

I created this and then tried to change debug to info. The real API server said:

The ConfigMap "notes-config-v2" is invalid: data: Forbidden: field is immutable when `immutable` is set

The usual pattern is to put a version or hash in the name (notes-config-v2) and point the Deployment at the new name. That change to the pod template triggers a normal rolling update, and rolling back is just pointing at the old name again.

Secrets: the same shape, a different intent

A Secret looks almost the same as a ConfigMap. It has a data section. The difference is the intent, and a few protections. Kubernetes can handle Secrets more carefully (for example, a kubelet keeps secret volumes in memory on the node, not on disk, and the API server can encrypt them at rest if you turn that on). You can also give different people different permissions on Secrets than on ConfigMaps.

Let me create one and look at it:

kubectl create secret generic notes-db \  --from-literal=DB_USER=notes \  --from-literal=DB_PASSWORD='s3cr3t-pw' \  --dry-run=client -o yaml

apiVersion: v1data:  DB_PASSWORD: czNjcjN0LXB3  DB_USER: bm90ZXM=kind: Secretmetadata:  name: notes-db

The values look scrambled. They are base64. Let me reverse one:

echo 'czNjcjN0LXB3' | base64 -d

s3cr3t-pw

So anyone who can read the Secret object can read the password. The Kubernetes docs even say that base64 only obscures the value, it does not make it secret. The reason Secrets use base64 is simple: a value may be binary (a certificate, a key file), and base64 lets it fit inside YAML and JSON. It is a format, not a lock.

data and stringData

In a Secret you may write values in two sections. data wants base64 text. stringData takes plain text, and the API server converts it for you. stringData is easier to write by hand:

# secret.yamlapiVersion: v1kind: Secretmetadata:  name: notes-dbtype: OpaquestringData:  DB_USER: notes  DB_PASSWORD: s3cr3t-pw

I applied this. The stored object had only data (with the base64 values) and no stringData. The stringData field is write-only convenience: it is never returned.

A leak most people do not know about: kubectl apply

When I ran kubectl get secret notes-db -o yaml after kubectl apply, I saw this:

metadata:  annotations:    kubectl.kubernetes.io/last-applied-configuration: |      {"apiVersion":"v1","kind":"Secret","metadata":{"annotations":{},"name":"notes-db","namespace":"default"},"stringData":{"DB_PASSWORD":"s3cr3t-pw","DB_USER":"notes"},"type":"Opaque"}

That is a plain text copy of my password in an annotation. kubectl apply stores the last thing you applied, so it can work out later what changed. If you apply a Secret that uses stringData, the plain value is saved there. People with permission to read the Secret can read it anyway, so it is not a new door, but it shows up in logs, kubectl get -o yaml pastes and backups. It is another reason not to manage Secrets by hand-written files. Create them with kubectl create secret (I checked: a Secret made this way had no annotations at all), or use an external secret tool, or use server-side apply.

Where does a Secret really live? I looked in etcd

The API server keeps every object in etcd. I have a real etcd in my lab, so I read the Secret straight out of it with etcdctl (a tool for reading etcd). By default, Kubernetes stores Secrets in etcd without encryption:

etcdctl get /registry/secrets/default/notes-db --print-value-only | strings | grep -c s3cr3t

2

Two lines of the stored bytes contain my password in plain text: one in the last-applied-configuration annotation and one in the data. Anyone with access to the etcd disk, or an etcd backup, could read all the Secrets in the cluster.

Now I did what the Kubernetes docs describe. I wrote an EncryptionConfiguration file and restarted the API server with --encryption-provider-config. This is the file (with the key removed):

# encryption-config.example.yamlapiVersion: apiserver.config.k8s.io/v1kind: EncryptionConfigurationresources:  - resources:      - secrets    providers:      - aescbc:          keys:            - name: key1              secret: <base64 of 32 random bytes>      - identity: {}

The first provider in the list is used to write. All providers listed are tried when reading. identity: {} means "no encryption" and it comes last so that older, unencrypted Secrets can still be read. After restarting the API server, I created a new Secret and looked at its bytes:

k8s:enc:aescbc:v1:key1:R

The stored value starts with k8s:enc:aescbc:v1:key1:, which says "encrypted with AES-CBC using key1", and the rest is unreadable. A search for the password in the stored bytes now finds 0 lines. The API still returns the real value to a caller who is allowed to read it:

kubectl get secret fresh -o jsonpath='{.data.DB_PASSWORD}' | base64 -d

s3cr3t-pw

The old Secret was still plain in etcd until I rewrote it. The docs suggest rewriting all Secrets after turning on encryption. I did that with:

kubectl get secrets -A -o json | kubectl replace -f -

and then the old notes-db Secret also started with k8s:enc:aescbc:v1:key1: and had 0 matches for the password.

Two honest notes. First, I used aescbc with the key in a file on the API server, because it is the simplest to show. The docs say a KMS provider (a key held in a cloud key service or hardware, outside the cluster) is stronger, because the key is not next to the data. Managed services like EKS, GKE and AKS have their own switch for this. Second, encryption at rest protects the disk and backups. It does nothing about someone who has legitimate API access, which brings us to RBAC.

Who can read Secrets: RBAC

RBAC (role-based access control) says which user or service account may do which action on which object. The rule to remember: get, list and watch on secrets all reveal the values. Even list does, because it returns the full objects. Also, anyone who can create a pod in a namespace can mount any Secret from that namespace into it and print it. So giving someone "create pods" is almost the same as giving "read all secrets here".

To check what an account may do, use kubectl auth can-i. In my lab I ran it as admin and as the default service account of a namespace:

$ kubectl -n lab8 auth can-i get secretsyes$ kubectl -n lab8 auth can-i get secrets --as=system:serviceaccount:lab8:defaultno

A fresh service account has no permissions by default. Keep it that way for your apps.

Secrets in env vars or in files?

Both work (secretKeyRef / secretRef for env, or a secret volume). Files are a little safer, for three reasons. Environment variables are easy to leak: crash reporters, printenv in a debug session, /proc/<pid>/environ, and child processes all see them. A file can have strict permissions. And volume-mounted Secrets are updated eventually when they change, while env vars never are. The trade-off is that many apps expect env vars. If you use env vars, make sure your app never logs them.

Other kinds of Secret

A Secret has a type. Opaque is the default ("any data"). Others have required keys, which the API checks. The ones you meet most:

The registry one deserves an example, because the ImagePullBackOff problem in lesson 8 often comes from it. This creates the Secret:

kubectl create secret docker-registry regcred \  --docker-server=registry.example.com \  --docker-username=bot --docker-password=pw \  --dry-run=client -o yaml

apiVersion: v1data:  .dockerconfigjson: eyJhdXRocyI6eyJyZWdpc3RyeS5leGFtcGxlLmNvbSI6eyJ1c2VybmFtZSI6ImJvdCIsInBhc3N3b3JkIjoicHciLCJhdXRoIjoiWW05ME9uQjMifX19kind: Secretmetadata:  name: regcredtype: kubernetes.io/dockerconfigjson

Then the pod says imagePullSecrets: [{name: regcred}] so the kubelet can log in when it pulls the image. Like all Secrets, it must be in the same namespace as the pod.

Better places for secrets

For real production use, many teams keep the source of truth outside the cluster (a cloud secret manager or a vault) and sync it in with a tool such as the External Secrets Operator or a CSI driver. Others keep encrypted Secret files in Git (Sealed Secrets, SOPS). I mention the names so you can recognise them. I did not run any of these here.

Volumes: giving a pod a folder

A container's own filesystem is thrown away when the container is replaced. Lesson 2 showed this with Docker. In Kubernetes a volume is a folder that belongs to the pod and can be mounted into one or more containers of that pod. The ConfigMap volume above is one kind. Here are the kinds you need first.

The hard question is the third row: how do you get a disk that outlives pods? Kubernetes splits that job in two, so that app developers do not need to know which cloud they run on.

PersistentVolumes and claims: the two-sided deal

Think of renting an apartment. The PersistentVolume (PV) is the apartment: a real piece of storage, such as a cloud disk or an NFS share. The PersistentVolumeClaim (PVC) is your rental request: "I need 5 GiB, I will write to it". The cluster matches the request to an apartment. Your pod then says "mount that claim".

The benefit: the developer writes the claim and never needs to know if the disk is an AWS EBS volume, a Google Persistent Disk, or a local SSD.

Static setup (an admin creates PVs by hand) is rare today. Most clusters use dynamic provisioning: you create the claim, and a StorageClass makes the PV for you.

A claim and a pod that uses it:

# storage.yamlapiVersion: v1kind: PersistentVolumeClaimmetadata:  name: uploadsspec:  accessModes:    - ReadWriteOnce  resources:    requests:      storage: 5Gi  # storageClassName omitted: the cluster default StorageClass is used---apiVersion: v1kind: Podmetadata:  name: uploaderspec:  containers:    - name: app      image: notes-api:1.0      volumeMounts:        - name: data          mountPath: /var/lib/notes/uploads  volumes:    - name: data      persistentVolumeClaim:        claimName: uploads

If you omit storageClassName, the cluster's default StorageClass is used. If the cluster has no default and there is no matching PV, the claim stays Pending. That is exactly what happened in my lab, which has no StorageClass at all. This is what a real PVC in that state looks like:

$ kubectl get pvc uploadsNAME      STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGEuploads   Pending                                                     <unset>                 0s

and the event the control plane recorded:

Normal  FailedBinding  persistentvolumeclaim/uploads  no persistent volumes available for this claim and no storage class is set

(The event type is Normal, even though the message sounds bad. It means "I tried to bind and could not yet".) The pod that uses this claim shows that it is waiting too. The scheduler said, in the real run:

Warning  FailedScheduling  default-scheduler  0/1 nodes are available: persistentvolumeclaim "no-such-claim" not found. not found

That one was my deliberate test with a claim name that does not exist. We will use it in lesson 8. For now remember: a pod with a PVC that cannot bind will stay Pending.

StorageClass

A StorageClass says how to make storage. Here is one I validated:

apiVersion: storage.k8s.io/v1kind: StorageClassmetadata:  name: fastprovisioner: example.com/fast-diskreclaimPolicy: RetainvolumeBindingMode: WaitForFirstConsumerallowVolumeExpansion: true

(example.com/fast-disk is a made-up provisioner. A real cluster uses the name of its CSI driver here. Reviewed, not run on a cluster here, other than the API server accepting it.)

Three fields matter. I read each in kubectl explain on the real server:

• volumeBindingMode: Immediate (the default) creates the disk as soon as the claim exists. WaitForFirstConsumer waits until a pod that uses the claim is scheduled, and then creates the disk in the right place. This matters because a cloud disk lives in one zone. If the disk is made in zone A and the pod lands in zone B, the pod can never start. WaitForFirstConsumer avoids that.
• reclaimPolicy: what happens to the disk when the claim is deleted. Delete (the default for dynamically provisioned volumes) deletes the real disk and your data. Retain keeps it, for you to clean up by hand. For anything precious, think about this before you delete a claim.
• allowVolumeExpansion: whether you may make a claim bigger later by editing the size. (You can grow a volume, not shrink it.)

Access modes

The trap: ordinary cloud block disks are RWO. If you scale a Deployment with a RWO claim to three replicas, pods that land on other nodes cannot mount the disk and stay stuck. One shared claim in a multi-replica Deployment is therefore a design smell. Use a StatefulSet (next), or move the shared data to object storage or a database.

Deleting things in the right order

Kubernetes has "storage object in use protection". If you delete a PVC that a pod still uses, the PVC is marked for deletion but is kept until the pod is gone. And deleting a PVC with reclaimPolicy: Delete destroys the data. Always know which policy applies before you run kubectl delete pvc.

StatefulSets: pods with names and their own disks

A Deployment treats pods as identical cattle. Pod notes-api-7888f544c5-hsp6l is replaceable by any other. A database is different. Postgres member 0 has data. Member 1 has its own copy. Each needs its own disk, and others need to find "member 0" by name.

A StatefulSet gives each pod three things:

1. A stable name with a number: pg-0, pg-1, pg-2 (the number is called the ordinal). When pg-1 is replaced, the new pod is again called pg-1.
2. A stable network name through a headless Service (a Service with clusterIP: None, from lesson 5). Each pod gets a DNS name like pg-0.pg.
3. Its own storage, made from volumeClaimTemplates. Each pod gets its own PVC (data-pg-0, data-pg-1, ...), and when the pod is replaced the same claim is attached to the new pod.

By default the pods start in order (0, then 1, then 2) and stop in the reverse order.

# statefulset.yamlapiVersion: v1kind: Servicemetadata:  name: pgspec:  clusterIP: None  selector:    app: pg  ports:    - name: postgres      port: 5432---apiVersion: apps/v1kind: StatefulSetmetadata:  name: pgspec:  serviceName: pg  replicas: 3  selector:    matchLabels:      app: pg  template:    metadata:      labels:        app: pg    spec:      containers:        - name: postgres          image: postgres:17          ports:            - name: postgres              containerPort: 5432          env:            - name: POSTGRES_PASSWORD              valueFrom:                secretKeyRef:                  name: notes-db                  key: DB_PASSWORD            - name: PGDATA              value: /var/lib/postgresql/data/pgdata          volumeMounts:            - name: data              mountPath: /var/lib/postgresql/data  volumeClaimTemplates:    - metadata:        name: data      spec:        accessModes:          - ReadWriteOnce        resources:          requests:            storage: 10Gi

(PGDATA points to a sub-folder because a fresh volume often has a lost+found folder at its root, and Postgres refuses to start in a non-empty folder. That is advice from the Postgres image docs, not something I could test here.)

Notice the sentence "create Claim data-pg-0": the claim name is <template name>-<pod name>. That is what you look for when you debug storage.

What a StatefulSet does not do

A StatefulSet gives stable identity and storage. It does not set up database replication, handle backups, or do failover. Postgres still needs to be told how to be a primary and replicas. That is why people use an operator (a program that knows how to run one particular database) rather than writing StatefulSets by hand.

Also, the PVCs of a StatefulSet are kept when you scale down or delete the StatefulSet. That is safe by default (you do not lose data by accident), but it leaves disks that you pay for. The field persistentVolumeClaimRetentionPolicy has whenDeleted and whenScaled, each Retain (default) or Delete. I confirmed that in kubectl explain on the real server.

My honest opinion for a beginner: in production, a managed database (a cloud service) is usually safer than your own Postgres in a StatefulSet. Run databases in Kubernetes when you have a good reason and an operator you trust.

Commands to know

Try it

You need kubectl and, ideally, kubeconform and a local cluster (kind, minikube or Docker Desktop). Without a cluster, steps 1 to 3 still work.

1. Create a ConfigMap with kubectl create configmap app --from-literal=MODE=prod --dry-run=client -o yaml. Then make the same ConfigMap with PAGE_SIZE: 20 (no quotes) in a file and run kubeconform -strict on it. What does it say?
2. Make a Secret with --from-literal=TOKEN=abc123 --dry-run=client -o yaml. Decode the value without any Kubernetes tool.
3. Write a Deployment that reads LOG_LEVEL from a ConfigMap as an environment variable. Run kubeconform -strict. Now change the key name configMapKeyRef to configMapKeyref and run it again.
4. On a real cluster: change the ConfigMap value after the pod started. Does printenv LOG_LEVEL in the pod change? Does a mounted file change? What do you do to make the env var update?
5. On a real cluster: create a PVC without a storage class. Is it Pending or Bound? What decides this?
6. Why would you choose WaitForFirstConsumer for a cloud cluster that spans three zones?

Answers

1. PAGE_SIZE: 20 fails with got number, want null or string. Quote it: "20".
2. echo -n 'YWJjMTIz' | base64 -d prints abc123. (Use -n when encoding so that no newline is added into the value: echo -n abc123 | base64.) The point: base64 is reversible by anyone.
3. The second run fails with additional properties 'configMapKeyref' not allowed (strict mode catches the typo).
4. The env var does not change in the running pod. A mounted file does change after a delay (unless you used subPath). To update the env var, restart the pod: kubectl rollout restart deployment/NAME.
5. It depends on whether the cluster has a default StorageClass. With one, a volume is made and (with Immediate binding) the claim becomes Bound, or it waits for a pod if the class uses WaitForFirstConsumer. With none, it stays Pending with no persistent volumes available for this claim and no storage class is set.
6. A cloud disk exists in one zone. WaitForFirstConsumer creates it after the scheduler picks a node, so the disk is in the same zone as the pod.

Interview questions

Key takeaways

• Keep settings out of the image. ConfigMaps hold normal settings, Secrets hold sensitive ones, and the pod reads them as env vars or files.
• ConfigMap and Secret values are strings. Quote numbers and booleans. kubeconform -strict and the API server both catch this.
• Env vars from a ConfigMap are fixed at container start. Volume files update later (not with subPath). Use rollout restart, a config hash, or immutable versioned ConfigMaps.
• base64 is not encryption. By default Secrets sit in etcd in plain form (I read one there). Use RBAC, encryption at rest (best with KMS), and an external secret source.
• kubectl apply can leave a plain copy of a Secret in an annotation.
• PVC asks for storage, PV is the storage, StorageClass makes it on demand. A pod that needs an unbound PVC stays Pending.
• Use WaitForFirstConsumer for zone-bound cloud disks, and check reclaimPolicy before deleting a claim.
• StatefulSets give stable names, stable DNS and a disk per pod. They do not give you database replication.
• Always run kubeconform -strict. Non-strict mode misses misspelled field names.

What's next

Next: Scaling, Rollouts and Reliability: Probes, Resources and Autoscaling, Lesson 7. Your pods now have settings, secrets and disks. Next they must stay healthy while you update and scale them. You will meet readiness and liveness probes, requests and limits, rolling updates and rollbacks, the autoscaler and PodDisruptionBudgets. Practise now: add a ConfigMap and a Secret to one of your own Deployments, and check it with kubeconform -strict.