Deploying workloads to AKS in Azure - Step-by-Step Execution

Process Flow - Deploying workloads to AKS

Write Kubernetes YAML manifest

↓

Connect to AKS cluster

↓

Run kubectl apply -f manifest

↓

Kubernetes API receives manifest

↓

Scheduler assigns pods to nodes

↓

Pods start running workload

↓

Check pod status and logs

↓

Workload deployed and accessible

This flow shows how a workload defined in a YAML file is deployed step-by-step to an AKS cluster using kubectl.

Execution Sample

Azure

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp
    image: nginx

This YAML defines a simple pod running an nginx container to be deployed on AKS.

Process Table

Step	Action	Input/Command	Result/State Change
1	Write manifest	YAML pod definition	Pod manifest ready to deploy
2	Connect to AKS	az aks get-credentials	kubectl configured to AKS cluster
3	Deploy workload	kubectl apply -f pod.yaml	API server receives pod manifest
4	Schedule pod	Kubernetes scheduler	Pod assigned to a node
5	Start pod	Kubelet on node	Container starts running nginx
6	Check status	kubectl get pods	Pod status is Running
7	Check logs	kubectl logs myapp-pod	Nginx logs displayed
8	Access workload	curl pod IP or service	Nginx welcome page served
9	Exit	Workload running	Deployment complete and stable

💡 Workload is deployed and running successfully on AKS cluster

Status Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	Final
Pod Manifest	Not created	Created and applied	Scheduled to node	Running container	Running pod
kubectl Context	Not set	Set to AKS cluster	Same	Same	Same
Pod Status	None	Pending	Scheduled	Running	Running

Key Moments - 3 Insights

Why does the pod status show 'Pending' after applying the manifest?

After applying the manifest (Step 3), the pod is created but not yet scheduled to a node. It stays 'Pending' until the scheduler assigns it (Step 4).

What happens if kubectl is not configured to the AKS cluster?

If kubectl context is not set (Step 2), the apply command will fail because it cannot reach the AKS API server to deploy the workload.

How do we verify the workload is running correctly?

By checking pod status (Step 6) and viewing logs (Step 7), we confirm the container is running and serving as expected.

Visual Quiz - 3 Questions

Look at the execution table, what is the pod status immediately after Step 3?

A Pending

B Running

C Succeeded

D Failed

💡 Hint

Check the 'Pod Status' variable in variable_tracker after Step 3

At which step does the pod get assigned to a node?

A Step 2

B Step 4

C Step 3

D Step 5

💡 Hint

Look at the 'Action' column in execution_table for scheduling

If kubectl is not connected to AKS, what will happen at Step 3?

A Pod will be scheduled anyway

B Pod will start running locally

C kubectl apply will fail

D Pod status will be Running

💡 Hint

Refer to key_moments about kubectl context configuration

Concept Snapshot

Deploying workloads to AKS:
- Write Kubernetes YAML manifest (pods, deployments)
- Connect kubectl to AKS cluster (az aks get-credentials)
- Run 'kubectl apply -f manifest.yaml' to deploy
- Kubernetes schedules pods to nodes
- Pods start containers and run workload
- Check status with 'kubectl get pods'
- View logs with 'kubectl logs <pod>'

Full Transcript

To deploy workloads to AKS, first write a Kubernetes YAML manifest describing your pod or deployment. Then connect your kubectl tool to the AKS cluster using 'az aks get-credentials'. Next, deploy the workload by running 'kubectl apply -f' with your manifest file. The Kubernetes API server receives this manifest and creates the pod resource. The scheduler assigns the pod to a node, where the kubelet starts the container. You can check the pod status with 'kubectl get pods' and view logs with 'kubectl logs'. Once the pod is running, your workload is deployed and accessible.

Practice

1. What is the main purpose of using a Deployment in Azure Kubernetes Service (AKS)?

easy

A. To monitor the health of the AKS cluster nodes

B. To manage and maintain a specified number of app copies running

C. To expose the app to the internet

D. To store data persistently for the app

Solution

1. Step 1: Understand Deployment role in AKS

   A Deployment ensures that a specified number of replicas of an app are running and manages updates to those replicas.

