3.2 Monitor & Troubleshoot AKS and Container Apps

Monitor & Troubleshoot AKS and Container Apps

Quick Answer: On AKS, start with kubectl get/describe, kubectl logs, and Events to see why Pods crash or stay unready. On Azure Container Apps (ACA), use log streams and Log Analytics tied to the Container Apps environment. Always finish with connectivity checks—DNS, Ingress, and NSG/network paths—because many "app down" incidents are routing or firewall problems.

AI-200 expects you to diagnose container platforms, not only write manifests. You must know where logs live, how events explain controller decisions, and how to prove end-to-end connectivity on both AKS and Azure Container Apps.

AKS vs Azure Container Apps: Troubleshooting Posture

Choose the tool that matches the platform. Running kubectl against Container Apps will not work—the control plane is not exposed as a customer-managed Kubernetes API in the same way.

AKS: Inspect Workloads Systematically

A reliable order of operations:

1. Status — kubectl get pods,deploy,svc,ingress -n <ns> -o wide
2. Describe — kubectl describe pod <name> -n <ns> (Events at the bottom)
3. Logs — kubectl logs <pod> -n <ns> / -c <container> / --previous
4. Cluster events — kubectl get events -n <ns> --sort-by=.lastTimestamp
5. Connectivity — Endpoints, DNS, Ingress IP, NSG/firewall

kubectl describe: Conditions and Events

describe surfaces:

• Pod phase and container state (Waiting, CrashLoopBackOff, Running)
• Probe failures ("Liveness probe failed", "Readiness probe failed")
• Image pull errors and mount failures
• Scheduling messages (Insufficient CPU/memory, taints/tolerations)

Events are time-ordered clues from the kubelet and controllers. A Deployment showing ProgressDeadlineExceeded often pairs with Pod Events about failed pulls or crash loops.

kubectl logs: Application Truth

kubectl logs deploy/inference-api -n ml-apps --tail=200
kubectl logs pod/inference-api-7f9c8 -n ml-apps -c api
kubectl logs pod/inference-api-7f9c8 -n ml-apps --previous

--previous reads the last terminated container instance—essential for CrashLoopBackOff where the current container just restarted empty. Multi-container Pods require -c because logs are per container.

If logs are empty but the Pod is crashing, look at describe/Events for OOMKilled, failed mounts, or missing Secrets—those fail before useful stdout exists.

Common AKS Symptom → First Check

Azure Container Apps: Logs and Revisions

Container Apps package each deployment as a revision. Troubleshooting focuses on:

• Replica status — activating, running, failed
• Console log stream — near-real-time stdout/stderr in portal or CLI
• System logs — platform messages (scaling, ingress, Dapr if used)
• Log Analytics — query historical logs with Kusto when streaming is not enough

Typical CLI patterns:

az containerapp logs show -n myapp -g myrg --follow
az containerapp revision list -n myapp -g myrg -o table
az containerapp show -n myapp -g myrg --query properties.configuration.ingress

When a new revision fails activation, compare revision traffic weights, environment variables, secrets, and ingress external vs internal settings. Scale-to-zero can look like "the app is down" when it is simply cold-starting—check replica counts and scale rules before blaming code.

Container Apps environments share Log Analytics configuration; if queries return nothing, verify diagnostic settings and that you are querying the correct workspace table for Container App console/system logs.

Connectivity: DNS, Ingress, and Network Controls

Many container incidents are path problems. Work outside-in and inside-out.

DNS

Wrong namespace in the DNS name, stale CoreDNS, or missing private zone links produce intermittent or hard failures that never appear in application logs.

Ingress and Application Gateways

For AKS Ingress: confirm the Ingress has an ADDRESS, the controller Pods are healthy, TLS secrets exist, and path/backend Service ports match. For AGIC or Application Gateway for Containers, also check Azure-side backend pool health probes—Azure may mark backends unhealthy even when kubectl logs looks fine.

For Container Apps: confirm ingress is enabled, traffic mode (external/internal), and that the client uses the correct FQDN and HTTPS settings. Internal ingress requires network path into the environment's VNet.

NSG, Firewall, and Network Policy

When Pods are Running and logs look healthy but external users time out, prioritize NSG effective security rules, load balancer health probe status, and whether the Ingress public IP is reachable. When only some Pod-to-Pod calls fail, inspect NetworkPolicies and CoreDNS.

End-to-End Connectivity Checklist

Use this exam-friendly sequence:

1. Container healthy? Logs without crash loops; readiness Passing
2. Service layer? AKS Endpoints non-empty / ACA ingress shows running replicas
3. Edge routing? Ingress/App Gateway/Container Apps URL returns expected status from inside Azure
4. Client path? Public DNS and TLS; NSG allows client → frontend; no corporate proxy MITM surprises
5. Dependencies? App can resolve and reach databases/APIs (egress NSG, private endpoints, connection strings)

Observability Add-ons

Production AKS often enables Container Insights (Azure Monitor) for node/Pod metrics and log aggregation. Container Apps lean on Log Analytics and metrics in Azure Monitor. Knowing which store holds historical data matters when the live log stream has already rotated.

Putting It Together

Treat AKS troubleshooting as Kubernetes-native: describe → events → logs → Endpoints → network. Treat Container Apps as managed revision/replica diagnostics plus environment logs. In both worlds, prove connectivity separately from application exceptions. That split—platform signal versus app signal versus network path—is what AI-200 scenarios test when a containerized solution "does not work" on Azure.