Project Overview
This lab demonstrates a complete, production-style workflow for standing up a containerized web application on Microsoft Azure using Azure Kubernetes Service (AKS). It covers cluster provisioning via the Azure CLI, secure node authentication, namespace-based workload isolation, application deployment, and public exposure through a cloud-native Load Balancer — the same pattern used to ship containerized services in real DevOps environments.
The objective was to take a project from a completely empty Azure subscription to a live, internet-reachable NGINX service, while documenting every command and its output for reproducibility and portfolio presentation.
Tools & Technologies
Microsoft Azure — Resource Groups, Azure Kubernetes Service (AKS), Load Balancer, Virtual Machine Scale Sets
Azure CLI (az) — cluster and resource provisioning
Kubernetes / kubectl — namespace, deployment, and service management
NGINX — containerized workload deployed to the cluster
VS Code + PowerShell — local development and terminal environment
SSH (ED25519) — secure node authentication
Architecture at a Glance
A resource group (kolakub-RG) hosts the AKS control plane, while Azure auto-generates a companion managed resource group (myNodeRG) containing the underlying VM Scale Set, virtual network, network security group, and Load Balancer that back the cluster's worker nodes. Inside the cluster, a dedicated frontend namespace isolates the NGINX deployment, which is exposed externally through a Kubernetes Service of type LoadBalancer.
Step-by-Step Walkthrough
STEP 1 Generate an SSH Key Pair for Node Authentication
he command produced a private key (aks-ssh) and a public key (aks-ssh.pub), which is later injected into the AKS cluster so nodes can be reached over SSH without password authentication.
Every AKS Linux node needs an SSH key for secure administrative access. Working inside the LAB-1 project folder in VS Code's PowerShell terminal, a dedicated .ssh directory was created, followed by an ED25519 key pair generated specifically for this cluster.
STEP 2 Create a Resource Group
Before any Azure resource can be provisioned, it needs a resource group to live in. The subscription was first checked for existing groups, then a new one — kolakub-RG — was created in the West US region.
The returned JSON confirms the resource group was created successfully and is ready to host the AKS cluster
STEP 3 Provision the AKS Cluster
With the resource group in place, the AKS cluster itself — MyAKSCluster — was provisioned using az aks create. The configuration defines a single-node systemp nodepool on Standard_D2s_v3 VMs, injects the previously generated SSH public key, uses the Azure CNI network plugin, and enables the cluster autoscaler (scaling between 1 and 2 nodes) so the workload can grow automatically under load.
Azure CLI streams back the complete cluster definition, confirming settings such as autoscaling, node pool profile, and orchestrator version once provisioning completes.
STEP 4 Verify the Cluster in the Azure Portal
Switching to the Azure Portal confirms the cluster was created successfully outside the CLI as well. Inside kolakub-RG, MyAKSCluster appears with resource type "Kubernetes service", deployed to the West US region.
STEP 5 Inspect the Auto-Generated Node Resource Group
AKS automatically creates a second, system-managed resource group (myNodeRG) to hold the infrastructure backing the cluster's nodes. Reviewing it surfaces the public IP address, the network security group, the virtual machine scale set running the actual worker node(s), the virtual network, the Load Balancer, and the managed identity used by the cluster.
This separation keeps user-managed resources (kolakub-RG) cleanly apart from Azure-managed cluster infrastructure (myNodeRG).
STEP 6 Create an Isolated Namespace
To keep the application workload logically separated from system components, a dedicated frontend namespace was created using kubectl, then verified against the cluster's full namespace list.
STEP 7 Deploy the NGINX Application
With the namespace ready, an NGINX deployment was rolled out into frontend. Checking the default namespace first confirms no resources exist there — the workload is correctly scoped — while querying across all namespaces and then filtering to frontend shows the deployment running with all 3 replicas ready and available.
STEP 8 Expose the Deployment with a LoadBalancer Service
To make the NGINX deployment reachable from outside the cluster, it was exposed as a Kubernetes Service of type LoadBalancer, mapping external port 80 over TCP to the pods.
STEP 9 Connect kubectl to the Cluster & Confirm Node Health
To manage the cluster from the local machine, its credentials were merged into the local kubeconfig with az aks get-credentials. A quick kubectl get node confirms the worker node is Ready and running Kubernetes v1.34.6.
STEP 10 Validate Public Access via the External IP
The final check confirms the service is live on the public internet. Querying the frontend namespace's services shows nginx-service of type LoadBalancer with an assigned EXTERNAL-IP, reachable on port 80 — proof the NGINX application is now publicly accessible.
Top comments (0)