Azure Kubernetes Service Basics

Azure Kubernetes Service (AKS) Basics

Introduction: Why Orchestration Matters

In the modern landscape of software development, moving from a single monolithic application to a collection of distributed microservices is a standard practice. While this shift provides developers with the flexibility to update individual components without redeploying the entire system, it introduces a significant operational burden. Managing dozens or hundreds of individual containers across multiple servers requires a way to automate deployment, scaling, and networking. This is where container orchestration comes into play.

Azure Kubernetes Service (AKS) is a managed container orchestration platform provided by Microsoft Azure. It simplifies the process of running Kubernetes—the industry-standard open-source system for automating deployment, scaling, and management of containerized applications—by offloading the complexity of maintaining the control plane to the cloud provider. Instead of spending your time patching the Kubernetes master nodes, monitoring API server health, or configuring etcd backups, you focus on your code and your container images. Understanding AKS is essential for any cloud engineer, as it is the foundation upon which most modern enterprise-grade applications are built.

Understanding the Kubernetes Architecture

To use AKS effectively, you must first understand the fundamental components of Kubernetes. Kubernetes operates on a cluster model, which consists of a control plane and one or more worker nodes. The control plane acts as the "brain" of the cluster, making decisions about scheduling, responding to cluster events, and maintaining the desired state of the application. In AKS, Microsoft manages this control plane entirely, providing you with a highly available endpoint to interact with via the kubectl command-line tool.

The worker nodes are the actual virtual machines (VMs) where your application containers run. These nodes are grouped into "node pools." A node pool is essentially a collection of VMs with the same configuration, such as the same CPU and memory specifications. You can have multiple node pools in a single cluster, which is useful if you have different workloads with varying resource requirements—for example, one pool using high-memory machines for a database and another using GPU-enabled machines for machine learning tasks.

Callout: Managed vs. Unmanaged Kubernetes A common point of confusion is the difference between AKS and "Kubernetes on VMs." In an unmanaged environment, you are responsible for the entire lifecycle of the master nodes, including OS updates, security patching, and cluster upgrades. In AKS, the control plane is managed for you. This means you do not have direct access to the master node operating system, but in exchange, you gain automated upgrades, managed security, and a guarantee of availability for the API server.

Key Concepts in AKS

Before deploying your first cluster, you need to familiarize yourself with the objects that define how your application runs.

• Pods: The smallest deployable unit in Kubernetes. A pod represents a single instance of a running process in your cluster and can contain one or more containers that share storage and network resources.
• Deployments: A way to define the desired state for your pods. You describe the number of replicas, the container image to use, and update strategies. If a pod crashes, the deployment controller automatically replaces it to maintain the desired count.
• Services: Since pods are ephemeral (they can die and be replaced by new ones with different IP addresses), you need a stable way to expose your application. A Service provides a single, stable IP address and DNS name to access a set of pods.
• Namespaces: A mechanism to isolate resources within a single cluster. This is useful for multi-tenant environments where you want to separate development, testing, and production workloads within the same physical cluster.

Setting Up Your First AKS Cluster

Getting started with AKS requires the Azure CLI (az). You should have this installed on your local machine before proceeding. The process involves creating a resource group, creating the cluster itself, and then connecting your local environment to the cluster.

Step-by-Step Cluster Creation

1. Create a Resource Group: All your Azure resources should live in a resource group to keep your environment organized and make cleanup easier. az group create --name myAKSResourceGroup --location eastus

2. Create the Cluster: This command provisions the managed control plane and an initial node pool. az aks create --resource-group myAKSResourceGroup --name myAKSCluster --node-count 2 --enable-addons monitoring --generate-ssh-keys

3. Connect to the Cluster: To interact with the cluster, you need to download the credentials. This updates your local ~/.kube/config file. az aks get-credentials --resource-group myAKSResourceGroup --name myAKSCluster

4. Verify the Connection: Run the following command to ensure your local machine can talk to the cluster. kubectl get nodes

If everything is configured correctly, you will see a list of the nodes currently running in your cluster.

Note: The --enable-addons monitoring flag is highly recommended for production clusters. It enables Container Insights, which provides logs and metrics about your pods and nodes directly in the Azure Portal, saving you from having to set up third-party logging solutions immediately.

Working with Deployments and Services

Once your cluster is active, you need to deploy an application. Kubernetes uses YAML files to define the desired state. Let’s look at a simple deployment for an Nginx web server.

