DEV Community

Cover image for Kubernetes on AKS: From Zero to Production Workloads -Creating the AKS Cluster (Part 2/9)
Rahimah Sulayman
Rahimah Sulayman

Posted on

Kubernetes on AKS: From Zero to Production Workloads -Creating the AKS Cluster (Part 2/9)

#kubernetes #aks #cloud #linux

Introduction

Provisioning a Kubernetes cluster is the next step after preparing the development environment. In this part of the series, I moved from local tooling setup to creating an Azure Kubernetes Service (AKS) cluster, connecting kubectl to it, verifying the cluster, and preparing a dedicated namespace for workloads.

The objective was to establish a working Kubernetes environment on Azure that could support the deployments and experiments in the missions that follow.

What This Part Covers

  • Loading the lab configuration.
  • Creating an Azure resource group.
  • Provisioning an AKS cluster.
  • Retrieving cluster credentials and configuring kubectl.
  • Verifying the cluster and its system components.
  • Creating and selecting a Kubernetes namespace.

1. Load the Lab Configuration

I started from the project directory created in Part 1:

cd /mnt/c/Users/Admin/Desktop/labs/aks-kubernetes-lab
Enter fullscreen mode Exit fullscreen mode

Before provisioning any Azure resources, I loaded the environment variables defined in lab.env:

source lab.env
Enter fullscreen mode Exit fullscreen mode

The environment file provides the configuration used by the commands in this mission, including the resource group name, cluster name, Azure region, and node size.

Using variables instead of repeatedly hardcoding resource names makes the commands easier to maintain and reuse throughout the lab.

2. Check the Resource Group and Create It

Before creating the resource group, I checked whether it already existed:

az group show --name $RESOURCE_GROUP --query location --output tsv 2>/dev/null
Enter fullscreen mode Exit fullscreen mode

The command queries the resource group's location. Redirecting standard error to /dev/null suppresses error messages if the resource group does not exist.

I then created the resource group:

az group create --name $RESOURCE_GROUP --location $LOCATION --output table
Enter fullscreen mode Exit fullscreen mode

The command returned the following result:

Location    Name
----------  ----------
westeurope  rg-aks-lab
Enter fullscreen mode Exit fullscreen mode

azure cli

This confirmed that the resource group rg-aks-lab was available in westeurope.

An Azure resource group provides a logical container for related resources. In this lab, it serves as the main resource group for the AKS environment.

3. Provision the AKS Cluster

With the resource group created, I provisioned the AKS cluster using the Azure CLI:

az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --location $LOCATION \
  --tier free \
  --node-count 1 \
  --node-vm-size $NODE_SIZE \
  --generate-ssh-keys \
  --output table
Enter fullscreen mode Exit fullscreen mode

Here is what the main options do:

  • --resource-group specifies the Azure resource group that will contain the cluster.
  • --name sets the AKS cluster name.
  • --location specifies the Azure region.
  • --tier free selects the Free tier for AKS cluster management.
  • --node-count 1 configures one initial worker node.
  • --node-vm-size specifies the virtual machine size for the node.
  • --generate-ssh-keys generates SSH keys if required.
  • --output table presents the returned information in a table format.

The command displayed a notice that the aks-preview extension had altered its behavior. It also warned that the new node pool would enable SSH access and recommended using --ssh-access disabled to disable SSH access for better security.

The command subsequently returned cluster information, including the Kubernetes version, provisioning state, resource group, and cluster name.

The key result was:

ProvisioningState: Succeeded
ResourceGroup:     rg-aks-lab
Name:              aks-lab
Location:          westeurope
Enter fullscreen mode Exit fullscreen mode

The provisioning state of Succeeded confirmed that Azure had completed the cluster creation operation.

AKS creation

4. Connect kubectl to the AKS Cluster

Creating the cluster is only part of the process. I also needed to configure my local Kubernetes client to communicate with it.

I retrieved the cluster credentials with:

az aks get-credentials \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --overwrite-existing
Enter fullscreen mode Exit fullscreen mode

The command returned:

Merged "aks-lab" as current context in /home/rahimahisah/.kube/config
Enter fullscreen mode Exit fullscreen mode

This merged the AKS cluster credentials into the local kubeconfig file and selected the aks-lab context.

To confirm the active context, I ran:

kubectl config current-context
Enter fullscreen mode Exit fullscreen mode

The output was:

aks-lab
Enter fullscreen mode Exit fullscreen mode

This confirmed that kubectl was configured to use the AKS cluster context.

