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

Loading diagram...

⚠️ 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?