Streamlined Kubernetes Setup for Small Businesses: An Azure AKS Guide

Step 1: Initial Setup: Tools and Azure Login

Before deploying anything in Azure, ensure your local environment is correctly configured with the necessary tools and authenticated against your Azure subscription. This step covers installing `kubectl` (if not already present), connecting to Azure, and setting up default configurations to streamline subsequent commands.

# Install kubectl if not already installed
az aks install-cli

# Log in to Azure. This will open a browser window for authentication.
az login --output none

# Set your default Azure subscription (replace with your subscription ID or name)
# This is crucial for ensuring all subsequent commands operate within the correct context.
az account set --subscription 'Your-Azure-Subscription-Name-or-ID'

# Set default resource group and location for convenience (optional but recommended)
# This reduces verbosity in future commands. You can override these per command.
az configure --defaults group='SkyCoreAKSResourceGroup' location='eastus'

az aks install-cli: Installs or updates kubectl, the Kubernetes command-line tool, on your local machine.

az login: Authenticates your Azure CLI session, connecting it to your Azure account.

az account set --subscription: Specifies which Azure subscription to use for all subsequent CLI commands.

az configure --defaults group='SkyCoreAKSResourceGroup' location='eastus': Configures default values for the resource group and location, making future commands shorter.

Portal alternative: Log in to the Azure Portal at portal.azure.com. Verify your subscription in the top-right corner. You'd still need CLI for kubectl.

Expected result: You will be successfully logged in to Azure, `kubectl` will be installed, and your default subscription and potentially resource group/location will be configured for your CLI session.

Step 2: Create an Azure Resource Group

An Azure Resource Group acts as a logical container for your Azure resources. For a small business, creating a dedicated resource group for your AKS cluster and its related components (like virtual networks, load balancers, and storage accounts) helps with organization, cost management, and lifecycle management. All resources within this guide will reside in this group.

az group create --name 'SkyCoreAKSResourceGroup' --location 'eastus'

--name: Specifies the unique name for your new resource group.

--location: Defines the Azure region where the resource group metadata will be stored and where resources will be deployed by default.

Portal alternative: Navigate to 'Resource groups' > 'Create'. Fill in the subscription, resource group name, and region, then review and create.

Expected result: A JSON output confirming the successful creation of the resource group, including its name, location, and provisioning state.

Step 3: Configure a Virtual Network (Optional but Recommended)

While AKS can create its own virtual network (VNet) by default, creating a custom VNet and subnet offers greater control over network topology, enhances security, and simplifies integration with other Azure services. This is a best practice for small businesses planning for future growth or needing isolated environments.

# Define variables for VNet and Subnet names and addresses
$vnetName = 'SkyCoreAKSVNet'
$vnetAddressPrefix = '10.0.0.0/16'
$aksSubnetName = 'aks-subnet'
$aksSubnetAddressPrefix = '10.0.0.0/24'
$otherSubnetName = 'app-gateway-subnet' # Example for future use like Application Gateway
$otherSubnetAddressPrefix = '10.0.1.0/24'

# Create the Virtual Network
az network vnet create `
    --name $vnetName `
    --address-prefixes $vnetAddressPrefix `
    --output none

# Create a subnet specifically for AKS nodes
az network vnet subnet create `
    --vnet-name $vnetName `
    --name $aksSubnetName `
    --address-prefixes $aksSubnetAddressPrefix `
    --output none

# (Optional) Create another subnet for other services, e.g., Application Gateway or jumpbox
az network vnet subnet create `
    --vnet-name $vnetName `
    --name $otherSubnetName `
    --address-prefixes $otherSubnetAddressPrefix `
    --output none

# Retrieve the full resource ID of the AKS subnet for cluster deployment
$aksSubnetId = az network vnet subnet show `
    --vnet-name $vnetName `
    --name $aksSubnetName `
    --query id --output tsv

Write-Host "AKS Subnet ID: $aksSubnetId"

az network vnet create: Creates a new virtual network with a specified address space.

--address-prefixes: Defines the CIDR block for the VNet.

az network vnet subnet create: Creates a new subnet within the specified VNet.

--vnet-name: Links the subnet to its parent virtual network.

--address-prefixes: Defines the CIDR block for the subnet.

az network vnet subnet show --query id --output tsv: Retrieves the unique resource ID of the created subnet, essential for linking AKS to it.

Portal alternative: Go to 'Virtual networks' > 'Create'. Define the VNet and then navigate into it to add subnets from the 'Subnets' blade.

Expected result: The virtual network and its subnets are created. The `Write-Host` command will output the full resource ID of the AKS subnet, which you'll need in the next step.

Step 4: Deploy Azure Kubernetes Service (AKS) Cluster

This is the core step: provisioning your AKS cluster. For a small business, the goal is a balanced configuration that offers reliability and scalability without incurring excessive costs. We'll use Azure CNI for advanced networking, enable the cluster autoscaler for efficiency, and configure a basic service principal for authentication.

