Eks

Right, so you’ve decided you want an EKS cluster. Good for you. You’ve also decided you don’t want to spend the next three weeks hand-crafting Terraform or CloudFormation for the VPC, IAM roles, node groups, add-ons, and all the other fiddly bits that AWS requires. You’re smarter than that. This is where EKS Blueprints comes in—it’s a collection of opinionated, pre-packaged modules for Terraform and CDK that aims to get you from zero to a fully-functional, production-ready cluster in a shockingly small amount of code. It’s like a brilliant but stubborn architect who says, “Trust me, I’ve already made all the hard decisions for you.”

Alright, let’s talk about Karpenter. Forget everything you thought you knew about autoscaling in Kubernetes, because this thing is a different beast entirely. The old Cluster Autoscaler (CAS) was like trying to parallel park a cruise ship—it worked, eventually, but it was slow, clunky, and you had to pre-define every single parking spot (node group) you might ever need. Karpenter is like teleportation. You say “I need a node with 4 CPUs and 16GB of RAM,” and it materializes the perfect instance for the job, often before the pod scheduler has even finished its cry for help. It’s not just scaling; it’s provisioning, and it does it with terrifying speed and efficiency.

Alright, let’s talk about getting traffic into your EKS cluster. You’ve got your pods running, your services defined, and now you need the outside world to actually see them. You could manually create an Application Load Balancer (ALB) or Network Load Balancer (NLB) in the AWS console every time you need one, but that would be tedious, error-prone, and frankly, a betrayal of the entire GitOps, declarative ethos we’re living in. Enter the AWS Load Balancer Controller (ALB Controller, for short—its name is a bit of a mouthful, as it handles both ALBs and NLBs).

Right, let’s talk about giving your pods an identity. Because by default, your pods running in EKS have precisely zero IAM permissions. They’re the digital equivalent of a hermit living off-grid—completely isolated from the AWS universe. You could solve this the old, terrible way: grant the massive, terrifying IAM permissions your app needs to the EC2 instance role of the worker node. Then every pod on that node, from your mission-critical app to that random busybox pod you forgot about, inherits those god-like powers. This is a security nightmare waiting to happen, and we’re not doing that.

Right, let’s talk about EKS add-ons. This is where AWS tries to make your life easier by managing some of the core components of your Kubernetes cluster for you. Think of them as the official, blessed-by-AWS versions of things you’d otherwise have to go find, install, and update yourself. It’s a good idea, mostly. We’ll cover the big four: VPC CNI, CoreDNS, kube-proxy, and the EBS CSI Driver. The first thing you need to know is that these aren’t magic. Under the hood, an EKS add-on is essentially AWS using its API to deploy a specific, validated version of a Helm chart or a manifest into your cluster’s kube-system namespace on your behalf. The value isn’t in the initial install—you could do that in five minutes. The value is in the ongoing management. AWS will tell you when new versions are available and handle the (mostly) safe rollout for you. It’s one less thing on your plate.

Alright, let’s talk about the actual compute in your cluster: the nodes. In EKS, you’ve got three main flavors for getting your worker nodes running: Managed Node Groups (MNGs), self-managed nodes (usually via the aws-iam-authenticator and some CloudFormation voodoo), and the serverless oddball, Fargate. Each has a superpower and a corresponding kryptonite. Your job is to pick which trade-off you want to live with. Managed Node Groups: The Easy Button (Mostly) This is AWS saying, “Look, you have enough to worry about. Let me handle the grimy details of the EC2 instances for you.” And 90% of the time, you should listen. An MNG isn’t just an Auto Scaling Group (ASG) that EKS knows about; it’s a tightly integrated abstraction that handles a ton of boilerplate for you.

Right, let’s talk about the brain of your EKS cluster: the control plane. When you hear “managed,” your brain might conjure images of AWS handling all the tedious bits while you kick back. And for the most part, that’s true. But “managed” doesn’t mean “magic.” It means “we run the fiddly bits you probably don’t want to, and you still need to know how they work so you don’t accidentally set the whole thing on fire.”

