Module 7: Eks Specifics For Production
1. Module introduction: why this one is different from the previous six
Description
Modules 1-6 have something in common that wasn't said out loud until now because it didn't need to be: everything you ran, actually ran. kind create cluster, every kubectl apply, metrics-server, ingress-nginx, Gitea, ArgoCD, OPA Gatekeeper, Kyverno, trivy image — six complete modules against a real Kubernetes cluster, on your machine, with no paid-plan limit and no AWS account involved. This module breaks that pattern, and does it on purpose, with the exact reason declared before you even get to wonder why: EKS isn't a service this ecosystem can run at $0, not even with LocalStack's most expensive paid plan.
This lesson exists so that honesty arrives first, before any EKS YAML. The rest of the module — node groups, Karpenter, IRSA, the AWS Load Balancer Controller — gets shown, explained in depth, and verified against official AWS documentation. None of it runs against a real AWS account. Every time it appears, it's going to be labeled (representative), with the exact technical reason, not a vague promise that "this would normally work like this."
Connection to the module
Module 1 left you with andes-cargo-cluster running on kind. Modules 2-6 built, layer by layer, a complete production system on top: Pods with replicas, externalized configuration, metrics-based autoscaling, Ingress, NetworkPolicy, GitOps with ArgoCD, and runtime guardrails with two admission-control engines. All of that is, literally, Kubernetes — the same kube-apiserver, the same etcd, the same object model running on an EKS node. What this module adds isn't "more Kubernetes": it's what changes around that same Kubernetes when, instead of kind administering your control plane in a Docker container on your laptop, it's AWS administering it, with a service level agreement (SLA) in place, inside your account.
The exact citation: why EKS doesn't run in this lab
docs.localstack.cloud, LocalStack's official documentation, marks every service with a badge indicating which pricing plan it's available in. For EKS (Elastic Kubernetes Service), that badge literally says:
"Included in Plans: Ultimate"
It's not in the free plan (Hobby/Community, the one this guide used for everything else). It isn't in the mid-tier paid Base plan either, the one that does cover other services named in this ecosystem's sibling guides (ECR, ECS). Of every AWS service that shows up in any guide in this ecosystem so far, EKS is the one that demands LocalStack's highest price tier.
But there's a second finding, verified in the same documentation, that matters more than the first for this module's design decisions: even if someone paid for the Ultimate plan, what LocalStack offers under the name "EKS" isn't a faithful replica of AWS's managed control plane. The documentation describes, in its own words, how it works underneath:
"The default approach for creating Kubernetes clusters using the local EKS API is by setting up an embedded k3d kube cluster within Docker."
Translated with no loss of precision: when you ask LocalStack to create an "EKS" cluster, what actually boots underneath is a k3d cluster — a packaging of k3s, a lightweight Kubernetes distribution, running in Docker containers — wrapped in API calls that mimic EKS. It's, in practice, the same underlying idea as kind (Kubernetes-in-Docker), with a different lightweight distribution name underneath, disguised as the EKS API. There's no IRSA actually evaluated against a real AWS account's OIDC provider. There's no AWS Load Balancer Controller creating a real ALB, because there's no real Elastic Load Balancing behind LocalStack for that controller to talk to. There are no node groups managed by real Auto Scaling Groups, because there's no real EC2 behind it.
WHAT "EKS" MEANS AT EACH LAYER
Real EKS (AWS) "EKS" on LocalStack Ultimate
kube-apiserver/etcd k3s embedded in k3d
administered by AWS, with an SLA running in Docker containers
│ │
IRSA / EKS Pod Identity no real evaluation of an
against a real OIDC provider IAM trust policy
│ │
AWS Load Balancer Controller no real ELB behind it —
creates a real ALB in your VPC there's nothing to create
│ │
Node groups → real Auto Scaling no real EC2 behind it
Groups → real EC2 instances
CONCLUSION: paying for Ultimate buys a second lightweight
Kubernetes-in-Docker distribution, wrapped in EKS API
calls — it doesn't buy the real managed control plane
this module teaches.For this exact reason, this guide doesn't use LocalStack for EKS, not even as a paid option shown for completeness. The pedagogical value of simulating a simulation is low, compared to what you already have: kind, which is real Kubernetes, with no imitation layer at all.
What ran, and what didn't — this module's honesty table
| Module | What got executed | Against what |
|---|---|---|
| M1 | kind create cluster, control plane architecture, image loading | Real Docker, on your machine |
| M2 | Pod, Deployment, Service, real load balancing | andes-cargo-cluster (kind) |
| M3 | ConfigMap, Secret, probes, HorizontalPodAutoscaler with real load | andes-cargo-cluster (kind) |
| M4 | ingress-nginx installed, Ingress, default-deny NetworkPolicy | andes-cargo-cluster (kind) |
| M5 | Gitea, ArgoCD, real pull-based sync, selfHeal demonstrated | andes-cargo-cluster (kind) |
| M6 | OPA Gatekeeper v3.23.0, Kyverno v1.18.2, trivy image, both engines active at once | andes-cargo-cluster (kind) |
| M7 (this one) | Nothing against real AWS — managed control plane, node groups, Fargate profiles, Karpenter, IRSA/Pod Identity, AWS Load Balancer Controller | Representative: real YAML/CLI, verified against docs.aws.amazon.com/eks and eksctl.io, never applied against an account |
| M8 | This module's migration document, and the final end-to-end walkthrough | andes-cargo-cluster (kind), honest documentation |
Notice the pattern: six executed modules, one representative, one that documents the boundary between the two. This isn't a guide that gradually becomes representative — it's a guide that executes almost everything, and precisely declares the one block it can't execute, and why.
Analogy: renting an apartment with maintenance included, versus owning your own house
Picture two ways of having a roof over your head. The first is renting an apartment in a building with management: if a pipe breaks, there's a super who fixes it; if the elevator fails, someone repairs it without you lifting a tool; you pay a monthly fee, and in exchange you never have to worry about the building's structure itself — only about what happens inside your unit. The second is owning your own house: if the roof leaks, you fix it yourself (or hire someone and supervise them yourself); if the boiler breaks on a Sunday night, it's your problem to solve, no one else's.
An EKS cluster is the apartment with maintenance included: AWS administers the building (kube-apiserver, etcd, the complete control plane), with a service level agreement in place, and your team focuses on what happens inside the unit (your workloads, your Deployments, your policies). A kind cluster, the one you built since Module 1, is the house you own: you built the entire "building" with a single command (kind create cluster), and even though you never had to think of it in those terms, you were responsible for the whole control plane — there just wasn't anything broken for you to notice. The next lesson makes that contrast explicit, component by component.
This module's map: the 8 lessons
MODULE 7 — WHAT'S SPECIFIC TO EKS FOR PRODUCTION
(representative, with the technical reason declared in every lesson)
M7.1 Introduction (this one) cost honesty, first
M7.2 The managed control plane what AWS administers, what it doesn't
M7.3 Node groups, self-managed, Fargate profiles the 3 forms of compute
M7.4 Karpenter vs Cluster Autoscaler HPA scales Pods; this scales nodes
M7.5 IRSA and EKS Pod Identity OIDC applied to a Pod
M7.6 AWS Load Balancer Controller the real production Ingress
M7.7 Hands-on: the EKS YAML representative, verified
M7.8 Project: the migration plan EXECUTED — the real document| # | Lesson | What it builds |
|---|---|---|
| 1 | Introduction (this one) | The central cost honesty; what got executed in M1-M6, what doesn't get executed in M7 |
| 2 | The managed control plane | AWS's kube-apiserver/etcd vs. what the team still administers; contrast with kind |
| 3 | Node groups: managed, self-managed, Fargate profiles | The three forms of compute behind EKS, eksctl/Terraform shown |
| 4 | Node autoscaling: Karpenter vs Cluster Autoscaler | Contrast with M3's HPA — Pods fixed on nodes vs. nodes that appear |
| 5 | IRSA and its successor, EKS Pod Identity | The OIDC pattern applied to a Pod, closing with StatusApiTaskRole |
| 6 | The AWS Load Balancer Controller | Same Ingress object, different controller — contrast with ingress-nginx (M4) |
| 7 | Hands-on: the EKS YAML, shown and explained | eksctl create cluster, IAMServiceAccount, IngressClass — representative, verified |
| 8 | Project: Andes Cargo's migration plan | EXECUTED — the real document, kind → EKS, resource by resource |
By the end of this module you're going to have something different from what the previous six left you: not one more running system, but the complete judgment to read, evaluate, and plan a real migration from kind to EKS — with no money spent, and no faked claim that something ran when it didn't.
Common mistakes
Expecting a "hands-on" with kubectl apply against a real AWS account somewhere in this module (expectation). What happens: someone, used to the previous six modules' pattern — every concept followed by a kubectl actually executed — looks for the same pattern here and gets frustrated not finding it. Why it happens: it's the pattern this very guide installed, with full intention, for six modules straight. How to spot it: if you reach lesson 7 (this module's "hands-on") expecting to see real output from an eksctl create cluster against AWS. How to fix it: this very lesson declared it first — lesson 7 is named, with full intention, "the YAML shown and explained," not "hands-on executed." It's real syntax, verified against official documentation, never run against an account.
Thinking "representative" means "made up" or "not trustworthy" (interpretation). What happens: someone reads the "(representative)" label and confuses it with "this might be wrong, no one verified it." Why it happens: in many contexts, "not executed" gets used as a synonym for "not verified." How to spot it: if you doubt a command or a YAML field in this module just because it didn't run against a real account. How to fix it: every representative piece of this module is checked against current official documentation (docs.aws.amazon.com/eks, eksctl.io, karpenter.sh), cited with its exact source — "representative" describes that there was no execution against AWS, not that the described syntax or behavior is doubtful.
Assuming this module is going to try EKS via LocalStack Ultimate, "even if only partially" (expectation about the lab). What happens: someone, knowing LocalStack offers EKS in its most expensive plan, expects this module to at least mention it as a viable option to run something. Why it happens: it seems reasonable that "paying more" would solve the "I can't run this for free" problem. How to spot it: if you look, in this module, for a docker run localstack/localstack-pro step with EKS enabled. How to fix it: this lesson already explained why that path got ruled out — not because of cost (though that's also a real barrier), but because what's behind that API, even paying for it, is another lightweight Kubernetes-in-Docker distribution, not the real managed control plane this module teaches.
Exercises
Exercise 1 — Rewrite the key citation without copying it. Without looking back at this lesson's "The exact citation" section, write from memory: (a) the plan badge LocalStack assigns to EKS, and (b) what technology LocalStack's documentation says runs underneath when someone creates an "EKS" cluster in that environment.
See solution
(a) "Included in Plans: Ultimate" — the most expensive paid plan LocalStack offers, higher than the Base plan that does cover other services in the ecosystem. (b) A k3d cluster (packaging of k3s, a lightweight Kubernetes distribution), running inside Docker, wrapped in API calls that mimic EKS — not a faithful replica of AWS's managed control plane.
Exercise 2 — Explain, in two sentences, why paying for the Ultimate plan wouldn't solve the underlying problem. A colleague asks you: "why don't you just pay for LocalStack Ultimate and actually run EKS in this module?" Answer them without using the word "cost" or "money" in your explanation.
See solution
A complete answer sounds, roughly, like this: "Even if we paid, what that API delivers underneath isn't AWS's real managed control plane — it's another lightweight Kubernetes distribution running in Docker, disguised as EKS — so there would be no IRSA evaluated against a real OIDC provider, no AWS Load Balancer Controller creating a real load balancer, no node groups backed by real EC2. Paying would buy a second simulation, not the system this module teaches." If your answer mentioned the problem is one of fidelity, not just price, you captured this lesson's central point.
Exercise 3 — Predict which lesson IS going to have executed evidence in this module, if nothing runs against AWS. Based on this lesson's honesty table, predict which lesson of this module is going to carry the "EXECUTED" label instead of "representative," and why that lesson can be executed with no AWS account.
See solution
Lesson 8, the module's final project: the migration plan for andes-cargo-k8s/ from kind to EKS. It can actually be executed because it requires no call to AWS at all — it's a document, a resource-by-resource table built against the real manifests that already exist in the repository (Modules 1-5), not against an external API. It's the same distinction other guides in the ecosystem already used: an analysis document, written against real, already-existing evidence, can be "executed" (the document itself is the real deliverable) even when the system it describes (EKS) isn't.
Summary and next step
This lesson established, before any other content in this module, this guide's central cost honesty: EKS is marked "Included in Plans: Ultimate" in LocalStack's official documentation — the highest price tier of any service named in this ecosystem — and, more important, even paying for that API doesn't faithfully reproduce AWS's real managed control plane, because it runs on a lightweight Kubernetes-in-Docker distribution (k3d/k3s) underneath. For this reason, all of Module 7 stays representative: shown, explained in depth, and verified against official documentation, but never executed against a real AWS account.
Before moving on you should be able to: cite LocalStack's exact badge for EKS; explain why paying for the Ultimate plan wouldn't solve the fidelity problem; and name, from memory, which of this module's eight lessons does have executed evidence, and why.
Next lesson: the managed control plane — what AWS administers, what stays yours. There you're going to see, component by component, the direct contrast with what kind had you administering without you knowing it.
Resources
- LocalStack — Elastic Kubernetes Service (EKS) — the exact source for the "Included in Plans: Ultimate" badge and the description of the embedded implementation via k3d/k3s.
- Amazon EKS — What is Amazon EKS? — the official definition of the service this module teaches without executing.
kubernetes-and-eks-in-production-guide(NIEVA), Module 1, lesson 6 —kind's architecture, which the next lesson directly contrasts against EKS.cloud-security-and-guardrails-guide(NIEVA), Module 2, lesson 6 — the same underlying limit (LocalStack Hobby doesn't evaluate identity or paid-tier enforcement) documented there for GitHub Actions OIDC, the same pattern this module documents for IRSA in lesson 5.