Workloads & config

An app often needs a different database address in dev and production. If that address is baked into the image, each environment needs a different build. Instead, make the app read a setting supplied at runtime. A ConfigMap holds ordinary values such as the database hostname; a Secret holds sensitive values such as an API key. A pod can read either as environment variables or mounted files. Changing those objects does not automatically refresh every running process: environment variables usually require new pods, while mounted files can update if the app rereads them.

Base64 is not encryption. A person allowed to read a Kubernetes Secret through the API can decode its value. AKS encrypts managed disks at rest by default; optional KMS encryption protects Secret values before they are written to etcd. Neither changes what an authorized API reader can see.¹ Limit who can read Secrets, never commit a Secret manifest containing real credentials, and choose storage and rotation controls from the threat model.

For credentials managed in Azure, §27e introduces Microsoft Entra Workload Identity and Azure Key Vault. The workload can authenticate without a long-lived Azure credential stored in the pod, then fetch an authorized secret from Key Vault. A Kubernetes Secret can also be appropriate when access, encryption and rotation meet the requirement. The key question is who can read the value, how it is protected and rotated, and whether the application needs a restart after a change.

A process that is running is not the same as a process that is working, and a process that is working is not the same as one that is ready to take traffic. Kubernetes will not guess the difference; you tell it, with three probes it runs on a schedule. A liveness probe answers "is this container still healthy, or has it wedged?" — if it fails, the kubelet kills and restarts the container. A readiness probe answers "should this pod receive traffic right now?" — if it fails, the pod is pulled out of its Service's endpoints but left running, so a pod that is warming up or briefly overloaded stops getting requests without being killed.

The third exists because slow starters get murdered by the first. A startup probe guards an app that needs thirty seconds to load before it can answer anything: while the startup probe is still failing, the liveness probe is held back, so a legitimately slow boot is not mistaken for a hang and restarted into an endless crash loop. Get these wrong in either direction and you feel it. No readiness probe, and traffic hits a pod before it can serve, so users see errors during every deploy. A liveness probe pointed at a dependency you do not control, and an outage in that dependency makes Kubernetes restart your healthy pods on a loop, turning a small problem into a self-inflicted one.

A node has finite CPU and memory. A container's request tells the scheduler how much capacity to account for when placing its pod; CPU requests also affect the container's share during contention. A limit controls maximum use: CPU can be throttled, while crossing a memory limit can cause an OOM kill. Requests that are too high leave pods pending; requests that are too low can pack more work on a node than it handles well. Measure actual usage and revisit both settings as load changes.

At a CPU limit, the runtime throttles the container; the symptom may be slow responses. At a memory limit, the kernel can terminate it, and Kubernetes reports OOMKilled. Whether the container restarts depends on the pod's restart policy. Inspect kubectl describe pod and recent usage before deciding whether the limit is too low or the app is leaking memory.

Over memory you are killed; over CPU you are throttled.

More load may require more app copies, more nodes, or both. A Horizontal Pod Autoscaler (HPA) changes the requested replica count using a configured metric. For CPU-utilization scaling, it compares measured CPU with the container's CPU request, so that request must be set. Other metric types have different requirements. The HPA also needs working metrics collection; check its status rather than assuming the signal is available.

The HPA can request ten pods, but some may stay Pending if they cannot be scheduled. An enabled cluster autoscaler can add nodes for pods blocked by resource capacity, within the pool's configured maximum and subscription quota. It cannot fix every Pending cause, such as an invalid image or incompatible placement rule. First read the pod's events. The distinction remains useful: the HPA requests pod replicas; the cluster autoscaler can change node count.

One more name to know but not yet wire up: KEDA, an event-driven autoscaler add-on for AKS. Where the HPA scales on CPU and memory, KEDA scales on the size of a queue, the lag on a topic, or a scheduled time — and it can scale a workload to zero when there is nothing to do. It is the right tool for a job that is bursty and event-shaped rather than steadily loaded; note where it lives so you reach for it when a queue, not a CPU graph, is what should drive your replica count.

Horizontal Pod Autoscaler

Changes desired pod replicas against a configured metric. CPU-utilization targets need CPU requests and working metrics. Answers "how many copies?"

Cluster autoscaler

When enabled, adjusts nodes in a pool for eligible unschedulable pods or safe scale-down, within limits. Answers "is there capacity for the copies?"

KEDA (add-on)

Event-driven scaling on queues, topics, or schedules — and down to zero. For bursty, event-shaped work rather than steady CPU load.

Take the objects from §1 through §4 and they are not four features; they are one hardened workload. Config and secrets come from outside the image, so the same build runs everywhere. Probes let the cluster route around a pod that is warming up and restart one that has truly wedged. Requests and limits make the pod a good tenant of its node, guaranteed its share and barred from eating its neighbours'. And an HPA turns a traffic spike into more replicas instead of a queue of dying pods. None of it is exotic; all of it is the difference between a demo and something you can leave running.

The order matters, too. You cannot sanely add an HPA before you have set requests, because the HPA measures against them; you should not set a memory limit without watching real usage first, or you are just guessing at the altitude where OOMKilled starts. So the honest sequence is: externalise config, add probes, observe real CPU and memory, set requests and limits from what you saw, then add the autoscaler on top. Each step earns the next, and doing them out of order is how a workload that looked fine in the demo falls over the first busy afternoon.