Deploying and Operating Azure Kubernetes Service (AKS) – A Practical Guide – Part 1 – Fundamentals and Core Concepts

With the increasing adoption of containerized applications, Kubernetes has established itself as the standard platform for container orchestration. However, its architecture and terminology can be complex, especially for those new to the ecosystem.

In this multi-part series, I’ll walk through the fundamentals of Kubernetes using Azure Kubernetes Service (AKS), focusing on a practical, hands-on approach rather than theory alone. The goal is to build a solid foundation that allows you to confidently deploy, operate, and troubleshoot workloads in Azure.

Google Cloud is the birthplace of Kubernetes—originally developed at Google and released as open source in 2014. Kubernetes builds on 15 years of running Google’s containerized workloads and the valuable contributions from the open source community. 

Source: https://cloud.google.com/learn/what-is-kubernetes

In this first part, we start with the core concepts and architecture of Kubernetes, forming the basis for everything that follows in the next parts of this series.

In Part 2 we take a closer look at how Kubernetes is implemented in Microsoft Azure using Azure Kubernetes Service (AKS).

In Part 3 we will walk through the deployment of an AKS cluster using both the Azure Portal and the Azure CLI. The focus is on a practical, reproducible setup that can be used as a foundation for further exploration in the next parts of this series.

What is Kubernetes?

Kubernetes is an open-source platform designed to automate the deployment, scaling, and operation of containerized applications. Instead of manually managing individual containers, Kubernetes provides a centralized system to orchestrate and manage them across a cluster of machines.

At its core, Kubernetes ensures that your applications run reliably and as intended. You define the desired state, such as how many instances of an application should be running, and Kubernetes continuously works to maintain that state. If a container fails, Kubernetes automatically replaces it. If demand increases, it can scale the application accordingly.

Kubernetes operates on top of a cluster, which consists of multiple machines (nodes) that work together. These nodes run containerized workloads, typically packaged using technologies like Docker or containerd.

In Azure Kubernetes Service (AKS), the default (and today effectively only supported) container runtime is: 👉 containerd

One of the key advantages of Kubernetes is abstraction. Instead of dealing with individual servers or containers, you interact with higher-level objects such as deployments and services. This allows you to focus on the application itself rather than the underlying infrastructure.

In the context of Azure, Kubernetes is provided as a managed service called Azure Kubernetes Service (AKS). AKS abstracts much of the operational complexity, such as managing the control plane, allowing you to focus on deploying and operating your workloads.

Kubernetes Architecture Overview

Kubernetes follows a distributed architecture based on a cluster of machines, designed to provide high availability, scalability, and fault tolerance for containerized workloads.

A Kubernetes cluster consists of two main components: the control plane and the worker nodes.

The control plane is responsible for managing the overall state of the cluster. It makes decisions about scheduling workloads, maintaining the desired state, and handling cluster-wide operations. Key components of the control plane include the API server, scheduler, and controller manager.

The worker nodes are the machines where your actual applications run. Each node hosts one or more containers, grouped into Kubernetes objects called pods. The nodes communicate with the control plane to receive instructions and report their current status.

At the center of all interactions is the Kubernetes API server. Every operation, whether deploying an application, scaling it, or retrieving its status, is performed through this API. Tools like kubectl or the Azure CLI interact with the cluster by sending requests to the API server.

Kubernetes continuously monitors the state of the cluster and compares it to the desired state defined by the user. If there is any deviation, or example, a failed container or a missing pod, the control plane automatically takes corrective action to bring the system back into the desired state.

In Azure Kubernetes Service (AKS), the control plane is fully managed by Azure. This means you don’t need to deploy, maintain, or patch control plane components, allowing you to focus entirely on managing your workloads running on the worker nodes.

Control Plane vs Worker Nodes

As introduced in the previous section, a Kubernetes cluster is divided into two main parts: the control plane and the worker nodes. Understanding the responsibilities of each is essential for working effectively with Kubernetes.

The control plane acts as the brain of the cluster. It is responsible for managing and maintaining the desired state of the system. When you deploy an application, scale it, or update its configuration, these actions are processed by the control plane.

