01: Exploring the AKS Cluster

01: Exploring the AKS Cluster

Overview

This is a guided tour exercise. The instructor creates and configures the AKS cluster; participants connect to it and explore its components using kubectl. By the end of this exercise, you will understand how the cluster is structured and how to navigate it from the command line.

Objective

• Connect to the AKS cluster using the kubeconfig provided by the instructor
• Explore nodes, system pods, and API resources
• Understand node pools (system vs user) and VM scale sets
• Become comfortable using kubectl for cluster exploration

Theory

AKS Cluster Components

An AKS cluster consists of:

• Managed control plane — API server, etcd, scheduler, controller managers (managed by Microsoft, invisible to you).
• Node pools — Groups of VMs (Azure VM Scale Sets) that run your workloads.
• Networking — Virtual network, subnets, load balancers, DNS.
• Add-ons — Optional components like app-routing (nginx ingress), monitoring, Azure Policy.

Node Pools

AKS uses two types of node pools:

VM Scale Sets

Each node pool is backed by an Azure VM Scale Set (VMSS). This means:

• Nodes in a pool share the same VM size, OS image, and configuration.
• Scaling is done by adding/removing VMs from the scale set.
• AKS manages the scale set lifecycle (you should not modify VMSS directly).

graph TB
    subgraph AKS["AKS Cluster"]
        subgraph CP["Control Plane (Microsoft-managed)"]
            API[API Server]
        end
        subgraph SP["System Node Pool (VMSS)"]
            SN1[Node 1]
            SN2[Node 2]
        end
        subgraph UP["User Node Pool (VMSS)"]
            UN1[Node 1]
            UN2[Node 2]
            UN3[Node 3]
        end
    end

    API --> SP
    API --> UP

    SN1 --- CoreDNS[CoreDNS]
    SN1 --- Metrics[metrics-server]
    SN2 --- CCM[cloud-controller-manager]

    UN1 --- App1[Your App Pod]
    UN2 --- App2[Your App Pod]
    UN3 --- App3[Your App Pod]

Instructor Demo: Creating the AKS Cluster

Note: This section is for instructor reference. Participants do NOT need to run these commands.

az aks create Command Walkthrough

az aks create \
  --resource-group training-rg \
  --name training-cluster \
  --node-count 3 \
  --node-vm-size Standard_D2s_v5 \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --network-dataplane cilium \
  --enable-app-routing \
  --disable-rbac \
  --generate-ssh-keys

Key Flags Explained

Practical Tasks

Task 1: Connect to the Cluster

Connect to the shared AKS cluster. The instructor will provide the resource group name and cluster name.

# Install kubectl and kubelogin (if not already installed)
az aks install-cli

# Download kubeconfig from AKS
az aks get-credentials \
  --resource-group <RESOURCE_GROUP> \
  --name <CLUSTER_NAME>

# Convert kubeconfig to use kubelogin for Azure authentication
kubelogin convert-kubeconfig -l azurecli

# Verify connection
kubectl cluster-info

# Set your personal namespace as default
kubectl config set-context --current --namespace=student-XX

Note: kubelogin is the Azure authentication plugin for kubectl. After kubelogin convert-kubeconfig, all subsequent kubectl commands authenticate via Entra ID automatically.

Expected output for kubectl cluster-info:

Kubernetes control plane is running at https://<cluster-name>.<region>.azmk8s.io:443
CoreDNS is running at https://<cluster-name>.<region>.azmk8s.io:443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Task 2: Examine Nodes

# List all nodes with extended details
kubectl get nodes -o wide

What to look for:

• NAME — The node name (usually matches the VMSS instance name).
• STATUS — Should be Ready.
• ROLES — In AKS, nodes typically show <none> (labels differentiate system vs user pools).
• VERSION — Kubernetes version running on the node.
• INTERNAL-IP — The node’s IP address in the Azure virtual network.
• OS-IMAGE — Should show Azure Linux or Ubuntu depending on configuration.
• CONTAINER-RUNTIME — containerd://x.x.x.

# Describe a specific node (replace <node-name> with an actual node name from the previous output)
kubectl describe node <node-name>

Sections to examine in the describe output:

Task 3: Explore System Components

# List all pods in the kube-system namespace
kubectl get pods -n kube-system

Key system pods you should see:

# Also check the app-routing-system namespace (if app-routing is enabled)
kubectl get pods -n app-routing-system

Task 4: Check API Server URL

kubectl cluster-info

Note the API server URL. This is the endpoint your kubectl communicates with. In AKS, it is a fully qualified domain name (FQDN) managed by Microsoft.

Task 5: List Available API Resources

# List all resource types the cluster supports
kubectl api-resources

This shows every resource type you can create in the cluster. Notice columns:

• NAME — Resource name (e.g., pods, services, deployments).
• SHORTNAMES — Abbreviations you can use with kubectl (e.g., po, svc, deploy).
• APIVERSION — The API group and version (e.g., apps/v1).
• NAMESPACED — Whether the resource is scoped to a namespace (true) or cluster-wide (false).

# Filter to see only namespaced resources
kubectl api-resources --namespaced=true

# Filter to see only cluster-scoped resources
kubectl api-resources --namespaced=false

AKS Portal Tour

Navigate to the Azure Portal and find the AKS cluster resource. Explore the following blades on your own:

1. Overview — Check the Kubernetes version, region, and resource group. Notice the secondary resource group (MC_*) — click into it to see the actual infrastructure (VMs, disks, NICs, load balancers).
2. Node Pools blade — View system and user node pools, their VM sizes, node counts, and Kubernetes version. Try to identify which pool is the system pool and which is the user pool.
3. Networking blade — Check the network plugin (Azure CNI), network policy engine (Cilium), DNS prefix, and load balancer configuration. Compare what you see here with the kubectl output from earlier tasks.
4. Kubernetes resources — The portal allows basic resource viewing (Workloads, Services, Storage) directly. Browse to Workloads and find the system pods you saw earlier with kubectl get pods -n kube-system.

Tip: Compare the information visible in the portal with what you discovered using kubectl. The portal provides a higher-level view, while kubectl gives you more detail and flexibility.

Common Problems

Best Practices

• Always set your default namespace to avoid accidentally creating resources in default:

  kubectl config set-context --current --namespace=student-XX
  

• Use -o wide for additional details in get commands.
• Use kubectl describe to investigate resource details and events.
• Never modify resources in kube-system unless you know exactly what you are doing.
• In production, always enable RBAC (--disable-rbac is only appropriate for training environments).

Summary

You have connected to the AKS cluster, explored its nodes and system components, and learned how to navigate the cluster using kubectl. The cluster uses Azure CNI with overlay networking, Cilium as the dataplane, and the app-routing add-on for Ingress. Your working namespace for all subsequent exercises is student-XX.

Proceed to Exercise 02 to learn about Kubernetes Namespaces.