Azure Kubernetes Service Architecture

Lesson: Azure Kubernetes Service (AKS) Architecture

1. Introduction: What is AKS and Why Use It?

Azure Kubernetes Service (AKS) is a managed container orchestration service provided by Microsoft Azure. It simplifies the deployment, management, and operations of Kubernetes—the industry-standard open-source system for automating the deployment, scaling, and management of containerized applications.

Why use AKS?

• Reduced Operational Overhead: Azure manages the Kubernetes control plane (the "brain" of the cluster), including health monitoring, patching, and upgrades, so you can focus on your application code.
• Scalability: AKS integrates seamlessly with Azure features like the Horizontal Pod Autoscaler (HPA) and the Cluster Autoscaler, allowing your infrastructure to grow or shrink based on real-time demand.
• Hybrid Ecosystem: Through Azure Arc, AKS can extend your Kubernetes environment to on-premises data centers or other cloud providers, offering a consistent management experience.
• Security & Compliance: AKS integrates with Microsoft Entra ID (formerly Azure AD) for identity management and Azure Policy for governance.

2. AKS Architecture Deep Dive

An AKS cluster is divided into two primary components: the Control Plane and the Node Pools.

The Control Plane (Managed by Azure)

When you create an AKS cluster, Azure automatically provisions and manages the control plane. This includes:

• API Server: The entry point for all Kubernetes management commands (via kubectl).
• etcd: The key-value store that keeps the state of your entire cluster configuration.
• Scheduler: Determines which nodes should host your pods.
• Controller Manager: Ensures the actual state of the cluster matches the desired state.

The Node Pools (Managed by You)

These are the virtual machines (nodes) that run your application containers.

• System Node Pool: Intended to run critical system services (like CoreDNS or Metrics Server).
• User Node Pool: Dedicated to running your application workloads.
• Virtual Kubelet: Allows you to "burst" into Azure Container Instances (ACI) when your physical nodes reach capacity, without managing extra VMs.

Practical Example: The Networking Model

AKS supports two primary networking plugins:

1. Kubenet: Uses a basic virtual network. Pods get IP addresses from a separate internal network, and traffic is NATed.
2. Azure CNI (Container Networking Interface): Every pod gets an IP address from your primary Azure Virtual Network. This is the preferred choice for enterprise environments requiring high performance and granular security policies.

3. Practical Implementation: Creating an AKS Cluster

To deploy an AKS cluster, you can use the Azure CLI. Below is a foundational script to provision a cluster with the best-practice CNI networking configuration.

# 1. Create a Resource Group
az group create --name myAKSResourceGroup --location eastus

# 2. Create a Virtual Network for Azure CNI
az network vnet create \
    --resource-group myAKSResourceGroup \
    --name myVnet \
    --address-prefixes 10.0.0.0/8 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 10.1.0.0/24

# 3. Get the Subnet ID
SUBNET_ID=$(az network vnet subnet show --resource-group myAKSResourceGroup --vnet-name myVnet --name myAKSSubnet --query id -o tsv)

# 4. Create the AKS Cluster
az aks create \
    --resource-group myAKSResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin azure \
    --vnet-subnet-id $SUBNET_ID \
    --generate-ssh-keys

Once deployed, you connect your local machine to the cluster using: az aks get-credentials --resource-group myAKSResourceGroup --name myAKSCluster

4. Best Practices and Common Pitfalls

Best Practices

• Use Multiple Node Pools: Separate your system services from your application workloads. This prevents a misbehaving application from crashing critical cluster components.
• Enable Cluster Autoscaler: Always enable the autoscaler. It ensures your cluster adjusts to traffic spikes without manual intervention.
• Implement Pod Disruption Budgets (PDBs): PDBs ensure that a minimum number of pods remain available during voluntary disruptions (like node upgrades).
• Use Azure Container Registry (ACR): Keep your images in ACR and use Managed Identities to allow AKS to pull images securely without storing static passwords.

Common Pitfalls

• Ignoring Resource Limits: Failing to define requests and limits in your Kubernetes manifests can lead to "noisy neighbor" issues where one container consumes all node memory, crashing others.
• Over-reliance on default Namespace: Always organize your applications into specific Namespaces. This allows for better RBAC (Role-Based Access Control) and resource quota management.
• Static IP Exhaustion: If using Azure CNI, ensure your VNet subnet is large enough. Every pod receives an IP address from the subnet; a small subnet will lead to deployment failures.

Important: Always upgrade your AKS cluster regularly. Kubernetes versions have a short support lifecycle. Running an outdated cluster exposes you to security vulnerabilities and potential breaking changes in the API.

5. Key Takeaways

1. Managed Control Plane: AKS offloads the complexity of the Kubernetes control plane to Azure, allowing you to focus on application deployment rather than infrastructure maintenance.
2. Networking Matters: Choose your networking model early. Azure CNI is recommended for production, but it requires careful IP address planning.
3. Security Integration: Leverage Microsoft Entra ID for RBAC and Managed Identities for service-to-service authentication to eliminate the need for hardcoded credentials.
4. Operational Maturity: Use tools like the Cluster Autoscaler, PDBs, and separate node pools to ensure your production environment is resilient and highly available.
5. Governance: Use Azure Policy for Kubernetes to enforce compliance, such as requiring all containers to have resource limits or disallowing privileged containers.