Key components of the control plane include:

• API Server – The central entry point for all interactions with the cluster. All commands from tools like kubectl or the Azure CLI are sent to the API server.
• Scheduler – Determines on which worker node a new pod should run, based on available resources and constraints.
• Controller Manager – Ensures that the desired state is maintained, for example by restarting failed pods or adjusting the number of running instances.

The worker nodes, on the other hand, are responsible for running the actual workloads. This is where your containerized applications are executed.

Each worker node typically includes:

• Kubelet – An agent that communicates with the control plane and ensures that containers are running as expected.
• Container Runtime – The software responsible for running containers (for example containerd).
• Kube-proxy – Handles networking and ensures that traffic is correctly routed to the appropriate pods.

The interaction between these components is continuous. The control plane defines what should happen, and the worker nodes report back their current state. If a node fails or a pod crashes, the control plane detects the deviation and schedules a replacement on another available node.

In Azure Kubernetes Service (AKS), the control plane is fully managed by Azure, meaning you do not have direct access to these components. However, understanding their roles is still crucial, as it helps when troubleshooting, designing architectures, and optimizing workloads.

Pods – The Smallest Deployable Unit in Kubernetes

In Kubernetes, the smallest and most fundamental unit is called a pod. Instead of deploying individual containers directly, Kubernetes always works with pods.

A pod represents a single instance of a running application and can contain one or more containers. In most cases, a pod runs a single container, but multiple tightly coupled containers can be grouped together within the same pod.

All containers within a pod share the same network and storage context. This means:

• they share the same IP address
• they can communicate with each other via localhost
• they can share storage volumes

This design makes pods ideal for running closely related processes, such as an application container together with a sidecar container for logging or monitoring.

Pods are ephemeral by design. They are not meant to be manually managed or long-lived. If a pod fails, Kubernetes replaces it automatically. Instead of managing pods directly, you typically use higher-level objects like deployments, which ensure that the desired number of pod instances is always running.

When a pod is created, the Kubernetes scheduler assigns it to a worker node. The kubelet on that node then ensures that the containers within the pod are started and running as expected.

Deployments

While pods are the smallest deployable unit in Kubernetes, they are typically not managed directly. Instead, Kubernetes uses higher-level objects called deployments to manage pods in a scalable and reliable way.

A deployment defines the desired state of an application, such as:

• how many pod replicas should be running
• which container image to use
• how updates should be performed

Once a deployment is created, Kubernetes automatically ensures that the defined number of pod instances is running at all times. If a pod fails or is deleted, the deployment controller replaces it automatically.

Deployments also enable scaling. You can easily increase or decrease the number of pod replicas depending on demand, either manually or automatically using autoscaling mechanisms.

Another key feature of deployments is rolling updates. When you update an application, for example, by deploying a new container image, Kubernetes gradually replaces old pods with new ones. This ensures that the application remains available during the update process, minimizing downtime.

In addition, deployments support rollbacks. If a new version introduces issues, Kubernetes allows you to revert to a previous stable version quickly.

Under the hood, deployments manage ReplicaSets, which are responsible for maintaining the desired number of pod replicas. While ReplicaSets are rarely managed directly, they play a crucial role in ensuring application availability.

Services – Exposing Applications in Kubernetes

In Kubernetes, pods are dynamic and ephemeral. They can be created, deleted, or replaced at any time, and their IP addresses can change accordingly. This makes it difficult to reliably access applications running inside pods.

To solve this, Kubernetes introduces services.

A service provides a stable endpoint for accessing a set of pods. Instead of connecting directly to individual pods, clients communicate with the service, which then routes traffic to the appropriate backend pods.

Services use label selectors to identify which pods belong to them. This allows Kubernetes to automatically update the list of backend pods as they are created or removed, without requiring any manual changes.

There are different types of services, each designed for specific use cases:

