Microsoft Azure

Containers — AKS & Container Apps

Run containers via managed Kubernetes (AKS) or serverless containers (Container Apps/ACI).

Two ways to run containers, and the honest answer is that most teams should start with the simpler one.

AKS is leasing a full industrial kitchen with every appliance and the responsibility to run it. Container Apps is a managed food-court stall that expands and contracts staff automatically and closes entirely when no customers are around. ACI is hiring a single chef for one quick job and paying by the minute.

Key Concepts

1
    AKS             managed Kubernetes. Full API, full ecosystem.
    Container Apps  serverless containers on Kubernetes you never see.
    ACI             a single container, per-second billing.
2
AKS gives you Kubernetes. Azure runs the control plane — free on the standard tier — and you run and pay for node pools. You get the whole API, Helm, operators, and portability, along with the operational weight: upgrades, node patching, capacity planning.
3
Container Apps hides it. Built on Kubernetes, KEDA, Dapr and Envoy, it runs containers with autoscaling including scale to zero, revisions with traffic splitting, and managed ingress — without you touching a node.
4
    scale rules: HTTP concurrency, queue length, CPU, any KEDA scaler
    revisions:   send 10% to the new one, then 100%
    Dapr:        service discovery, pub/sub, state, out of the box
5
Scale to zero is the headline. An internal service used during office hours costs nothing overnight, which AKS cannot do for a node pool.
6
When to choose which.
    starting out, few services     Container Apps
    need the Kubernetes API,
      operators, custom scheduling AKS
    existing Kubernetes skills     AKS
    event-driven, spiky, scale to zero  Container Apps
    one-off or burst container     ACI
7
Workload identity is the right auth model on both: the pod or app gets an Entra identity and calls Azure services with no secret.
8
On AKS, the things that actually cause incidents.
    no resource requests/limits -> noisy neighbours, evictions
    no PodDisruptionBudget      -> an upgrade drains everything
    node pool in one zone       -> a zone outage is a full outage
    cluster autoscaler not configured -> pending pods forever
9
Node pools should be separated — system pods on one, user workloads on another — so a workload cannot starve the cluster's own components.
10
What the interviewer is probing.1. "AKS or Container Apps?" Probing: whether the default is justified. Stalls: "AKS, it is Kubernetes." Moves up: Container Apps unless you need the Kubernetes API, operators or custom scheduling — it gives autoscaling including scale to zero with no nodes to manage.
11
2. "What does scale to zero change about cost?" Probing: the economics. Stalls: "It saves a little." Moves up: an internal service used in office hours costs nothing overnight, which an AKS node pool cannot do.
12
3. "How should a pod authenticate to Azure services?" Probing: workload identity. Stalls: "A secret in the cluster." Moves up: workload identity, so the pod gets an Entra identity and a short-lived token with no secret stored.
13
4. "What causes most AKS incidents?" Probing: the operational basics. Stalls: "Kubernetes is complex." Moves up: missing resource requests and limits, no PodDisruptionBudget so an upgrade drains everything, and single-zone node pools.