Deploying workloads to AKS in Azure - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
When deploying workloads to Azure Kubernetes Service (AKS), it is important to understand how the deployment time changes as the number of workloads grows.
We want to know how the time to deploy scales when adding more workloads.
Analyze the time complexity of deploying multiple container workloads to AKS using Azure CLI commands.
az aks create --resource-group myResourceGroup --name myAKSCluster --node-count 3 --enable-addons monitoring --generate-ssh-keys
for workload in workloads:
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
kubectl apply -f workload.yaml
This sequence creates an AKS cluster once, then deploys each workload by applying its configuration to the cluster.
- Primary operation: Applying workload configuration with
kubectl apply. - How many times: Once per workload, so it repeats as many times as there are workloads.
- Fetching cluster credentials with
az aks get-credentialsalso repeats per workload but usually cached after first time.
Each workload requires a separate apply operation, so the total deployment time grows as you add more workloads.
| Input Size (n) | Approx. API Calls/Operations |
|---|---|
| 10 | 10 apply operations |
| 100 | 100 apply operations |
| 1000 | 1000 apply operations |
Pattern observation: The number of apply operations grows directly with the number of workloads.
Time Complexity: O(n)
This means the deployment time increases in a straight line as you add more workloads.
[X] Wrong: "Deploying multiple workloads happens all at once, so time stays the same no matter how many workloads."
[OK] Correct: Each workload requires its own deployment step, so time adds up with each one.
Understanding how deployment time grows helps you plan and explain scaling strategies clearly in real projects.
"What if we deployed all workloads using a single combined configuration file? How would the time complexity change?"
Practice
Solution
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.Step 2: Differentiate from other components
Persistent storage is handled by volumes, exposure by Services, and monitoring by Azure Monitor, not Deployments.Final Answer:
To manage and maintain a specified number of app copies running -> Option BQuick Check:
Deployment manages app replicas = A [OK]
- Confusing Deployment with Service for exposure
- Thinking Deployment stores data
- Assuming Deployment monitors nodes
kubectl command correctly applies a YAML file named app-deployment.yaml to deploy an app to AKS?Solution
Step 1: Identify correct kubectl syntax for applying YAML
The command to apply a YAML file iskubectl apply -f filename.yaml.Step 2: Check other options for correctness
kubectl createrequires resource type,kubectl runis for quick pod creation, andkubectl deployis not a valid command.Final Answer:
kubectl apply -f app-deployment.yaml -> Option CQuick Check:
Apply YAML file = kubectl apply -f [OK]
- Using 'kubectl create' without resource type
- Trying 'kubectl deploy' which doesn't exist
- Confusing 'kubectl run' with applying YAML
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?
Solution
Step 1: Identify the replicas count in the YAML
Thereplicasfield is set to 3, meaning AKS will run 3 pods.Step 2: Confirm no other fields override replicas
There is no override or scaling specified, so the number remains 3.Final Answer:
3 -> Option AQuick Check:
replicas: 3 means 3 pods [OK]
- Ignoring the replicas field
- Confusing selector labels with pod count
- Assuming default pod count is 1
Solution
Step 1: Understand what 'Pending' pod state means
Pods in 'Pending' usually wait for resources like CPU or memory to be available on nodes.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.Final Answer:
There are not enough cluster resources to schedule pods -> Option DQuick Check:
Pending pods = resource shortage [OK]
- Confusing image pull errors with Pending state
- Thinking missing replicas stops pod creation
- Assuming Service type affects pod scheduling
Solution
Step 1: Identify Service types and their purposes
ClusterIPexposes service inside cluster only,NodePortexposes on node ports,LoadBalancercreates cloud load balancer with stable IP,ExternalNamemaps to external DNS.Step 2: Choose Service type for internet exposure with stable IP
LoadBalanceris the correct choice to get a cloud-managed IP and load balancing for external access.Final Answer:
LoadBalancer -> Option AQuick Check:
Internet exposure with stable IP = LoadBalancer [OK]
- Using ClusterIP which is internal only
- Choosing NodePort which uses random ports
- Confusing ExternalName with load balancing
