4.1.6.4. Deploy Applications to AKS

4.1.6.4. Deploy Applications to AKS

💡 First Principle: Deploying applications to AKS is a declarative process, using Kubernetes manifests to define the desired state of the application, which Kubernetes then works to achieve and maintain.

Scenario: You have a new microservice packaged as a Docker image in Azure Container Registry. You need to deploy multiple replicas of this microservice to your AKS cluster, expose it internally to other services in the cluster, and also expose it externally via an HTTP endpoint for public access.

What It Is: Deploying applications to AKS involves using Kubernetes objects defined in YAML files (manifests) to tell Kubernetes how to manage your containerized applications.

Kubernetes Manifests: Applications are deployed by writing YAML manifests that specify the configuration for Kubernetes objects.

Essential Kubernetes Objects:

• Deployment: Ensures a specified number of identical pods (container instances) are running and manages rolling updates.
• Service: Exposes deployments to the network, providing stable endpoints.
• Ingress: Manages external HTTP/HTTPS access to services.

High-Level Deployment Steps:

1. Connect to AKS: Use az aks get-credentials to configure kubectl.
2. Apply Manifests: Deploy resources with kubectl apply -f <manifest.yaml>.
3. Monitor Status: Check progress using kubectl get pods, kubectl get services, etc.

Practical Implementation: Sample Deployment YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: myregistry.azurecr.io/myapp:v1
        ports:
        - containerPort: 80
---

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: my-app

Visual: AKS Application Deployment with Kubernetes Objects

⚠️ Common Pitfall: Exposing a deployment directly with a LoadBalancer service for every microservice. This can become expensive and complex. For multiple HTTP services, it's better to use an Ingress controller to manage external access through a single load balancer.

Key Trade-Offs:

• Simplicity (LoadBalancer Service) vs. Flexibility/Cost (Ingress): A LoadBalancer service is simple for exposing one service. An Ingress is more complex to set up but provides more flexible routing and is more cost-effective for exposing multiple services.

Reflection Question: How does declaratively defining your application's desired state using Kubernetes manifests (e.g., Deployment, Service, Ingress) fundamentally simplify deploying, managing, and scaling containerized applications to AKS by offloading operational complexity to Kubernetes?

Theory builds understanding, but hands-on practice builds confidence. Complete these Microsoft Learn labs to reinforce the concepts from this phase with real Azure environments:

Lab 1: Create a Windows Virtual Machine in Azure Focus: Deploy VMs, configure networking, manage disks

Lab 2: Manage Virtual Machines with the Azure CLI Focus: CLI-based VM management, resize, start/stop

Lab 3: Deploy a Website with Azure App Service Focus: Create App Service plans, deploy apps, configure slots

Lab 4: Introduction to Azure Kubernetes Service Focus: Deploy AKS clusters and manage containerized workloads

⚠️ Tip: These labs use free Azure sandbox environments — no personal subscription or credit card required. Complete them after reading the study material but before attempting the practice questions for maximum retention.