• ClusterIP (default) – Exposes the service internally within the cluster. This is typically used for communication between applications.
• NodePort – Exposes the service on a static port on each worker node, making it accessible from outside the cluster.
• LoadBalancer – Integrates with cloud providers like Azure to provision an external load balancer, allowing external access to the application.

In Azure Kubernetes Service (AKS), a service of type LoadBalancer automatically creates and configures an Azure Load Balancer. This provides a public or private IP address that can be used to access the application from outside the cluster.

Services also provide basic load balancing by distributing traffic across multiple pod instances, ensuring both availability and scalability.

Namespaces – Logical Isolation in Kubernetes

As Kubernetes clusters grow, managing multiple applications, teams, or environments within the same cluster can become complex. To address this, Kubernetes provides namespaces as a way to logically separate resources.

A namespace acts as a virtual boundary within a cluster. It allows you to organize and isolate resources such as pods, services, and deployments without requiring separate clusters.

Common use cases for namespaces include:

• separating environments (e.g., development, testing, production)
• isolating workloads between teams or projects
• organizing resources for better manageability

Each resource in Kubernetes belongs to a namespace. When working with tools like kubectl, you can target a specific namespace to scope your operations accordingly.

Namespaces also enable more advanced scenarios, such as applying resource quotas, access controls (RBAC), and policies on a per-namespace basis. This makes them an essential building block for multi-tenant or larger-scale environments.

By default, Kubernetes includes several namespaces, such as:

• default – used when no namespace is specified
• kube-system – contains system components managed by Kubernetes
• kube-public – intended for publicly accessible resources within the cluster

In short, namespaces provide a simple but powerful way to organize and isolate workloads within a Kubernetes cluster.

Kubernetes Beyond Azure – AWS and Google Cloud

While this series focuses on Azure Kubernetes Service (AKS), Kubernetes itself is cloud-agnostic and available across all major cloud providers.

In Amazon Web Services (AWS), Kubernetes is offered as Elastic Kubernetes Service (EKS). Similar to AKS, AWS manages the control plane, while you are responsible for managing the worker nodes (unless using serverless options like Fargate). EKS integrates tightly with AWS services such as IAM, VPC networking, and Elastic Load Balancing.

In Google Cloud Platform (GCP), Kubernetes is available as Google Kubernetes Engine (GKE). GKE is often considered one of the most mature managed Kubernetes offerings, as Kubernetes originally originated from Google’s internal systems. Like AKS and EKS, GKE provides a managed control plane and deep integration with the cloud ecosystem.

Despite differences in implementation and integration, the core Kubernetes concepts, pods, deployments, services, and namespaces, remain the same across all platforms. This portability is one of Kubernetes’ biggest strengths, allowing workloads to be moved between environments with minimal changes.

However, each cloud provider introduces its own specifics, particularly around networking, identity, storage, and load balancing. Understanding these differences becomes important when designing multi-cloud or hybrid architectures.

Summary and What’s Next

In this first part of the series, we introduced the fundamental concepts of Kubernetes and built a solid foundation for understanding how container orchestration works in practice.

We covered the core building blocks of Kubernetes, including its architecture, the roles of the control plane and worker nodes, and key objects such as pods, deployments, and services. In addition, we explored namespaces as a way to logically organize and isolate workloads within a cluster.

To provide a broader perspective, we also briefly looked at how Kubernetes is implemented across major cloud providers such as AWS and Google Cloud, highlighting its cloud-agnostic nature.

These fundamentals are essential for working with Kubernetes effectively, regardless of the platform.

In Part 2, we move from general Kubernetes concepts to the Azure-specific implementation using Azure Kubernetes Service (AKS), where we will explore its architecture, components, and integration with Azure services.

With the core concepts in place, the next step is to understand how Kubernetes is implemented in Azure and how these building blocks map to real-world infrastructure.

Links

What is Azure Kubernetes Service (AKS)?
https://learn.microsoft.com/en-us/azure/aks/what-is-aks

What is Amazon EKS?
https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html

What is Kubernetes?
https://cloud.google.com/learn/what-is-kubernetes

Google Kubernetes Engine (GKE)
https://cloud.google.com/kubernetes-engine