Kubernetes contexts allow a single kubeconfig file to hold connection details for multiple clusters. Checking the active context before running commands is a useful habit because it helps prevent accidentally targeting the wrong environment.

Retrieving AKS credentials and verifying the current Kubernetes context

5. Verify the Kubernetes Cluster

After connecting kubectl, I checked the cluster's node status:

kubectl get nodes -o wide
Enter fullscreen mode Exit fullscreen mode

The output showed:

NAME                                STATUS   ROLES    AGE     VERSION
aks-nodepool1-33590657-vmss000000   Ready    <none>   3m18s   v1.36.4
Enter fullscreen mode Exit fullscreen mode

The node was in the Ready state, indicating that Kubernetes considered it ready to accept workloads.

The wider output also included information about the node's internal IP address, operating system image, kernel version, and container runtime.

The node was running Ubuntu 24.04.5 LTS, and the Kubernetes version shown was v1.36.4.

Inspect the cluster components

Next, I checked the cluster information:

kubectl cluster-info
Enter fullscreen mode Exit fullscreen mode

The output confirmed that the Kubernetes control plane was running and displayed the endpoints for CoreDNS and the metrics server.

I then inspected the system pods in the kube-system namespace:

kubectl get pods --namespace kube-system
Enter fullscreen mode Exit fullscreen mode

The output showed system components in the Running state, including:

  • azure-cns
  • azure-ip-masq-agent
  • cloud-node-manager
  • coredns
  • coredns-autoscaler
  • csi-azuredisk-node
  • csi-azurefile-node
  • kube-proxy
  • metrics-server
  • konnectivity-agent

These components support the operation of the cluster. For example, CoreDNS provides cluster DNS services, the CSI node components support storage integration, and the metrics server provides resource metrics used by Kubernetes tools and autoscaling components.

Checking the node, cluster information, and system pods provided an initial verification that the cluster was accessible and its core components were running.

Screenshot 4: Node status, cluster information, and system pods.

Node status, cluster information, and system pods

6. Create a Dedicated Kubernetes Namespace

With the cluster verified, I created a namespace for the lab workloads:

kubectl create namespace k8s-lab
Enter fullscreen mode Exit fullscreen mode

Kubernetes confirmed the operation:

namespace/k8s-lab created
Enter fullscreen mode Exit fullscreen mode

I then configured the current context to use the new namespace by default:

kubectl config set-context --current --namespace=k8s-lab
Enter fullscreen mode Exit fullscreen mode

The output confirmed that the aks-lab context had been modified.

To verify the namespace configured in the current context, I ran:

kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Enter fullscreen mode Exit fullscreen mode

The result was:

k8s-lab
Enter fullscreen mode Exit fullscreen mode

This means that subsequent kubectl commands that do not explicitly specify a namespace will use k8s-lab by default.

Namespaces provide a way to organize Kubernetes resources within a cluster. Creating a dedicated namespace keeps the lab workloads separate from system components running in kube-system.

Namespace creation

7. What Learned

This mission connected the local tooling setup from Part 1 to a working Kubernetes environment hosted on Azure.

The key takeaways were:

  • Azure resource organization: Resource groups provide a logical boundary for related Azure resources.
  • Cluster provisioning: The Azure CLI can provision an AKS cluster using a repeatable set of configuration options.
  • Kubernetes authentication and context: Retrieving credentials allows kubectl to communicate with the selected cluster.
  • Cluster verification: Checking node readiness, cluster information, and system pods helps establish whether the environment is operational.
  • Namespace management: A dedicated namespace helps organize lab workloads and avoid mixing them with system resources.

One important habit I reinforced was verifying the active Kubernetes context before working with cluster resources. It is a small check that can help prevent mistakes when managing multiple environments.

Conclusion

The AKS cluster was provisioned successfully, the local Kubernetes client was connected to it, and the k8s-lab namespace was created and selected as the default namespace for the current context.

The environment is now ready for the next stage of the series, where I will begin working with Kubernetes resources and workloads.

In Part 3, the series will continue with the next mission in the lab, building on the cluster and namespace established here.

This article is part of the nine-part series, “Kubernetes on AKS: From Zero to Production Workloads.”

Top comments (1)

Collapse
 
rahimah_dev profile image
Rahimah Sulayman •

A Kubernetes cluster is more than just a collection of nodes, it’s the foundation for running resilient, scalable workloads. In this mission, I focused on getting the fundamentals right: provisioning AKS, configuring kubectl, verifying cluster health, and preparing a dedicated namespace. Every production-ready environment starts with a solid foundation, and this is where mine begins.