# Define cluster name and Kubernetes version
$aksClusterName = 'SkyCoreAKSDemoCluster'
$kubernetesVersion = '1.28.5' # Check Azure docs for the latest stable version

# Deploy the AKS cluster
az aks create `
    --name $aksClusterName `
    --kubernetes-version $kubernetesVersion `
    --node-count 2 ` # Start with 2 nodes for high availability and basic workload
    --node-vm-size Standard_DS2_v2 ` # General purpose VM size, good for small business
    --network-plugin azure ` # Use Azure CNI for advanced networking features
    --vnet-subnet-id $aksSubnetId ` # Link to our custom VNet subnet
    --enable-managed-identity ` # Recommended for secure AKS cluster operations
    --enable-cluster-autoscaler ` # Automate node scaling for cost efficiency
    --min-count 1 ` # Minimum nodes when autoscaler is active
    --max-count 3 ` # Maximum nodes when autoscaler is active
    --load-balancer-sku standard ` # Standard SKU for advanced features like zone redundancy
    --generate-ssh-keys ` # Generate SSH keys for node access (optional but good for troubleshooting)
    --tags 'Project=SkyCoreAKS' 'Environment=Dev' # Tag resources for cost management
    --output none

--name: The unique name for your AKS cluster.

--kubernetes-version: Specifies the desired Kubernetes version. Always check Azure documentation for the latest stable version.

--node-count: Initial number of nodes in the default node pool. Two nodes provide basic high availability.

--node-vm-size: The size of the virtual machines for your worker nodes. `Standard_DS2_v2` is a common choice for balanced workloads.

--network-plugin azure: Configures the cluster to use Azure CNI, assigning each pod its own IP address from the VNet subnet. This is recommended for production and advanced networking.

--vnet-subnet-id: The resource ID of the subnet dedicated to your AKS cluster nodes.

--enable-managed-identity: Enables managed identities for AKS, a more secure alternative to service principals for Azure resource interaction.

--enable-cluster-autoscaler: Automatically scales the number of nodes based on resource demand, helping manage costs.

--min-count, --max-count: Define the lower and upper limits for the cluster autoscaler.

--load-balancer-sku standard: Uses the Standard Load Balancer, offering enhanced features over Basic SKU.

--generate-ssh-keys: Creates a new SSH key pair and stores it in Azure for accessing cluster nodes.

--tags: Apply Azure tags for better resource management and cost tracking.

Portal alternative: Go to 'Kubernetes services' > 'Create'. Fill in all necessary details across 'Basics', 'Node pools', 'Networking' (select 'Azure CNI' and link your custom VNet/subnet), 'Integrations', 'Advanced', and 'Tags' tabs. Ensure autoscaling is enabled under 'Node pools'.

Expected result: This command can take 10-15 minutes to complete. A successful deployment will show a JSON output detailing the cluster's properties, or if `--output none` is used, a silent success. The cluster will be provisioned in your resource group.

Step 5: Connect to Your AKS Cluster

Once your AKS cluster is deployed, you need to configure your local `kubectl` client to securely connect and interact with it. This involves downloading the cluster's credentials and merging them into your `kubectl` configuration file.

# Get credentials for your AKS cluster
az aks get-credentials `
    --resource-group 'SkyCoreAKSResourceGroup' `
    --name 'SkyCoreAKSDemoCluster' `
    --overwrite-existing # Overwrite if credentials for this cluster already exist

# Verify connection by listing nodes
kubectl get nodes

az aks get-credentials: Downloads the credentials and updates your local `kubectl` configuration file (~/.kube/config).

--resource-group: Specifies the resource group where your AKS cluster resides.

--name: The name of your AKS cluster.

--overwrite-existing: Ensures that if you've connected to this cluster before, the credentials are refreshed, preventing potential issues with outdated access tokens.

kubectl get nodes: A `kubectl` command to list all worker nodes in your Kubernetes cluster, verifying successful connection.

Portal alternative: Navigate to your AKS cluster in the Azure Portal, go to 'Connect' blade, and copy the provided az aks get-credentials command.

Expected result: The `kubectl` configuration file is updated. `kubectl get nodes` will output a list of your cluster's nodes, showing their status (e.g., 'Ready'), roles, age, and version.

Step 6: Deploy a Sample Application

With your AKS cluster ready and your `kubectl` configured, let's deploy a simple NGINX web server. This step demonstrates basic Kubernetes deployment and service exposure, confirming your cluster is fully operational and capable of hosting applications.

# Deploy an NGINX application
kubectl create deployment nginx --image=nginx

# Expose the NGINX deployment as a LoadBalancer service
# This will provision an Azure Load Balancer and assign a public IP address.
kubectl expose deployment nginx `
    --port=80 `
    --type=LoadBalancer