Right, let’s talk about saving money. Because let’s be honest, the only thing more terrifying than your Kubernetes cluster melting down is the bill for the cluster that’s sitting there doing nothing. AWS is happy to sell you on-demand instances that you pay for 24/7, but we’re smarter than that. We’re going to harness two of AWS’s most powerful cost-saving tools: Spot Instances and Karpenter. One is a deeply discounted fire sale on compute capacity, and the other is the brilliant, ruthless robot that knows how to shop it.

Right, let’s talk about the three amigos that AWS graciously pre-installs for you on every EKS cluster: CoreDNS, kube-proxy, and the Amazon VPC CNI. Think of them less as optional “add-ons” and more as the “operating system” of your cluster. Without them, your cluster is a very expensive, very confused computer that can’t talk to itself or the outside world. AWS manages the installation and versioning of these for you, which is mostly a blessing, but as we’ll see, sometimes a curse in disguise.

Alright, let’s talk networking. This is where the rubber meets the road in EKS, and frankly, where most people get their knickers in a twist. You’ve got your shiny new cluster, but until your pods can actually talk to each other and the outside world, it’s just a very expensive, very abstract art installation. The two big players here are the VPC CNI plugin and Security Groups for Pods. One provides the fundamental plumbing, the other gives you a much-needed security scalpel. Let’s get our hands dirty.

Right, let’s talk storage. Because your fancy pods are ephemeral, and while that’s great for cattle, not pets, your precious application data needs to live somewhere more permanent than a container’s short, brutal life. You can’t just chmod 777 your way out of this one. In the old, barbaric days of EKS, you’d use the in-tree aws-ebs and aws-efs volume plugins that were baked into Kubernetes itself. Those are now deprecated and scheduled for a not-so-tearful goodbye. The future, and frankly the present, is the Container Storage Interface (CSI).

Alright, let’s talk about getting traffic into your EKS cluster. You’ve got pods, they’re running your brilliant application, but they’re useless if users can’t reach them. You might be thinking, “It’s Kubernetes, I’ll just create a Service of type LoadBalancer and call it a day.” And you’d be right… sort of. On AWS, that classic move doesn’t get you a classic Elastic Load Balancer (ELB) by default. It gets you a Network Load Balancer (NLB). And while NLBs are fantastic for raw performance and preserving the client IP, they’re a bit like a sledgehammer—powerful but not always the right tool for the job, especially for HTTP-based services.

Alright, let’s talk about IAM Roles for Service Accounts, or IRSA. This is, without a doubt, one of the best things to happen to Kubernetes on AWS. Before IRSA, giving a pod permissions to, say, access an S3 bucket was a bit of a nightmare. You’d have to give the EC2 instance running your worker nodes a massive IAM role with all the permissions any pod on that node could ever need. It was the equivalent of handing out the master key to the entire building to every single tenant. Horrifying from a security perspective, and a compliance auditor’s worst nightmare.

Alright, let’s talk about the actual compute power in your EKS cluster: the nodes. This is where your pods actually run, and AWS gives you three distinct flavors to choose from. Picking the right one isn’t just a technicality; it’s the difference between a smooth ride and a part-time job you never applied for. Managed Node Groups: Your Default Choice If you’re not a masochist, start here. An EKS Managed Node Group (MNG) is AWS saying, “Hey, we’ll handle the Kubernetes worker node boilerplate for you.” They provision the underlying EC2 instances, register them with your cluster, and—this is the killer feature—manage the node lifecycle, including automated rolling updates and terminations.

Alright, let’s get our hands dirty. Creating an EKS cluster feels like it should be a one-click affair, right? It’s “managed” after all. And then you see the console form with roughly 47 dropdowns and realize, ah, this is AWS’s version of “managed”—they manage the control plane, you manage the configuration headache. Don’t panic. We’ve got three main paths out of this jungle: the AWS Console (for the masochists and the curious), eksctl (for people who value their time), and Terraform (for those of us who need to build something repeatable and robust). I’ll walk you through all three, but I’m not going to pretend they’re all equally admirable.