The Deployment YAML (nginx-deployment.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

To apply this to your cluster, run: kubectl apply -f nginx-deployment.yaml

This command instructs Kubernetes to ensure that two pods running the Nginx image are always available. If you delete one of the pods manually, the deployment controller will notice the discrepancy and spin up a new one immediately.

Exposing the Deployment

The deployment above creates pods, but they are only accessible from within the cluster. To make your application reachable from the internet, you need a Service.

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

When you apply this file, Azure will automatically provision an External Load Balancer and assign it a public IP address. You can see the status of this by running kubectl get service nginx-service. Once the EXTERNAL-IP field is populated, you can navigate to that IP in your browser to see your Nginx landing page.

Configuration and Best Practices

As you move beyond simple deployments, you will encounter scenarios where you need to manage sensitive data, resource constraints, and scaling policies.

Managing Secrets and ConfigMaps

Never hardcode configuration values or sensitive credentials inside your container images. Use Kubernetes ConfigMaps for non-sensitive data (like environment variables or configuration files) and Secrets for sensitive data (like database connection strings or API keys).

Resource Requests and Limits

One of the most common mistakes beginners make is failing to define resource requests and limits. A "request" tells the Kubernetes scheduler how much CPU or memory the pod needs to function, while a "limit" sets a hard cap on how much it can consume. If you don't set these, a "noisy neighbor" container could consume all the resources on a node, causing other containers to crash.

resources:
  requests:
    memory: "64Mi"
    cpu: "250m"
  limits:
    memory: "128Mi"
    cpu: "500m"

Horizontal Pod Autoscaler (HPA)

Manually scaling your pods is inefficient. The Horizontal Pod Autoscaler automatically scales the number of pods in your deployment based on observed CPU utilization or other custom metrics. This ensures your application remains responsive during traffic spikes without requiring manual intervention.

Callout: The Importance of Probes Kubernetes provides Liveness and Readiness probes to monitor the health of your application. A Liveness probe tells Kubernetes if the container is still running or if it should be restarted. A Readiness probe tells Kubernetes when the application is actually ready to accept traffic. Without these, your service might route traffic to a pod that is still booting up, leading to "503 Service Unavailable" errors for your users.

Comparison Table: Service Types

Common Pitfalls and How to Avoid Them

1. Over-provisioning Resources

It is tempting to give every pod as much RAM and CPU as possible to prevent crashes. However, this leads to underutilized clusters and wasted money. Always start with modest resource requests and use the Vertical Pod Autoscaler or monitoring tools to observe actual usage before tuning the values.

2. Ignoring Cluster Upgrades

AKS clusters need to be upgraded regularly to receive security patches and new features. If you ignore these, your cluster will eventually fall out of support. Use the Azure Portal or CLI to schedule maintenance windows, and always test your application in a staging cluster before performing a major version upgrade on production.

3. Misconfiguring Networking

Networking in Kubernetes can be complex. If you are using Azure CNI (Container Networking Interface), each pod gets its own IP address from your virtual network. This is great for performance but can quickly exhaust your IP address space if your subnets are too small. Always plan your IP address strategy before creating the cluster.

4. Running as Root

Security best practice dictates that you should never run your containers as the root user. If a container is compromised, the attacker would have root access to the container's filesystem. Always define a non-privileged user in your Dockerfile and use a SecurityContext in your Kubernetes manifest to enforce this.

Advanced Concepts: Ingress Controllers

While the LoadBalancer service type is excellent for simple setups, it becomes expensive and difficult to manage when you have dozens of microservices. Each LoadBalancer service results in a new public IP address and a new Azure Load Balancer resource.

An Ingress Controller (like Nginx Ingress or Azure Application Gateway Ingress Controller) acts as a single entry point for your cluster. It handles SSL termination, URL path-based routing (e.g., example.com/api vs example.com/web), and host-based routing. By using an Ingress, you can expose multiple services behind a single public IP address, which is significantly more cost-effective and easier to secure with a single SSL certificate.

Monitoring and Logging

In a distributed system, debugging a crash is impossible without logs. AKS integrates natively with Azure Monitor and Log Analytics. When you enable the Container Insights add-on, you get a pre-configured dashboard that shows:

• Node health: CPU and memory pressure across your cluster.
• Pod logs: A unified view of stdout/stderr logs from all your containers.
• Deployment status: Real-time visibility into rolling updates and deployment failures.

Always configure your applications to log to standard output (stdout). Kubernetes captures these logs automatically, and the log aggregation service will ship them to your configured workspace. Avoid writing logs to files inside the container, as those files will be lost when the pod is deleted.

Security Considerations for AKS

Security in Kubernetes is a multi-layered responsibility. You must secure the cluster itself, the container images, and the network communication between services.

1. Role-Based Access Control (RBAC): Use Azure Active Directory (Azure AD) integration with AKS. This allows you to manage cluster access using your existing corporate identities rather than managing local Kubernetes users.
2. Network Policies: By default, all pods in a Kubernetes cluster can communicate with all other pods. This is a security risk. Use Network Policies to enforce a "zero-trust" model, where only authorized services can talk to each other.
3. Image Scanning: Use Azure Container Registry (ACR) to store your images and enable vulnerability scanning. This will notify you if your base images contain known security flaws.
4. Private Clusters: For high-security environments, create a "private AKS cluster." In this configuration, the API server is not exposed to the public internet; it is only reachable from within your private virtual network or via a VPN/ExpressRoute connection.

Troubleshooting Workflow

When something goes wrong in AKS, follow a structured troubleshooting process:

1. Check Pod Status: Run kubectl get pods. If a pod is in CrashLoopBackOff, it means the application is starting and then immediately failing.
2. Examine Logs: Run kubectl logs <pod-name> to see the application's output. This is usually the first place to find the cause of a crash.
3. Describe the Resource: If logs don't help, run kubectl describe pod <pod-name>. This will show you events related to the pod, such as "FailedScheduling" (due to lack of resources) or "PullImageError" (due to incorrect credentials).
4. Verify Networking: If your pod is running but you cannot connect to it, check your Service configuration. Ensure the selector labels in the Service match the labels defined in your Deployment.

Practical Example: Deploying a Multi-Tier Application

Imagine you are deploying a web application with a frontend and a backend API. You would create two separate deployments and two separate services.

• Frontend Deployment: Configured to talk to the backend service via the internal DNS name (e.g., http://backend-service).
• Backend Deployment: Configured to expose an API endpoint.
• Frontend Service: Exposed via an Ingress controller to the public.
• Backend Service: Exposed only as ClusterIP so it cannot be accessed directly from the internet.

This architecture ensures that your backend database or API is protected behind the frontend, reducing the attack surface. By using internal DNS, your frontend doesn't need to know the IP address of the backend pods, which is crucial because those IPs change whenever the pods restart.

Maintaining Your Cluster

The lifecycle of an AKS cluster includes regular maintenance. Microsoft releases new Kubernetes versions frequently. You should establish a regular cadence for upgrading your cluster nodes.

• Plan the upgrade: Use the Azure CLI to check for available upgrades: az aks get-upgrades --name myAKSCluster --resource-group myAKSResourceGroup.
• Perform a test upgrade: Always upgrade a dev/test cluster before upgrading production.
• Use Node Image Upgrades: Even if the Kubernetes version doesn't change, the underlying node OS images might need security patches. You can perform a node image upgrade to keep the underlying Linux/Windows nodes secure without changing the Kubernetes version.
• Monitor Quotas: Ensure your Azure subscription has sufficient quota for the number of VMs you plan to run. If you try to scale your cluster and hit a subscription limit, your deployment will fail.

Summary: Key Takeaways

1. Managed Control Plane: AKS simplifies Kubernetes management by handling the control plane, allowing you to focus on your applications.
2. Declarative Configuration: Use YAML files to define your desired state, and let Kubernetes handle the work of reconciling that state. Avoid making manual changes to the cluster via CLI whenever possible.
3. Resource Management: Always set requests and limits for your containers to ensure stable performance and cost efficiency.
4. Security First: Use RBAC, Network Policies, and private clusters to secure your environment. Never run containers as root.
5. Observability: Enable monitoring and logging from day one. You cannot troubleshoot what you cannot see.
6. Planning for Change: Remember that pods are ephemeral. Design your applications to be stateless and ensure they can handle being restarted or rescheduled at any time.
7. Regular Maintenance: Keep your cluster updated with the latest Kubernetes versions and node images to ensure security and compatibility.

FAQ

Q: Can I run Windows containers in AKS? A: Yes, AKS supports both Linux and Windows Server node pools. You can have a single cluster that runs both, though they must be in separate node pools.

Q: What happens if my cluster nodes run out of memory? A: Kubernetes will start evicting pods based on their priority. If you haven't set resource limits, it's hard for Kubernetes to know which pods to kill, which can result in the entire node becoming unresponsive. This is why resource requests and limits are critical.

Q: Is AKS expensive? A: The management of the AKS control plane is free. You only pay for the underlying virtual machines, storage, and networking resources that your cluster consumes.

Q: How do I handle persistent data? A: Use Persistent Volumes (PV) and Persistent Volume Claims (PVC). These map your container storage to Azure Disk or Azure Files, ensuring your data survives even if the pod is deleted or the node is replaced.

Q: Can I use my own CI/CD pipeline with AKS? A: Absolutely. AKS is designed to be integrated with tools like GitHub Actions, Azure DevOps, or Jenkins. Most pipelines simply use kubectl or helm to update the deployment manifests in the cluster during the release phase.

By following these principles and maintaining a disciplined approach to configuration and security, you will find AKS to be a powerful and reliable engine for your containerized workloads. The transition to orchestrated containers is a significant step, but with the managed capabilities of Azure, it becomes a manageable and highly scalable reality for any development team.