Azure Kubernetes Service (AKS) - Simply Explained

You've heard Kubernetes and AKS get thrown around in cloud conversations. Maybe you nodded along, but honestly, what did they actually mean for someone running applications in the cloud? Containers changed how we built software because they're lightweight, portable, and consistent. The problem is managing the manually gets messy fast. A handful of containers you can handle. But when you have dozens or hundreds, you spend all your time on scaling, updates, and dealing with failures instead of building your actual product. By the end of this episode, you'll understand the four big things as your Kubernetes service handles for you. The control plane, the nodes, the networking, and the security will also break down what it actually costs. No marketing fluff, just plain English. The container problem, why we need AKS? Containers took over because they solve a real pain. A package bundling your application code, runtime, libraries, and configuration, it runs the same on your laptop in a test server or in production. No more, it works on my machine problems. Running a handful of containers works fine. You start them manually, check their logs, restart them when they crash. But once you have dozens or hundreds spread across multiple servers, you run into a whole new set of problems. You need to decide where each container goes, which server gets which container, how they find each other over the network. What happens when one crashes at three in the morning? And how to handle a traffic spike demanding 50 more copies of your app in 30 seconds. Kubernetes is an open source platform designed for exactly these problems. It schedules containers onto servers, scales them up and down, checks their health, and routes traffic between them. It's the industry standard for container orchestration, but Kubernetes solves one problem and creates another. Running it yourself is complex. You have to set up and maintain a control plane. The brain of the cluster, manage worker nodes, apply security patches, upgrade versions, and backup configuration data. That's a full time job for someone who knows what they're doing. Managed services like Azure Kubernetes Service take that operational burden off your shoulders. Microsoft runs the control plane for you and handles the upgrades, patches, and backups. You focus on your applications. So what exactly does AKS do for you? Let's start with the biggest piece, the control plane. What is Azure Kubernetes Service? AKS is Microsoft's managed version of Kubernetes. Plane and simple, you get a fully functional Kubernetes cluster without having to set up or maintain the underlying infrastructure. Microsoft runs the control plane for you and you focus on deploying and running your applications. Think of it like renting an apartment versus building a house. When you build a house, you're responsible for everything, the foundation, plumbing, electrical roof. When you rent the landlord handles all that, you just move in and decorate. AKS is the landlord. Microsoft handles the foundation, the control plane, networking, security patches, and upgrades. You bring the furniture, your containerized applications, configurations, and deployment pipelines. But AKS isn't just a standalone Kubernetes cluster. It works tightly with the rest of the Azure platform. Entra ID handles user authentication and access control. Azure Monitor collects logs and metrics from your cluster and your applications. As your policy lets you enforce rules across all your clusters, things like no containers running as root or all images must come from an approved registry. These integrations are what make AKS more than just Kubernetes running on Azure VMs. Now, you still need to know the basic Kubernetes concepts, pods, deployments, and services. That's the knowledge you bring. AKS doesn't replace that. But what it does remove is the operational overhead of keeping the cluster healthy. You don't worry about the control plane going down. You don't manually upgrade Kubernetes versions but you don't back up ETCD the cluster's configuration database. Microsoft handles all of it. So let's pull back the curtain on that brain, the control plane, the control plane, the brain Microsoft manages. What exactly is inside that control plane? Four main components. The API server is the front door. Every command, request, and interaction with your cluster goes through it. The scheduler decides which node runs each new pod, the controller manager watches the cluster state and makes sure reality matches what you asked for. And ETCD stores all the configuration data. Think of it as your cluster's memory. If ETCD gets corrupted or lost, you've lost the cluster. If you set up Kubernetes yourself, you're responsible for all of this. You patch the API server when vulnerabilities appear. You backup ETCD regularly. You handle hardware failures on the machines running these components. It's a lot of work. With AKS, Microsoft takes that off your plate. They run the control plane on their own infrastructure. They patch it, back it up, and monitor it. You never see the underlying machines. You just interact with the API server endpoint and everything else happens behind the scenes. But not all control planes are the same. AKS offers three tiers, free standard and premium. The free tier gives you the control plane at no extra cost, no SLA on the API server. It's fine for learning, development, or test environments where a few minutes of downtime won't hurt. But for production workloads, you'll probably want more. The standard tier costs about $72 per month per cluster. That gives you a 99.95% SLA on the API server when you use availability zones. If the control plane goes down, Microsoft credits you. It's the default choice for most production clusters. The premium tier runs about $432 per month. You get everything in standard plus long term support for Kubernetes versions. If you're running a regulated workload that needs to stay on a specific version for months or years, that's where premium makes sense. Here's the key point though. You don't actually pay for the control plane itself. The free tier is truly free. Standard and premium are fees for the SLA and long term support, not for the control plane resources. What you do pay for are the worker nodes, the VMs that run your containers. Those are built separately at standard as your VM rates. So think of it this way. The control plane is the brain. Microsoft manages it for you. You choose the service tier based on your reliability needs. But the real work of running your applications happens on the worker nodes. Those worker nodes are where your applications actually run. Let's talk about them. The nodes, the workers you pay for. Nodes are Azure virtual machines, plane and simple. Standard Azure VMs that host your pods, which are the smallest unit in Kubernetes running one or more containers. You choose the size and the number. So if you want a D2.3 with two VCPUs and eight gigs of RAM, you can do that. Need a memory optimized E32 with 32 VCPUs and 256 gigs. That works too. Now, you don't just throw random VMs together. AKS organizes them into node pools. A node pool is a group of identical VMs with the same size and configuration. You can have multiple node pools in the single cluster, one pool with general purpose D-Series VMs for your web frontend, another with memory optimized E-Series VMs for your database, and a third with GPU enabled VMs for machine learning workloads. Each pool scales independently. And that scaling is automatic. The cluster autoscaler monitors your pods. When they need more resources, then current nodes can provide. It adds new nodes. And when traffic drops and nodes sit mostly idle, it removes them. You set the minimum and maximum size for each pool and AKS handles the rest. This is where you save real money. You're not paying for idle capacity during off-peak hours. Node upgrades are another thing AKS handles. When a new OS security patch comes out, AKS can apply it to your nodes, and when a new Kubernetes version is released, AKS can upgrade your cluster. You control the schedule you decide when upgrades happen, not Microsoft. The actual work of draining pods, updating nodes, and bringing them back online is handled for you. Now the cost, you pay standard Azure VM rates for your nodes. A D2.3 in East US runs about $70 per month and a larger VM costs more. But there are ways to bring that down significantly. Reserved instances let you commit to one or three years in exchange for a discount, saving up to 72% compared to pay as you go pricing. If you know your baseline capacity, the nodes you always need running, reserving them makes a lot of sense. Spot VMs are even cheaper. Up to 90% off pay as you go rates, but here's the catch. Azure can reclaim that capacity at any time, giving your nodes 30 seconds notice before eviction. That's fine for batch jobs, CI/CD pipelines or stateless workloads that can handle interruptions, but not great for your customer-facing production API. So you pay for the workers, you choose the size, the number, and the pricing model, while AKS manages the pools, the scaling, and the upgrades. Your nodes and pods need to talk to each other. And that's where networking comes in. Networking, how pods talk. Every pod in your cluster needs an IP address, but pods come and go constantly. They crash, they scale up, they get replaced. So you need a system that hands out IPs dynamically and makes sure pods can reach each other. That's what the container networking interface does. Azure CNI is Microsoft's implementation, and it manages how pods get addresses and how traffic flows between them. There are two main networking models you can choose from. Overlay networking gives pods IPs from a separate address range that's not part of your virtual network. This is the more scalable option. You can have up to 5,000 nodes and a quarter million pods in a single cluster. Because pod IPs are isolated from your VNet, you can reuse the same address space across multiple clusters without conflicts. The trade-off is that pods can't be accessed directly from outside the cluster. Traffic leaving a pod gets translated to the nodes IP address. The other option is flat networking, where pods get IPs directly from your VNet range. External systems can reach pods directly if needed, but the downside is you're consuming IP addresses from your VNet, which can run out quickly if you have a lot of pods. You need to plan your subnet sizes carefully. Now let's talk about traffic leaving your cluster. When a pod needs to reach something on the internet, an external API, a database, a third-party service, that traffic has to go through something. By default, AKS uses an Azure load balancer for outbound connections and works fine for most workloads. But if your applications make a lot of outbound connections, you can run into something called snap port exhaustion. Each node gets a fixed number of source network address translation ports. And when they run out, new connections fail. The solution is Azure and Ad Gateway, which handles high connection counts much better. For exposing your applications to the internet, there are two main approaches. For applications that communicate over TCP or UDP, things like gaming servers, databases, or custom protocols, you use a load balancer service. It gives your app a public IP and forwards traffic at layer four. For web applications that use HTTP or HTTPS, you want an ingress controller. This works at layer seven. It understands URLs, paths, and host names. You can route traffic to different services based on the domain name or the URL path. And one public IP can serve dozens of applications. AKS supports managed ingress options like the application gateway for containers. Or you can run your own like NGNix. One mistake people often make is creating their AKS cluster with a subnet that's too small. Maybe a 28 subnet, 16 IPs total. That works for a small test cluster, but AKS reserves IPs per node. A three node cluster with a 28 might be fine today, but next month you add a node pool, your traffic grows, and suddenly you can't scale. And you cannot change the subnet's IDR after the cluster is created. You'd have to rebuild the cluster or create a new node pool on a different subnet and migrate your workloads. Plan your subnet sizes for growth from day one. Once your app is running and reachable, you need to lock it down. Security, who gets in? So how does security actually work in AKS? Think of it like a building with multiple layers of protection. The first layer is identity and access who gets through the door. You connect your cluster to Enter ID, which is Microsoft's identity service. It used to be called Azure Active Directory. Your team logs in using their normal work credentials no separate accounts needed. Then on top of that, you add Kubernetes R back, which is role-based access control. This decides who can see what, who can deploy pods, who can delete resources. A developer might only get access to their own namespace, while an operator has cluster wide read access and an admin gets full control. You can map intro groups directly to Kubernetes roles, so when someone joins or leaves the team, you update the intro group and permissions follow automatically. It's the reception desk handling access for the whole building. Network security is layer two. By default, your AKS cluster's API server is accessible over the public internet, and while you can restrict it to specific IP ranges, the endpoint is still exposed. For production workloads, you'll want a private cluster instead. That way the API server gets an internal IP from your VNet, accessible only through Azure Private Link, no public exposure whatsoever. Anyone managing the cluster needs to be connected to your network whether through a VPN, express route, or a jumpbox inside the VNet. Then we get down to pod security, which is where most container vulnerabilities happen. The number one rule, do not run containers as root. If a container runs as root and an attacker breaks in, they have root access on the host. Same with privilege escalation, disable it. Use Azure Policy for Kubernetes to enforce these rules automatically. You can say no container in this namespace can run as root, and the policy blocks any deployment that violates that rule before it ever reaches a node. Secrets are the next big one. Never store passwords, API keys or connection strings in your code or container images. People do it all the time. They hard code a database password in a config file, build the image, push it to a registry, and that password is now embedded forever. Anyone with access to the registry can extract it. Instead use Azure Key Vault. Store your secrets there and let your pods access them through the secret store CSI driver. The pod mounts the secret as a volume or environment variable at runtime, and the secret never touches your image or source code. Finally, monitoring. Microsoft Defender for Containers scans your container images for known vulnerabilities and monitors your cluster for suspicious activity, privilege escalation attempts on usual network connections, crypto mining workloads. It's not a set it and forget it tool, but it catches things you might miss on your own. Even with all that things can go wrong. So let's look at the most common pitfalls. Common pitfalls, what goes wrong? What trips people up most often? Let's walk through the usual suspects. First up is Azure Quotar Limits. Your Azure subscription has limits on how many VCP use you can use in a given region, and the same goes for public IPs, load balances and other resources. When you create an AKS cluster, it consumes some of that quota. If you hit the limit, cluster creation fails or scaling stops working. The fix is straightforward, request a quota increase through the Azure portal. But do it before you need it, not when a deployment is stuck at 2am. Next is subnet sizing, and this one hurts because you can't fix it after the fact. AKS reserves IP addresses per node, and each node needs a certain number of IPs for pods. If your subnet is too small, you'll run out of addresses and you cannot expand a subnet after the cluster is created. So plan for growth. If you think you need 10 nodes today, provision enough IPs for 50. A 24 subnet gives you 251 usable IPs, which is a good starting point for most clusters. Image pullback office probably the most common pod error you'll see. Your pod tries to pull a container image, and it fails. Usually it's an authentication problem. Your cluster can't access the container registry. Maybe you're using a private registry without credentials or the credentials expired. Check your image pull secrets, make sure the service account has access to the registry and verify the image name is correct. It's rarely a Kubernetes bug. Crash loopback office another frequent one. Your pod starts, runs for a few seconds, crashes, restarts, crashes again. The natural instinct is to blame Kubernetes, but don't. Nine times out of 10, it's your application, a misconfigured environment variable, a missing dependency, a database connection string pointing to the wrong server, check the pod logs with Kubecta logs. The error message is usually right there, and then there's outbound connection exhaustion. Your applications make a lot of connections to external services, API's databases, third party tools. Each connection uses a snap port, and each node has a limited number of those ports. When they run out, new connections fail silently. Your app looks healthy, but it can't reach anything outside the cluster. The fix is to switch to Azure NAT gateway, which handles high connection counts much better than the default load balancer, or use larger node sizes that get more snap ports per node. All these pieces come with a price tag, so let's break down what you'll actually pay. Costs and pricing. So what does AKS actually cost? Let's be clear. The bulk of your build comes from the worker node VMs, the compute, storage, and networking. That's where the real money goes. A D2 or Cilla's V3 node in East US costs about $70 per month. Five nodes, $350, 10 nodes, 700. Those VM costs add up fast. The control plane has three pricing tiers. Free gives you the control plane at no extra cost, but there's no SLA. Standard runs about $72 per month per cluster with a 99.95% SLA on the API server. Premium is about $432 per month, and adds long term support for Kubernetes versions. For most production workloads, standard is your sweet spot. But you can bring those VM costs down. Reserved instances let you commit to one or three years, saving up to 72% compared to pay as you go. If you know your baseline capacity, the nodes you always need running, reserving them is a no-brainer. Azure Savings plans work similarly, but give you more flexibility across different VM families. You commit to a certain hourly spend, and Azure applies the discount automatically. Savings run up to 65%, spot VMs are the cheapest option, up to 90% off, but here's the catch. Azure can reclaim that capacity at any time. Your nodes get evicted, your pods get rescheduled. That works fine for batch jobs, CICD runners, or stateless workloads. Not so much for your production API, cost optimization isn't just about discounts, right size your nodes. Don't provision a 16 core VM when your pods only use two. Use the cluster autoscaler, so you're not paying for idle nodes during low traffic. For low CPU workloads, consider B-Series VMs. They're burstable and significantly cheaper than D-Series. Don't forget storage and data transfer either. Persistent volumes at cost. Azure disk is fast but expensive, as your files is cheaper but slower. Choose based on your workloads performance needs. Data egress, traffic leaving Azure also costs money. Keep your traffic within the same region when possible. So when does AKS actually make sense? Let's talk real world guidance. When should you use AKS? AKS shines with microservices architecture. You have multiple independent services that need to scale separately. The front end might need 10 replicas during peak hours while the back end only needs three. AKS handles that naturally. Each service scales independently based on its own traffic. Higher availability is another strong case. AKS distributes your pods across multiple nodes. If a node fails, the pods get rescheduled onto healthy nodes. If you use availability zones, your cluster can survive an entire data center going down. For applications that need to be up 24/7, that's valuable. CI/CD integration is where AKS really pays off. You build your container image, push it to a registry and AKS deploys the new version with a rolling update. Zero downtime. If something goes wrong, you roll back. No manual SSH into servers, no copy-pasting files, the pipeline handles everything. But AKS isn't always the right answer. If you have a simple monolithic application running on a single VM, AKS adds complexity without much benefit. You'd be managing Kubernetes just for the sake of managing it. Sometimes a VM and app service or even Azure functions is the simpler, cheaper choice. If you're just starting out, use the free tier. Create a cluster, deploy a test application, break things, fix them, learn the concepts without worrying about cost. When you're ready for production, move to standard. Let's bring it all together. So here's what you need to remember. AKS takes care of four big things. Microsoft manages the control plane. That's the brain of the cluster. You choose the size and number of nodes, the worker VMs, and AKS handles the pools and scaling. For networking, pods talk to each other and the outside world through Azure's C&I, and AKS integrates with it to make everything work. Security tools are built in, identity, network isolation, pod hardening. You only pay for the compute, nodes, storage, and networking. The control plane itself is free on the free tier. You only need standard or premium if you want the SLA or long term support. Your next step, create a free AKS cluster in the Azure portal. Deploy a simple test application, NGNX, or a Hello World container. See how it works? Break it and fix it. That hands-on experience beats any tutorial. If this episode helped, subscribe for more plane English Azure explanations and share it with someone starting their cloud journey.