Why managed Kubernetes matters in Azure - Why It Works

Introduction

Running Kubernetes on your own means handling many complex tasks like setup, updates, and fixing problems. Managed Kubernetes services take care of these tasks for you, so you can focus on building your apps instead of managing infrastructure.

When you want to deploy containerized apps without spending time on Kubernetes setup and maintenance

When you need automatic updates and security patches for your Kubernetes cluster

When you want to scale your app easily without managing the underlying servers

When you prefer a cloud provider to handle backups and recovery for your Kubernetes environment

When you want integrated monitoring and logging without extra setup

Commands

This command creates a managed Kubernetes cluster in Azure with 2 nodes. Azure handles the control plane and maintenance for you.

Terminal

az aks create --resource-group example-group --name example-cluster --node-count 2 --enable-managed-identity --generate-ssh-keys

Expected Output

Waiting for AAD role to propagate

{

  "agentPoolProfiles": [

    {

      "count": 2,

      "maxPods": 110,

      "name": "nodepool1",

      "osType": "Linux",

      "type": "VirtualMachineScaleSets",

      "vmSize": "Standard_DS2_v2"

    }

  ],

  "fqdn": "example-cluster-12345.hcp.eastus.azmk8s.io",

  "id": "/subscriptions/xxxx/resourceGroups/example-group/providers/Microsoft.ContainerService/managedClusters/example-cluster",

  "location": "eastus",

  "name": "example-cluster",

  "nodeResourceGroup": "MC_example-group_example-cluster_eastus",

  "provisioningState": "Succeeded",

  "resourceGroup": "example-group",

  "type": "Microsoft.ContainerService/ManagedClusters"

}

→

--node-count - Sets the number of worker nodes in the cluster

→

--enable-managed-identity - Uses Azure managed identity for secure cluster operations

→

--generate-ssh-keys - Creates SSH keys automatically for node access

This command downloads the cluster credentials so you can manage the cluster using kubectl.

Terminal

az aks get-credentials --resource-group example-group --name example-cluster

Expected Output

Merged "example-cluster" as current context in /home/user/.kube/config

→

--resource-group - Specifies the resource group of the cluster

→

--name - Specifies the name of the cluster

This command lists the worker nodes in your managed Kubernetes cluster to verify it is running.

Terminal

kubectl get nodes

Expected Output

NAME                                STATUS   ROLES   AGE   VERSION

aks-nodepool1-12345678-vmss000000   Ready    agent   5m    v1.26.1

Key Concept

If you remember nothing else from this pattern, remember: managed Kubernetes lets you run containers without worrying about the complex setup and maintenance.

Common Mistakes

Trying to manage Kubernetes control plane yourself instead of using managed service

It adds unnecessary complexity and risk of misconfiguration

Use Azure Kubernetes Service (AKS) to handle control plane and updates automatically

Not downloading cluster credentials before running kubectl commands

kubectl cannot connect to the cluster without credentials

Run 'az aks get-credentials' to configure kubectl access

Summary

Create a managed Kubernetes cluster with 'az aks create' to let Azure handle control plane and maintenance.

Download cluster credentials using 'az aks get-credentials' to manage the cluster with kubectl.

Verify cluster nodes with 'kubectl get nodes' to confirm your managed Kubernetes is running.

Practice

1. What is the main benefit of using managed Kubernetes services like Azure Kubernetes Service (AKS)?

easy

A. It handles infrastructure tasks like updates and scaling automatically.

B. It requires you to manually configure all cluster components.

C. It only supports Windows containers.

D. It eliminates the need for containerization.

Solution

1. Step 1: Understand managed Kubernetes purpose

   Managed Kubernetes services automate infrastructure tasks such as updates, scaling, and security.

2. Step 2: Compare options

   Options B, C, and D are incorrect because they either require manual setup, limit container types, or misunderstand containerization benefits.

3. Final Answer:

   It handles infrastructure tasks like updates and scaling automatically. -> Option A

4. Quick Check:

   Managed Kubernetes automates infrastructure tasks = A [OK]

Hint: Managed means cloud handles setup and scaling for you [OK]

Common Mistakes:

• Thinking you must manage all cluster setup manually
• Believing managed Kubernetes only supports certain container types
• Confusing containerization with Kubernetes management

2. Which of the following is the correct Azure CLI command to create a managed Kubernetes cluster named myCluster in resource group myGroup?

easy

A. az aks create --resource-group myGroup --name myCluster --node-count 3 --enable-addons monitoring

