The mental model that finally helped me understand Kubernetes, Amazon EKS, worker nodes, IAM, networking, and scaling.
Kubernetes has a reputation for being complicated.
And honestly, I understand why.
The first time I looked at a Kubernetes architecture diagram, I saw terms like:
API Server. etcd. Scheduler. Controller Manager. kubelet. kube-proxy. Pods. Nodes. CNI. CoreDNS.
Then I started looking at Kubernetes on AWS, and suddenly there was another layer:
IAM roles, VPCs, subnets, security groups, EC2, ECR, Auto Scaling Groups, CloudWatch…
It felt like there were hundreds of things I needed to understand before I could even run a simple application.
But over time, I realized something:
Kubernetes becomes much easier when you stop trying to memorize everything and start with the mental model.
So in this post, I want to share the way I think about Kubernetes and Amazon EKS.
My goal isn’t to give you a list of commands to memorize.
Instead, I want to help you understand what we’re actually building, why each component exists, and how all the pieces fit together.
📚 Table of Contents
- Kubernetes: What Problem Does It Solve?
- The Kubernetes Mental Model
- Control Plane
- Worker Nodes
3. Understanding the Control Plane
4. Why Amazon EKS?
5. Building an EKS Cluster
- IAM
- VPC & Networking
- API Access
- Kubernetes Add-ons
6. Worker Nodes & Scaling
7. The Mental Model to Take Away
So, What Is Kubernetes?
At its core, Kubernetes is a container orchestration system.
Its job is to automate the deployment, scaling, and management of containerized applications.
Let’s say I have an application packaged as a container.
Running one container is relatively simple.
But what happens when I need to:
- Run multiple copies of my application?
- Restart a container when it fails?
- Distribute traffic between instances?
- Deploy a new version?
- Scale up when traffic increases?
- Manage many containers across multiple machines?
Doing all of that manually becomes difficult very quickly.
That’s where Kubernetes comes in.
And the first mental model I want you to remember is incredibly simple:
Kubernetes Cluster
|
+------------+------------+
| |
Control Plane Worker Nodes
"The brain" "The workers"
That’s where I recommend starting.
Everything else builds on top of these two sides.
The Two Parts of a Kubernetes Cluster
A Kubernetes cluster has two major parts:
- The control plane
- The worker nodes
Understanding this distinction is probably the most important thing I learned when getting started with Kubernetes.
1. Worker Nodes: Where My Application Runs
Worker nodes are the machines that actually run my containerized applications.
Inside a worker node, Kubernetes has several components that help manage those workloads.
One of the most important is the kubelet.
The kubelet makes sure the containers expected to run inside Kubernetes Pods are actually running properly.
Kubernetes also supports container runtimes such as containerd and CRI-O, while kube-proxy maintains networking rules that allow communication with Pods.
So I like to visualize a worker node like this:
Worker Node
|
+---- kubelet
|
+---- Container Runtime
|
+---- kube-proxy
|
+---- Pods
|
+---- My Application
The easiest way for me to remember it is:
Worker nodes are where my workloads actually run.
2. Control Plane: The Brain of the Cluster
If worker nodes run my applications, the control plane manages the cluster.
The control plane is responsible for managing worker nodes and Pods.
It contains several important components.
Let’s simplify them.
API Server
The API server is the front door of Kubernetes.
It exposes the Kubernetes API that other components and tools use to interact with the cluster.
When I eventually use a tool like kubectl, I'm interacting with Kubernetes through this API.
So I think of it as:
The API Server = the front door of my Kubernetes cluster.
etcd
etcd is the persistence store for Kubernetes.
It stores important cluster data and state.
My simple mental model is:
etcd remembers what Kubernetes knows about the cluster.
Scheduler
The scheduler decides where newly created Pods should run.
If a Pod hasn’t been assigned to a node, the scheduler evaluates the available nodes and selects one.
So I think of the scheduler as:
The component responsible for deciding where a workload should run.
Controller Manager
The controller manager contains several controllers that continuously watch the cluster and respond to changes.
There are controllers responsible for things such as nodes, Jobs, endpoints, service accounts, and more.
I don’t think you need to memorize every controller when you’re just getting started.
The important concept is:
Kubernetes continuously watches the system and tries to make the actual state match the desired state.
That idea becomes extremely important as you go deeper into Kubernetes.
And Then AWS Enters the Picture
Once I understood the basic Kubernetes architecture, the next question for me was:
Who is going to operate all of this?
If I run Kubernetes myself, I have to worry about setting up and maintaining the control plane.
That means thinking about availability, upgrades, infrastructure, networking, security, monitoring, and maintenance.
That’s a lot of operational responsibility.
And this is where Amazon EKS becomes interesting.
What Is Amazon EKS?
Amazon Elastic Kubernetes Service, or EKS, is AWS’s managed Kubernetes service.
The key idea is:
AWS manages the Kubernetes control plane for me.
Instead of manually installing and operating the Kubernetes control plane myself, I can use EKS and let AWS handle that responsibility.
I like to visualize it this way:
Amazon EKS
|
+-------+-------+
| Control Plane |
| Managed by |
| AWS |
+-------+-------+
|
+-------+-------+
| |
Worker Node Worker Node
| |
Pods Pods
This immediately makes EKS easier to understand.
I’m still using Kubernetes.
But I don’t have to think about operating the entire Kubernetes control plane myself.
How I Think About Creating an EKS Cluster
When I create an EKS cluster, I don’t think:
“Which AWS console button do I click next?”
Instead, I think:
“What does my Kubernetes cluster need in order to work?”
That leads me naturally to a few important areas:
- Cluster configuration
- IAM
- Networking
- API access
- Kubernetes add-ons
- Logging
- Worker nodes
- Scaling
Once I think about it this way, the AWS configuration starts making much more sense.
Step 1: Create the EKS Cluster
The first thing I need is the EKS cluster itself.
When creating it, I need to think about things such as:
- Cluster name
- Kubernetes version
- IAM role
- Networking
- API endpoint access
- Add-ons
- Logging
These aren’t random configuration options.
Each one maps back to a part of the architecture.
That’s why I strongly recommend understanding the architecture before getting lost in the AWS console.
Step 2: Give EKS the Right IAM Permissions
AWS services need permission to interact with AWS resources.
So the EKS control plane needs an IAM role that allows it to perform the AWS actions it needs.
I think about this role as:
EKS Control Plane
|
v
IAM Cluster Role
|
v
AWS Resource Permissions
The important question I ask is:
What is this component actually allowed to do?
IAM isn’t just something I configure because AWS asks me to.
It’s part of the security model of my infrastructure.
Step 3: Configure the VPC and Subnets
Next comes networking.
My EKS cluster needs a network environment.
That’s where the AWS VPC and subnets come in.
The important thing for me to understand is:
Kubernetes doesn’t exist in isolation when I run it on AWS.
It needs to integrate with AWS networking.
So I need to think about where my resources live and how they communicate.
A simplified view looks like this:
AWS VPC
|
+--------+--------+
| |
Subnet Subnet
| |
Worker Node Worker Node
| |
Pods Pods
This mental model becomes increasingly important when I start working with production architectures.
Step 4: Decide How My Kubernetes API Can Be Accessed
This is one of the configuration decisions I pay particular attention to.
The Kubernetes API endpoint can be configured for:
- Public access
- Public + private access
- Private access
With public access, the endpoint can be reached from outside the VPC.
With public + private access, external access remains available while worker-node traffic to the endpoint can stay within the VPC.
With private access, the endpoint is accessible only within the VPC.
When I need to connect to the cluster from my local machine during initial setup, public + private access can be useful.
But for production, I always want to ask:
Who actually needs access to my Kubernetes API, and from where?
That’s a security question — not just a configuration question.
I can also restrict access to specific IP addresses rather than leaving the endpoint open to everyone.
Step 5: Understand the Kubernetes Add-ons
There are also several components that provide important networking and service functionality.
Three important ones are:
VPC CNI
Provides Pod networking within the cluster.
CoreDNS
Provides service discovery.
kube-proxy
Provides service networking.
I find it easier to understand these when I focus on the problem each one solves:
Kubernetes Workloads
|
+---------+---------+
| | |
CNI CoreDNS kube-proxy
| | |
Network Discovery Services
Now I’m not just memorizing three names.
I’m connecting each name to a responsibility.
Step 6: Think About Logging Before Production
EKS can send control-plane logs to CloudWatch Logs.
When I’m working on a simple learning environment, I may not need every log enabled.
But when I’m thinking about production, observability becomes much more important.
I like asking myself:
If something breaks at 2 AM, what information will I wish I had?
That question changes how I think about logging.
A system isn’t production-ready just because it works.
I also need to be able to understand what happened when it doesn’t work.
Step 7: Add Worker Nodes
At this point, I have an EKS control plane.
But there’s a very important question:
Where will my application actually run?
The answer is:
Worker nodes.
With EKS, worker machines can be organized into node groups.
A node group is essentially a collection of EC2 instances, and an EKS cluster can have multiple node groups.
I visualize it like this:
EKS Cluster
|
+---- Node Group
|
+---- EC2 Instance
|
+---- EC2 Instance
|
+---- EC2 Instance
My Pods eventually run on these worker machines.
Step 8: Give the Worker Nodes Their Own IAM Role
Here’s something that confused me initially:
“If the cluster already has an IAM role, why do the worker nodes need another one?”
Because they have different responsibilities.
The control plane and worker nodes don’t need identical permissions.
The worker-node role needs permissions related to things such as:
- EKS worker-node functionality
- VPC CNI networking
- Pulling container images from ECR
The relevant policies described in the source are the Amazon EKS CNI Policy, Amazon EKS Worker Node Policy, and Amazon EC2 Container Registry Read Only Policy.
So I think about IAM like this:
Control Plane
|
+---- Cluster IAM Role
Worker Nodes
|
+---- Node IAM Role
|
+---- EKS permissions
+---- CNI permissions
+---- ECR pull permissions
Different component.
Different responsibility.
Different permissions.
That’s a much better mental model than thinking about IAM as one giant role for the entire cluster.
Step 9: Choose the Worker Machine
Now I need to decide what kind of EC2 instances I want to use for my worker nodes.
This is where I consider things like:
- CPU
- Memory
- Network requirements
- Storage
- Cost
- Workload requirements
I also need to think about On-Demand vs Spot capacity.
Spot instances can be cheaper, but they can also be interrupted.
For workloads where stability is more important, On-Demand capacity can be the safer choice.
The important lesson for me is:
I shouldn’t blindly copy an instance type from someone else’s tutorial.
My infrastructure should be based on my workload.
A small development API and a production machine-learning workload obviously don’t have the same requirements.
Step 10: Configure Node Scaling
Now we get to one of the most useful parts of the architecture: scaling.
When I configure a node group, I need to think about three numbers:
Minimum
The smallest number of nodes the group should have.
Maximum
The largest number of nodes the group can scale to.
Desired
The number of nodes I want running right now.
For example:
Minimum: 1
Desired: 1
Maximum: 2
This means I start with one node, but my node group is allowed to grow to two nodes.
I visualize it like this:
Maximum
2
|
+----+----+
| |
Node 1 Node 2
|
Desired
1
|
Minimum
1
Once I see it visually, the three values become much easier to understand.
Step 11: Let the Worker Nodes Join the Cluster
After creating the node group, AWS provisions the EC2 instances.
Once the node group becomes active, the worker nodes become available to run Kubernetes workloads.
Now my architecture finally looks like this:
AWS
|
Amazon EKS
|
+-----------+-----------+
| |
Control Plane Node Group
Managed by AWS |
+----+----+
| |
EC2 EC2
| |
Pods Pods
At this point, I have the foundation I need to start running applications.
Scaling the Worker Nodes
Now let’s imagine my application needs more capacity.
I start with:
Desired = 1
Then I increase it:
Desired = 2
AWS can respond by launching another EC2 instance.
The underlying Auto Scaling Group reflects that infrastructure change as another instance is launched.
So I can think about the process like this:
Before
+---------+
| Worker |
| Node 1 |
+---------+
Scale Up
After
+---------+ +---------+
| Worker | | Worker |
| Node 1 | | Node 2 |
+---------+ +---------+
I’ve now increased the available worker capacity.
And Scaling Down Works Too
Scaling isn’t only about adding machines.
I can also reduce capacity.
For example, if I configure:
Minimum = 0
Desired = 0
the EC2 instances can be terminated as the node group scales down.
So the basic idea becomes:
1 Node
|
| Scale Up
v
2 Nodes
|
| Scale Down
v
0 Nodes
This is the foundation of scalable infrastructure.
The Mental Model I Want You to Remember
If you’re learning Kubernetes, I don’t want you to memorize hundreds of terms.
Start here:
KUBERNETES
|
+----------+----------+
| |
CONTROL PLANE WORKER NODES
"Makes decisions" "Runs workloads"
| |
+-----+------+ +---+---+
| | | | |
API etcd Scheduler Pods Pods
Then add AWS:
AWS
|
EKS
|
+---------+---------+
| |
Control Plane Worker Nodes
Managed by AWS EC2 / Node Groups
| |
+---------+---------+
|
Pods
|
Applications
Then add the supporting infrastructure:
AWS
|
+-----------+-----------+
| |
EKS IAM
| |
+-------+-------+ Permissions
| |
Control Plane Node Groups
| |
| EC2
| |
+-------+-------+
|
Networking
|
VPC / Subnets
|
CNI / DNS / Proxy
When I started thinking about Kubernetes this way, the architecture stopped looking like a giant collection of unrelated components.
Everything started having a purpose.
The 5 Things I Want You to Remember
1. Kubernetes orchestrates containers
Kubernetes isn’t just about running a container.
It’s about managing containerized workloads across infrastructure.
2. The control plane is the brain
The control plane manages the cluster and makes decisions.
Worker nodes execute the workloads.
The simplest way I remember it is:
Control plane = decisions.
Worker nodes = execution.
3. EKS manages the Kubernetes control plane
One of the main reasons I would consider EKS is that AWS manages the Kubernetes control plane for me.
That removes a significant operational responsibility while still giving me Kubernetes.
4. IAM and networking are first-class concerns
When I use Kubernetes on AWS, I’m not learning Kubernetes in isolation.
I’m learning how Kubernetes integrates with AWS.
That means IAM, VPCs, subnets, ECR, networking, and observability all matter.
5. Don’t learn Kubernetes by memorizing commands
This is probably the biggest lesson I want to share.
I don’t want to start my Kubernetes journey by blindly memorizing:
kubectl get pods
kubectl get nodes
kubectl describe pod
Instead, I want to understand:
Why does this command exist?
I don’t want to memorize:
“There is an API server.”
I want to understand:
“The API server provides a way for tools and components to interact with the cluster.”
I don’t want to memorize:
“There is a scheduler.”
I want to understand:
“Something needs to decide which worker node should run a Pod.”
Once I understand why, the terminology becomes much easier to remember.
Final Takeaway
Kubernetes looks complicated because we’re often introduced to it as a giant collection of components.
I think there’s a better way to learn it.
Start with the architecture.
Start with two questions:
Who makes the decisions?
→ The control plane.
Who runs the workloads?
→ The worker nodes.
Then ask:
Who manages the control plane?
→ With EKS, AWS.
How do the components communicate?
→ Through Kubernetes and AWS networking.
What gives components permission to interact with AWS?
→ IAM roles and policies.
Where do the workloads actually run?
→ On worker nodes.
How can I add or remove capacity?
→ Through node-group scaling.
Once I have this mental model, Kubernetes stops looking like a wall of unfamiliar terminology.
It becomes a system where every component has a job.
And that’s the point I want to leave you with:
Don’t learn Kubernetes by memorizing the architecture. Learn the architecture, and the terminology will start making sense.
My next step after understanding this foundation would be to connect to the EKS cluster from my local machine using kubectl and deploy an actual application onto it. That's where the theory starts becoming real.
If you’re learning Kubernetes right now, I hope this mental model saves you some of the confusion I had when I first started exploring it.
Build the mental model first. Learn the commands second.