2. Step 2: Differentiate from other components

   Persistent storage is handled by volumes, exposure by Services, and monitoring by Azure Monitor, not Deployments.

3. Final Answer:

   To manage and maintain a specified number of app copies running -> Option B

4. Quick Check:

   Deployment manages app replicas = A [OK]

Hint: Deployments keep app copies running smoothly [OK]

Common Mistakes:

• Confusing Deployment with Service for exposure
• Thinking Deployment stores data
• Assuming Deployment monitors nodes

2. Which kubectl command correctly applies a YAML file named app-deployment.yaml to deploy an app to AKS?

easy

A. kubectl create app-deployment.yaml

B. kubectl run app-deployment.yaml

C. kubectl apply -f app-deployment.yaml

D. kubectl deploy app-deployment.yaml

Solution

1. Step 1: Identify correct kubectl syntax for applying YAML

   The command to apply a YAML file is kubectl apply -f filename.yaml.

2. Step 2: Check other options for correctness

   kubectl create requires resource type, kubectl run is for quick pod creation, and kubectl deploy is not a valid command.

3. Final Answer:

   kubectl apply -f app-deployment.yaml -> Option C

4. Quick Check:

   Apply YAML file = kubectl apply -f [OK]

Hint: Use 'kubectl apply -f' to deploy YAML files [OK]

Common Mistakes:

• Using 'kubectl create' without resource type
• Trying 'kubectl deploy' which doesn't exist
• Confusing 'kubectl run' with applying YAML

3. Given this YAML snippet for an AKS Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: nginx:latest
        ports:
        - containerPort: 80

How many pods will AKS try to run for this Deployment?

medium

A. 3

B. 2

C. 1

D. 0

Solution

1. Step 1: Identify the replicas count in the YAML

   The replicas field is set to 3, meaning AKS will run 3 pods.

2. Step 2: Confirm no other fields override replicas

   There is no override or scaling specified, so the number remains 3.

3. Final Answer:

   3 -> Option A

4. Quick Check:

   replicas: 3 means 3 pods [OK]

Hint: Check 'replicas' field for pod count [OK]

Common Mistakes:

• Ignoring the replicas field
• Confusing selector labels with pod count
• Assuming default pod count is 1

4. You applied a Deployment YAML but your pods are stuck in 'Pending' state. Which of these is the most likely cause?

medium

A. The container image name is misspelled

B. The Service type is set to ClusterIP

C. The Deployment YAML is missing the 'replicas' field

D. There are not enough cluster resources to schedule pods

Solution

1. Step 1: Understand what 'Pending' pod state means

   Pods in 'Pending' usually wait for resources like CPU or memory to be available on nodes.

2. Step 2: Evaluate options for causing Pending state

   Misspelled image causes ImagePull errors, missing replicas defaults to 1, and Service type doesn't affect pod scheduling.

3. Final Answer:

   There are not enough cluster resources to schedule pods -> Option D

4. Quick Check:

   Pending pods = resource shortage [OK]

Hint: Pending pods often mean no resources available [OK]

Common Mistakes:

• Confusing image pull errors with Pending state
• Thinking missing replicas stops pod creation
• Assuming Service type affects pod scheduling

5. You want to expose your AKS Deployment to the internet with a stable IP and load balancing. Which Kubernetes Service type should you use in your YAML?

hard

A. LoadBalancer

B. NodePort

C. ClusterIP

D. ExternalName

Solution

1. Step 1: Identify Service types and their purposes

   ClusterIP exposes service inside cluster only, NodePort exposes on node ports, LoadBalancer creates cloud load balancer with stable IP, ExternalName maps to external DNS.

2. Step 2: Choose Service type for internet exposure with stable IP

   LoadBalancer is the correct choice to get a cloud-managed IP and load balancing for external access.

3. Final Answer:

   LoadBalancer -> Option A

4. Quick Check:

   Internet exposure with stable IP = LoadBalancer [OK]

Hint: Use LoadBalancer Service for external stable IP [OK]

Common Mistakes:

• Using ClusterIP which is internal only
• Choosing NodePort which uses random ports
• Confusing ExternalName with load balancing