B. az k8s create --group myGroup --cluster myCluster --nodes 3

C. az aks deploy --resource-group myGroup --cluster-name myCluster --count 3

D. az container create --resource-group myGroup --name myCluster --count 3

Solution

1. Step 1: Identify correct Azure CLI syntax for AKS creation

   The correct command uses az aks create with parameters --resource-group, --name, and --node-count.

2. Step 2: Evaluate options

   az aks create --resource-group myGroup --name myCluster --node-count 3 --enable-addons monitoring matches the correct syntax. Options B, C, and D use incorrect commands or parameters.

3. Final Answer:

   az aks create --resource-group myGroup --name myCluster --node-count 3 --enable-addons monitoring -> Option A

4. Quick Check:

   Correct Azure CLI command for AKS creation = A [OK]

Hint: Use 'az aks create' with resource group and name [OK]

Common Mistakes:

• Using 'az k8s' instead of 'az aks'
• Mixing parameters like --cluster-name instead of --name
• Confusing container creation with cluster creation

3. Given the following Azure CLI command output snippet after creating an AKS cluster, what does the nodeResourceGroup field represent?

{
  "name": "myCluster",
  "nodeResourceGroup": "MC_myGroup_myCluster",
  "kubernetesVersion": "1.24.6",
  "provisioningState": "Succeeded"
}

medium

A. The resource group for Azure Active Directory.

B. The resource group where the AKS cluster nodes are deployed.

C. The resource group for Azure Container Registry.

D. The resource group where user applications are stored.

Solution

1. Step 1: Understand nodeResourceGroup meaning

   The nodeResourceGroup is a system-generated resource group that contains the infrastructure resources for the AKS nodes.

2. Step 2: Eliminate incorrect options

   Options A, B, and C refer to unrelated resource groups for identity services, user applications, or container registry.

3. Final Answer:

   The resource group where the AKS cluster nodes are deployed. -> Option B

4. Quick Check:

   nodeResourceGroup = AKS nodes resource group [OK]

Hint: nodeResourceGroup holds cluster node resources [OK]

Common Mistakes:

• Confusing nodeResourceGroup with app resource group
• Assuming it relates to container registry
• Mixing it up with identity or directory groups

4. You tried to scale your AKS cluster using the command az aks scale --resource-group myGroup --name myCluster --node-count 5 but got an error. What is the most likely cause?

medium

A. The az aks scale command does not exist; you should use az aks update instead.

B. You must delete the cluster before changing node count.

C. Scaling is not supported on managed Kubernetes clusters.

D. You need to specify the node pool name with --nodepool-name when scaling.

Solution

1. Step 1: Check correct command usage for scaling AKS

   Scaling requires specifying the node pool name using --nodepool-name with az aks scale.

2. Step 2: Analyze options

   The az aks scale command does not exist; you should use az aks update instead. is wrong because az aks scale exists. Scaling is not supported on managed Kubernetes clusters. is false; scaling is supported. You must delete the cluster before changing node count. is incorrect; no need to delete cluster.

3. Final Answer:

   You need to specify the node pool name with --nodepool-name when scaling. -> Option D

4. Quick Check:

   Scaling AKS requires node pool name = B [OK]

Hint: Always include --nodepool-name when scaling nodes [OK]

Common Mistakes:

• Omitting --nodepool-name parameter
• Thinking scaling is unsupported
• Trying to delete cluster to scale nodes

5. You want to ensure your AKS cluster automatically updates to the latest patch version for security without downtime. Which managed Kubernetes feature should you enable?

hard

A. Disable node auto-scaling

B. Manual upgrade triggered by user only

C. Cluster auto-upgrade with surge upgrades enabled

D. Use a single-node cluster to avoid complexity

Solution

1. Step 1: Identify feature for automatic, zero-downtime upgrades

   Cluster auto-upgrade with surge upgrades allows patch updates with minimal downtime by upgrading nodes in batches.

2. Step 2: Evaluate other options

   Manual upgrade requires user action, disabling auto-scaling doesn't affect upgrades, and single-node clusters increase downtime risk.

3. Final Answer:

   Cluster auto-upgrade with surge upgrades enabled -> Option C

4. Quick Check:

   Auto-upgrade with surge = zero downtime updates [OK]

Hint: Enable auto-upgrade with surge for smooth updates [OK]

Common Mistakes:

• Relying on manual upgrades only
• Disabling auto-scaling thinking it helps upgrades
• Using single-node clusters for production