# Check the status of the service and get its external IP
Write-Host "Waiting for NGINX service external IP..."
$ip = ''
while (-not $ip) {
    Start-Sleep -Seconds 5
    $ip = (kubectl get service nginx -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    Write-Host "Current IP: $ip (Waiting for external IP...)"
}
Write-Host "NGINX External IP: $ip"

# Access the application via the browser (replace with the actual IP)
# Example: Start-Process "http://$ip" # For Windows
# Example: open "http://$ip" # For macOS
# Example: xdg-open "http://$ip" # For Linux

kubectl create deployment nginx --image=nginx: Creates a Kubernetes Deployment named 'nginx' that runs the official NGINX Docker image.

kubectl expose deployment nginx --port=80 --type=LoadBalancer: Creates a Kubernetes Service that exposes the NGINX deployment on port 80. `LoadBalancer` type provisions an Azure Load Balancer to provide a public IP address.

kubectl get service nginx -o jsonpath='{.status.loadBalancer.ingress[0].ip}': Queries the 'nginx' service and extracts its external IP address once the Azure Load Balancer provisions it.

Portal alternative: While you can't deploy apps directly in the portal, you can monitor your cluster's workloads and services under your AKS cluster's 'Workloads' and 'Services and ingresses' blades.

Expected result: An NGINX deployment will be created. A few minutes after exposing the service, `kubectl get service nginx` will show an `EXTERNAL-IP`. Browsing to this IP in a web browser should display the default "Welcome to Nginx!" page.

Step 7: Monitor and Scale Your AKS Cluster

Effective monitoring is crucial for small businesses to ensure application health and optimize costs. AKS integrates well with Azure Monitor. Scaling, both at the application and infrastructure level, is vital for handling varying workloads efficiently.

# Enable Azure Monitor for containers (if not enabled during cluster creation)
# It's recommended to enable this for production clusters.
az aks enable-addons `
    --addons monitoring `
    --name 'SkyCoreAKSDemoCluster' `
    --resource-group 'SkyCoreAKSResourceGroup'

# View basic node and pod metrics (requires Metrics Server, usually pre-installed)
kubectl top nodes
kubectl top pods -n default # See pods in the 'default' namespace

# Manually scale the NGINX application to 3 replicas
kubectl scale deployment/nginx --replicas=3

# Verify the scaled deployment
kubectl get pods -l app=nginx

# Test cluster autoscaler (e.g., by creating a high-demand workload or checking logs)
# You can see autoscaler logs in Azure Monitor for containers or by checking the events:
# kubectl get events --field-selector 'involvedObject.name=cluster-autoscaler' -n kube-system

az aks enable-addons --addons monitoring: Activates the Azure Monitor for containers add-on for your AKS cluster, providing deep visibility into cluster health and performance.

kubectl top nodes: Displays CPU and memory usage for your cluster nodes.

kubectl top pods: Displays CPU and memory usage for individual pods.

kubectl scale deployment/nginx --replicas=3: Increases the number of running instances (pods) of your NGINX application to three.

kubectl get pods -l app=nginx: Lists pods matching the label `app=nginx` to verify the scaling.

Portal alternative: For monitoring, navigate to your AKS cluster, then go to the 'Insights' blade. Here you'll find detailed dashboards for node, controller, and container performance. For scaling, you can manually adjust node counts under 'Node pools' or review autoscaler status.

Expected result: Azure Monitor for containers will be enabled for your cluster. `kubectl top` commands will show resource usage. Your NGINX application will scale to three pods, distributed across your cluster nodes.

Step 8: Cost Management and Cluster Teardown

Understanding and managing costs is paramount for small businesses. Azure provides tools for cost analysis. When your AKS cluster is no longer needed, it's crucial to deprovision all associated resources to avoid unnecessary charges. The simplest and most recommended way is to delete the entire resource group.

# View estimated costs in Azure Cost Management
# Portal: Navigate to "Cost Management + Billing" -> "Cost management" -> "Cost analysis"
# Filter by your resource group 'SkyCoreAKSResourceGroup'

# --- CLEANUP (ONLY RUN WHEN YOU ARE DONE AND WANT TO DELETE ALL RESOURCES) ---

# Delete the entire resource group and all its contents
# This is irreversible. Confirm carefully!
az group delete `
    --name 'SkyCoreAKSResourceGroup' `
    --no-wait ` # Don't wait for the deletion to complete (it can take time)
    --yes         # Confirm the deletion without a prompt

az group delete: Deletes an entire resource group and all resources contained within it.

--name: Specifies the name of the resource group to be deleted.

--no-wait: Allows the command to return immediately without waiting for the deletion operation to finish.

--yes: Suppresses the confirmation prompt, proceeding directly with the deletion.

Portal alternative: Navigate to 'Resource groups', select 'SkyCoreAKSResourceGroup', then click 'Delete resource group'. You will need to type the resource group name to confirm.

Expected result: The deletion process for the `SkyCoreAKSResourceGroup` will initiate. All your AKS cluster resources, VNet, Load Balancers, and any other components created in that resource group will be permanently removed from your Azure subscription. Verify in the Azure Portal that the resource group is gone after some time.