Deploying Containers to Azure Kubernetes Service

Overview and What You Will Learn

In this lab, you will build a container image, push it to Azure Container Registry, create an AKS cluster wired to that registry, and deploy the container so it's reachable through a load-balanced public endpoint - the complete path from source code to a running, accessible service.

Why This Matters in Production

A team at Hotstar running several interdependent containerized services - a recommendation engine, a video metadata service, a user profile service - needs coordinated scaling, service discovery, and self-healing across all of them simultaneously. AKS provides exactly this orchestration layer, handling failures and scaling decisions that would otherwise require significant manual coordination across separate containers running independently.

Core Principles

The path from source code to a running AKS workload passes through three distinct stages.

Attaching ACR directly to the AKS cluster at creation time means the cluster's nodes are automatically granted permission to pull images from that registry, with no separate credential configuration needed.

Detailed Step-by-Step Practical Lab

1. Create a Resource Group and an Azure Container Registry:

2. Build a container image directly in ACR, with no local Docker installation required:

3. Create an AKS cluster, attaching the registry so nodes can pull images from it automatically:

4. Retrieve the cluster's credentials so kubectl can connect to it:

5. Deploy the container image as a Kubernetes Deployment:

6. Expose the deployment through a Kubernetes Service backed by an Azure Load Balancer, making it reachable from outside the cluster:

7. Wait for the Load Balancer to receive a public IP, then confirm the service is reachable:

8. Confirm the pod is running correctly:

9. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Manually managing ACR credentials as Kubernetes secrets instead of using --attach-acr at cluster creation. Manual credential management means those credentials can expire or be misconfigured, causing confusing image pull failures - attaching the registry directly grants pull access through the cluster's own managed identity instead.

Tip

Use kubectl describe pod <pod-name> immediately when a pod does not reach a Running state. It shows the exact reason - an image pull failure, insufficient node resources, or a failed readiness check - rather than requiring you to guess.

• Reach for AKS specifically once you have multiple interdependent containerized services, not for a single simple container that Azure Container Instances could run with far less operational overhead.
• Node count and VM size directly determine cluster capacity and cost. Start with a small node count for a lab or early-stage workload, and use the Cluster Autoscaler once real production traffic patterns are understood.

Quick Reference & Troubleshooting Commands