If you have been following along and building your own applications, you have probably noticed a growing problem: YAML fatigue.

To deploy a simple full-stack application, you need a Deployment, a Service, an Ingress, maybe a ConfigMap, a Secret, and a HorizontalPodAutoscaler. That is easily 300+ lines of raw YAML. Worse, if you want to deploy that exact same application to three different environments (Dev, Staging, and Production), you either have to copy-paste those 300 lines three times, or write complex bash scripts to inject different environment variables.

There has to be a better way. Enter Helm, the package manager for Kubernetes. Today, in the final part of our series, we are going to learn how to tame the YAML beast, package our applications logically, and deploy them like professionals.

1. What is Helm?

If you use a Mac, you probably use Homebrew (brew install node). If you use Ubuntu, you use APT (apt install nginx). Helm is the exact same concept, but for Kubernetes.

Helm allows you to bundle all of your scattered Kubernetes YAML files into a single, logical, version-controlled package called a Helm Chart.

Instead of running:

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl apply -f ingress.yaml

You simply run:

helm install my-app ./my-app-chart

Helm takes your chart, renders the final YAML, and sends it to the Kubernetes API server all at once.

2. The Core Concept: Templating

The real power of Helm is not just grouping files together; it is templating. Helm uses the Go templating engine to inject dynamic variables into your otherwise static YAML manifests.

When you generate a new Helm chart (using helm create my-app), Helm builds a specific directory structure:

my-app/
  Chart.yaml          # Metadata about the chart (name, version)
  values.yaml         # The default variables for your templates
  templates/          # The actual YAML files containing Go templates

How Templating Works

Let's look at a raw Kubernetes Service YAML:

apiVersion: v1
kind: Service
metadata:
  name: frontend-service
spec:
  type: ClusterIP
  ports:
    - port: 80

If we want to make this dynamic, we move it into the templates/ folder and replace the hardcoded values with Helm variables (which are wrapped in {{ }}):

# templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}-service
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}

Where do those values come from? They come from the values.yaml file at the root of your chart:

# values.yaml
service:
  type: ClusterIP
  port: 80

When you run helm install, Helm merges the values.yaml with the templates, compiles the final valid Kubernetes YAML, and deploys it.

3. The Multi-Environment Superpower

Why is templating so valuable? Because it completely solves the multi-environment problem.

You keep one set of templates, but you create different values files for different environments.

For example, you might create a values-prod.yaml:

# values-prod.yaml
replicaCount: 10
service:
  type: LoadBalancer
image:
  tag: "v2.0.0"

And a values-dev.yaml:

# values-dev.yaml
replicaCount: 1
service:
  type: NodePort
image:
  tag: "latest-dev"

To deploy to production, you just pass the specific values file to the Helm command:

helm install my-app ./my-app-chart -f values-prod.yaml

You have successfully decoupled your application's structure (the templates) from its environment data (the values).

4. Releases and Rollbacks

If you deploy raw YAML with kubectl apply, Kubernetes just blindly updates the state. If you make a mistake and break production, how do you undo it? You have to manually find the previous YAML file and re-apply it.

Helm solves this with Releases. Every time you install or upgrade a chart, Helm creates a tracked Release in the cluster. It remembers exactly what YAML it generated and applied.

If you deploy version 2 of your app and it crashes, rolling back is literally one command:

# See your deployment history
helm history my-app

# Rollback to revision 1
helm rollback my-app 1

Helm instantly reverts every single Kubernetes resource (Deployments, Services, ConfigMaps) back to exactly how they were in revision 1.

5. The Brain of the Package: Chart.yaml

If templates/ holds your structure and values.yaml holds your data, what does Chart.yaml do?

The Chart.yaml file is the identity and metadata of your Helm chart. It tells Helm exactly what it is packaging. When you type helm list to see what is running in your cluster, the information you see comes directly from this file.

A typical Chart.yaml looks like this:

apiVersion: v2 
name: my-frontend-app 
description: A React frontend for our e-commerce platform type: application version: 1.1.0 # The version of this Helm Chart 
appVersion: "2.4.5" # The version of the underlying application code 
dependencies:         # External charts required by your app
  - name: redis
    version: "17.3.14"
    repository: "https://charts.bitnami.com/bitnami"

Why is this file so important?

1. Versioning: Notice there are two versions. appVersion is the version of your actual code (e.g., your Docker image tag like v2.4.5). But version is the version of the Helm Chart itself (e.g., 1.1.0). If you update your Kubernetes Service from a ClusterIP to a NodePort, your application code hasn't changed, but your infrastructure has. You would bump the Chart version to 1.1.1 to track that infrastructure change.

2. Dependencies: If your frontend application cannot run without a Redis cache, you can actually declare Redis as a dependency inside your Chart.yaml. When you install your frontend chart, Helm will automatically go download and install the Redis chart first.

3. Template Injection: Just like you can inject variables from values.yaml, you can also inject metadata from Chart.yaml directly into your templates using {{ .Chart.Name }} or {{ .Chart.Version }}.

6. Helm Chart Best Practices

As you start writing your own charts, the templates can get messy quickly. Here are three industry-standard best practices to keep your charts clean:

1. Use _helpers.tpl for Reusable Logic Never hardcode labels across multiple files. Helm allows you to define reusable snippets of code in a file called _helpers.tpl. You can define a standard set of labels once, and inject them into your Deployment, Service, and Ingress simultaneously.

2. Follow Semantic Versioning strictly Your Chart.yaml has two version fields: version (the version of the Helm chart itself) and appVersion (the version of the Docker image it deploys). Always increment the version using Semantic Versioning (e.g., 1.0.0 to 1.0.1) whenever you change the templates.

3. Never put passwords in values.yaml Values files are meant to be checked into Git. Do not put database passwords or API keys in your values.yaml. Instead, inject them at runtime using CI/CD pipelines:

helm upgrade my-app ./my-app-chart --set database.password=$SECRET_VAR

And with that, we have reached the end of our Kubernetes Fundamentals series!

Thank you for following along on this journey. Reach out to me on Twitter and/or LinkedIn

But there is a massive piece of the puzzle we have ignored until now. When you run kubectl apply -f pod.yaml, how does Kubernetes actually decide which specific server (Worker Node) your application should run on?

In a traditional Virtual Machine world, a sysadmin decides where an application goes. In Kubernetes, this is handled automatically by the kube-scheduler. Today, we are going to dive deep into the brain of Kubernetes. We will explore how the scheduler thinks, how to control where your Pods live using Taints and Affinity, how to bypass the scheduler entirely, and how to automatically scale your infrastructure when traffic spikes.

1. The Core Mechanism: Labels and Selectors

Before we can tell Kubernetes where to place things, we need to understand how Kubernetes identifies things. The entire Kubernetes ecosystem relies on a simple tagging system: Labels and Selectors.

• Labels are key-value pairs attached to objects (like Pods or Nodes).

• Selectors are how other Kubernetes components find those objects.

Here is what that looks like in YAML. We label a Pod, and a Service selects it:

# 1. We label the Pod
apiVersion: v1
kind: Pod
metadata:
  name: my-app
  labels:
    env: production
    tier: frontend
spec:
  containers:
    - name: nginx
      image: nginx
***
# 2. A Service selects the Pod using those labels
apiVersion: v1
kind: Service
metadata:
  name: frontend-service
spec:
  selector:
    env: production
    tier: frontend

Labels and Node Selection

Labels and selectors are also part of scheduling. Nodes can have labels just like Pods, for example disktype=ssd or hardware=gpu.

Kubernetes can use these node labels to decide where a Pod should run. The simplest way is nodeSelector, where a Pod explicitly states, "schedule me only on nodes with this label."

# First, label a node via CLI:
# kubectl label nodes worker-1 disktype=ssd

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  nodeSelector:
    disktype: ssd
  containers:
    - name: nginx
      image: nginx

As we will see later, Node Affinity builds heavily on this exact same concept.

2. The Mental Map: What happens when you create a Pod?

To understand scheduling, you need to understand the exact timeline of a Pod's creation.

1. The Request: You run kubectl apply -f pod.yaml. The API Server validates the YAML and saves the Pod object into the etcd database.

2. The Pending State: At this exact moment, the Pod's configuration contains a field called nodeName which is set to null. Because it has no node, the Pod is marked as Pending.

3. The Scheduler Awakens: The kube-scheduler, which constantly watches the API Server for Pods with no nodeName, spots your Pod and begins its selection process.

4. The Assignment: The Scheduler picks the best Node and updates the Pod's nodeName field in etcd. The Scheduler's job is now done. It does not start the container.

5. The Execution: The kubelet (the agent running on the winning Node) sees that a Pod has been assigned to its machine. The kubelet downloads the container image and starts the application.

6. The Runtime: Health probes and autoscalers take over monitoring the running application.

The golden rule here is: The Scheduler only decides WHERE a Pod goes, not HOW it starts.

3. Inside the Scheduler: The Two-Phase Process

When the Scheduler spots your Pending Pod, it looks at all the available worker nodes in your cluster and runs a two-phase elimination tournament.

Phase 1: Filtering (The Elimination Round)

In this phase, the Scheduler removes any node that physically or logically cannot run the Pod. The most critical filter is Resource Requests.

spec:
  containers:
  - name: my-app
    image: my-app:v1
    resources:
      requests:
        cpu: "500m"      # Half a CPU core
        memory: "512Mi"
      limits:
        cpu: "1000m"     # One full CPU core
        memory: "1Gi"

A Major Gotcha: The Scheduler only looks at requests. Furthermore, it does not look at the actual, physical CPU currently being used on a Node. It looks at the Allocatable Capacity minus the Sum of Requests of all currently scheduled Pods.

If a Node has 4 CPUs, and is running 3 Pods that each request 1 CPU, the Scheduler sees 1 CPU available. Even if those 3 Pods are currently idle and using 0% physical CPU, the Scheduler will absolutely reject a new Pod that requests 2 CPUs. The Node is mathematically eliminated.

In short, requests decide placement, while limits decide runtime boundaries.

Phase 2: Scoring (The Ranking Round)

Once the Scheduler has a list of nodes that survived the filtering phase, it scores them. It assigns points based on built-in rules, such as prioritizing nodes that have the most free resources (to balance the cluster) or prioritizing nodes that already have the required container images downloaded. The Node with the highest score wins the Pod.

4. Deep Dive: Node Affinity (Attracting Pods)

Node Affinity works on top of node labels. In that sense, it is closely related to nodeSelector.

The difference is:

• nodeSelector is the simple form: it requires an exact label match only.

• nodeAffinity is the advanced form: it still uses node labels, but supports operators like In, NotIn, and Exists, and also supports both hard and soft rules.

There are two main types of Node Affinity, mapping perfectly to our two scheduling phases:

1. requiredDuringSchedulingIgnoredDuringExecution (The Hard Rule) Evaluated during the Filtering phase. If a Node doesn't match, it is eliminated.

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - nvme

1. preferredDuringSchedulingIgnoredDuringExecution (The Soft Rule) Evaluated during the Scoring phase. The Scheduler gives extra points to Nodes with matching labels. However, if no perfect nodes are available, the Scheduler will still schedule the Pod elsewhere rather than leaving it Pending.

What does IgnoredDuringExecution mean? Suppose a Pod requires an nvme node and is successfully scheduled there. A week later, an administrator removes the disktype: nvme label from that Node. What happens? Nothing. The rule is ignored during execution. The Pod will continue running happily.

5. Deep Dive: Taints and Tolerations (Repelling Pods)

If Affinity is a magnet that attracts Pods, Taints are a repellent that pushes them away.

Think of a Node as a restricted machine pool. When you add a Taint to that Node (for example, dedicated=gpu:NoSchedule), Kubernetes treats it as protected and avoids placing regular Pods there. Only Pods with the correct Toleration are considered eligible to run on it.

In simple terms: Taint protects the node, and Toleration gives a Pod permission to be placed there.

spec:
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

Where people get confused is the Effect.

1. NoSchedule: "Do not schedule any new Pods here unless they tolerate this taint." Evaluated during the Filtering phase. Edge Case: If you add this taint to a Node already running 50 normal Pods, those 50 Pods will continue to run perfectly fine. Only future deployments will be blocked.

2. PreferNoSchedule: A soft rule. The Scheduler will try its best not to put new Pods on this Node, but if the cluster is completely full, it will bypass the restriction. Evaluated during the Scoring phase.

3. NoExecute (The Dangerous One): This is an aggressive rule used during runtime. If you apply a NoExecute taint to a Node, it blocks new Pods AND immediately evicts any existing running Pods that lack the matching toleration.

Quick Summary: Filtering vs Scoring Map

To keep your mental model clean, here is exactly where each concept fits:

6. Bypassing the Scheduler: Manual and Static Pods

What if you don't want to use the Two-Phase process?

Manual Scheduling You can bypass the Scheduler entirely by hardcoding the nodeName directly in your YAML:

spec:
  nodeName: worker-node-01
  containers:
  - name: my-app
    image: nginx

The API Server skips the Scheduler entirely. The kubelet on worker-node-01 simply sees the assignment and starts the Pod.

Static Pods Static Pods bypass the API Server and the Scheduler entirely. If you SSH into a Worker Node, you will find a specific directory configured in the kubelet (usually /etc/kubernetes/manifests). If you drop a standard Pod YAML file into this folder, the local kubelet detects the file and starts the Pod directly.

What happens if you edit that file? The kubelet continuously watches that directory on the hard drive. If you open pod.yaml in vim and change the image version, the kubelet instantly notices the file modification, cleanly shuts down the running container, and restarts it with the new configuration. If you delete the file, the Pod is killed.

Why does this exist? This is exactly how Kubernetes runs its own control plane! The API Server, Scheduler, and etcd are all run as Static Pods on the master nodes, allowing them to boot up before the Kubernetes API even exists.

7. Runtime: The Kubelet and Health Probes

Once the Pod is placed on a Node, the kubelet takes ownership. To know if your application is actually working, the kubelet relies on Health Probes. (Remember our table: The Scheduler never looks at Health Probes).

spec:
  containers:
  - name: my-app
    image: my-app:v1
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080

1. Liveness Probe ("Is the app dead?") If the app returns an error or times out, the kubelet assumes the container has crashed, kills it, and restarts it.

2. Readiness Probe ("Can it handle traffic?") If this probe fails, the container is not killed. Instead, Kubernetes temporarily removes the Pod's IP address from the Service endpoints. The Edge Case: If your Node.js app loses its connection to the database, a failing Liveness probe would trap your app in an infinite reboot loop. Instead, a failing Readiness probe simply stops user traffic from reaching that Pod, leaving the container running peacefully until the DB comes back online.

3. Startup Probe For legacy applications that take 30 seconds to boot, a strict Liveness probe might kill the app before it ever finishes starting. A Startup probe pauses the other probes until the application successfully boots for the first time.

8. Day 2 Operations: Autoscaling

Now your Pods are healthy, but what happens when traffic spikes by 1000%?

1. Horizontal Pod Autoscaler (HPA) The HPA scales the number of Pod replicas. It watches metrics (like CPU).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: frontend-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: frontend
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

If your Pods hit 80% CPU, the HPA dynamically alters your Deployment from 2 Pods up to 10.

2. Vertical Pod Autoscaler (VPA) The VPA scales the size of your Pods. It analyzes historical usage and adjusts the CPU/Memory requests and limits. The Gotcha: Never use HPA and VPA on the same metric (like CPU). The HPA will try to add more Pods, while the VPA will try to reboot existing Pods with higher limits. They will fight each other, causing massive instability.

3. Cluster Autoscaler (CA) If the HPA requests 20 new Pods but your Worker Nodes are completely out of CPU, those new Pods will sit in Pending. The Cluster Autoscaler watches for Pending Pods and makes API calls to AWS/GCP to spin up brand new Virtual Machines to accommodate them.

The Modern Standard: KEDA

Standard HPA relies heavily on CPU and Memory. But what if you are processing a message queue? Your CPU might be 10%, but you have 10,000 messages waiting in AWS SQS.

Enter KEDA (Kubernetes Event-driven Autoscaling). KEDA can talk directly to external systems like Kafka or AWS SQS.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: aws-sqs-scaler
spec:
  scaleTargetRef:
    name: worker-deployment
  minReplicaCount: 0   # Scale to zero!
  maxReplicaCount: 10
  triggers:
  - type: aws-sqs-queue
    metadata:
      queueURL: https://sqs.us-east-1.amazonaws.com/123/my-queue
      queueLength: "100" # Add 1 Pod for every 100 messages

KEDA translates these external events into metrics the standard HPA can understand, enabling true event-driven, scale-to-zero architectures.

You now understand the complete lifecycle of a workload in Kubernetes. You write declarative YAML. The API server stores it. The Scheduler filters and scores your nodes, respecting your Taints and Affinities. The kubelet takes over, starting your containers and running Health Probes. Finally, components like the HPA and Cluster Autoscaler continuously monitor and adjust the scale of your infrastructure to match reality.

In the next part of this series, we will look at how to package all these complex YAML files into something reusable using Helm, and explore how to manage production-ready configurations and secrets securely.

Hope you found this useful!
Reach out to me on Twitter and/or LinkedIn.

At this point, we have Pods running inside our cluster. But right now, they are completely isolated. The frontend cannot talk to the backend, the backend cannot reach the database, and users on the internet cannot access the application at all.

If you come from a traditional Virtual Machine (VM) or pure Docker background, Kubernetes networking can feel like black magic. Today, we are going to demystify it. By the end of this article, you will understand exactly how traffic flows inside a cluster, how to expose your applications to the world, and how to do it securely and efficiently.

The Foundation: Pod Networking

Before we can connect our applications, we need to understand how the network works at the lowest level. Kubernetes networking is built on a few strict rules. If you understand these, the rest of the system makes sense.

1. Containers in the same Pod (The "Pause" Container)

In standard Docker, every container gets its own isolated network interface and IP address. Kubernetes does things differently. Instead of giving each container an IP, it groups them into a Pod and gives the Pod the IP address.

To make this work, Kubernetes creates a tiny, invisible container called the "pause" container before it starts your actual application. This container does nothing but hold a network namespace open. Your application containers then join this shared space.

Because they share the exact same network stack, if you have a Node.js container and a Redis container in the same Pod, Node.js can connect to Redis simply by calling localhost:6379.

2. Pods on the same Node

Every Pod gets its own cluster-wide unique IP address. Let's say Pod A (10.1.0.2) and Pod B (10.1.0.3) are running on the same physical worker node.

When Pod A wants to talk to Pod B, the traffic flows out of Pod A's virtual ethernet interface, hits a virtual network bridge inside the Linux kernel of that node, and is immediately handed over to Pod B's interface. It is fast, local, and requires no complex routing.

3. Pods on different Nodes (The Overlay Network)

In this scenario, we have two worker nodes sitting on a standard corporate physical network (VLAN/Subnet 192.168.1.0/24).

The Environment:

• Worker Node 1: Physical IP 192.168.1.10 | Pod CIDR 10.1.0.0/24

• Worker Node 2: Physical IP 192.168.1.11 | Pod CIDR 10.2.0.0/24

• Source (Pod A on Node 1): IP 10.1.0.5

• Destination (Pod C on Node 2): IP 10.2.0.5

The Step-by-Step Execution

1. Packet Initiation:

   Pod A (10.1.0.5) generates a network packet. The "Inner Header" lists the Source as 10.1.0.5 and the Destination as 10.2.0.5.

2. Routing Decision (Node 1):

   The packet hits the Virtual Ethernet interface on Node 1. The Container Network Interface (CNI)—such as Flannel or Calico—checks the local routing table. It identifies that the 10.2.0.0/24 range is hosted by Worker Node 2 at physical address 192.168.1.11.

3. Encapsulation (The "Envelope"):

   Since the physical network switches don't know where 10.2.0.5 is, Node 1 wraps the original packet inside a new one (typically using VXLAN or UDP).

   • Outer Source IP: 192.168.1.10 (Node 1)

   • Outer Destination IP: 192.168.1.11 (Node 2)

   • Payload: The original Pod A -> Pod C packet.

4. Physical Transit:

   The physical network equipment (routers/switches) sees a standard packet moving from 192.168.1.10 to 192.168.1.11. It routes this efficiently across the data center.

5. Decapsulation (Node 2):

   Worker Node 2 receives the packet on its physical interface. It recognizes the encapsulation header, strips it off, and reveals the original "Inner" packet destined for 10.2.0.5.

6. Final Delivery:

   Node 2 looks at its local bridge and sees that Pod C is attached to its local interface. It delivers the packet directly to Pod C's network namespace.

The Core Problem: Ephemeral Pods

Now that we know Pods can talk to each other via IP addresses, we run into a major real-world problem.

Let's imagine a standard architecture: a React Frontend talking to a Node.js Backend. In a VM world, you would hardcode the backend server's IP address (like 192.168.1.50) into your frontend code, and it would work forever.

In Kubernetes, Pods are ephemeral. If a Node.js backend Pod crashes, or you deploy a new version, Kubernetes destroys the old Pod and creates a new one. The new Pod will get a completely different, random IP address.

If your frontend is trying to send API requests to 10.1.0.2, and that Pod dies and is replaced by a Pod at 10.2.0.9, your application breaks.

You can never rely on a Pod's IP address. We need a stable networking layer.

The Solution: Kubernetes Services

To solve the changing IP problem, Kubernetes introduces the concept of a Service.

Think of Pods like temporary workers in a call center, and a Service like the company’s main phone number. Workers might quit, change desks, or go on break, but the customer always dials the same 1-800 number, and the call gets routed to whoever is currently available.

A Service gives you a stable virtual IP address, a permanent DNS name, and built-in load balancing across your Pods.

There are four types of Services you need to know.

1. ClusterIP (The Default)

ClusterIP creates a stable, virtual IP address that is only reachable from inside the cluster. This is what you use for internal application-to-application traffic.

apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 3000

When your frontend makes an HTTP request to backend-service on port 80, the Service catches the traffic and load-balances it across whichever backend Pods are currently alive.

2. NodePort (For Local Testing)

If you want to access your application from outside the cluster, you can use a NodePort. A NodePort opens a specific port (between 30000 and 32767) on the actual, physical IP address of every single worker node in your cluster.

  type: NodePort
  ports:
    - port: 80
      targetPort: 3000
      nodePort: 30080

If you visit http://<Node-IP>:30080 in your browser, the node receives the traffic and forwards it to your Pods.

Why NodePort is a bad approach for production: While NodePort is great for quick debugging, you should almost never use it in production. It forces you to manage a messy range of high-number ports. More importantly, it requires you to expose your underlying infrastructure (the node IPs) to external traffic, bypassing standard security firewalls and cloud load balancers.

3. LoadBalancer (The Cloud Way)

To properly expose an application to the internet, you use the LoadBalancer type.

When you deploy a LoadBalancer Service, Kubernetes talks directly to your cloud provider (AWS, GCP, Azure). The cloud provider automatically spins up a physical, external Load Balancer, assigns it a secure public IP address, and wires it up to your cluster. This is the standard way to accept external internet traffic.

4. ExternalName (The DNS Trick)

Suppose your database is not running inside Kubernetes, but is instead a managed service like AWS RDS (mydb.abc123.rds.amazonaws.com). You could hardcode that URL into your application, but if the database URL ever changes, you have to rewrite your code.

Instead, you create an ExternalName service:

apiVersion: v1
kind: Service
metadata:
  name: postgres-db
spec:
  type: ExternalName
  externalName: mydb.abc123.rds.amazonaws.com

This service does no routing and has no IP. It is simply a DNS alias inside the cluster. Your backend application simply connects to postgres-db, and Kubernetes translates that on the fly to the AWS URL.

Note: Where does the database port (like 5432) come from? The port comes from your application code! Your backend says connect("postgres-db", 5432). Kubernetes translates the hostname, but the port stays exactly what your code requested.

Clarifying Ports: port vs targetPort vs nodePort

When writing Service YAML, this is the most common place developers make mistakes. Let's define them clearly:

• targetPort: The port your actual application is running on inside the container (e.g., your Node.js app is listening on 3000).

• port: The port the Service exposes inside the cluster. Other Pods will use this port to talk to the Service. (e.g., setting this to 80 means other apps can just call http://backend-service without typing a port).

• nodePort: The port opened on the physical worker nodes (only used if the Service type is NodePort).

Under the Hood: How Services Actually Work (kube-proxy)

We know Services provide a stable IP, but here is the biggest secret in Kubernetes: A Service is not a real thing.

There is no "Service container" running anywhere. A Service does not have a network interface. A Service's IP address is entirely fake. It exists only as a set of rules programmed into the kernel of your worker nodes.

The component responsible for this is called kube-proxy. Despite its name, kube-proxy is not a traditional proxy like NGINX. It does not sit in the middle and catch traffic. Instead, kube-proxy is an agent that runs on every single node. It watches the Kubernetes API, and whenever a Service is created, it writes iptables or IPVS rules directly into the Linux kernel of its node.

The Packet Flow

Let's trace what happens when Pod A (on Node 1) calls a ClusterIP Service that points to Pod C (on Node 2).

1. The Request: Pod A makes a request to the Service's virtual IP (10.96.0.10).

2. The Kernel Intercepts: The packet leaves Pod A and hits the Linux kernel of Node 1.

3. The Rule Match: The rules created by kube-proxy immediately spot the destination IP (10.96.0.10).

4. DNAT (Destination NAT): The kernel mathematically picks a healthy backend Pod (Pod C). It then rewrites the packet's destination IP, changing it from the fake Service IP to the real IP of Pod C (10.2.0.5).

5. Normal Routing: Now that the packet has a real Pod IP, it leaves Node 1, travels across the network to Node 2, and is delivered to Pod C.

The critical takeaway: The decision of which Pod to send the traffic to, and the rewriting of the IP address, happens entirely on the source node (Node 1). By the time the packet reaches Node 2, it is just a normal packet aimed at a normal Pod.

Exposing to the World: Ingress vs LoadBalancer

We know that LoadBalancer Services expose applications to the internet. But what if you have a microservices architecture with a Frontend UI, a User API, and a Payment API?

If you use LoadBalancer Services, AWS will create three separate external load balancers. You will have three separate public IP addresses, and you will pay the monthly fee for all three. Furthermore, standard Load Balancers operate at Layer 4 (TCP). They do not understand HTTP URLs. You cannot tell an AWS Load Balancer to route /api to one place and /frontend to another.

Enter Ingress: The Smart Router

To solve this, Kubernetes provides the Ingress.

An Ingress operates at Layer 7 (HTTP/HTTPS). Instead of creating a LoadBalancer for every single microservice, you deploy one single Ingress Controller (usually an NGINX proxy) and expose it via one LoadBalancer Service.

You then write Ingress rules to organize your traffic based on URLs:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  rules:
    - host: myapp.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-service
                port:
                  number: 80
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: backend-service
                port:
                  number: 80

By using an Ingress, your traffic flow becomes highly efficient:

1. Massive Cost Savings: You only pay for one cloud Load Balancer.

2. Smart Routing: Traffic to myapp.com/api goes to the backend, and / goes to the frontend.

3. Centralized SSL: You can attach your SSL/TLS certificates directly to the Ingress, meaning your internal Pods can communicate over simple HTTP without worrying about encryption overhead.

A LoadBalancer opens a door to your cluster. An Ingress stands right inside that door, reads the URL of every request, and smartly routes it to the correct internal Service.

You now have a complete mental model of Kubernetes networking. You know that Pods share network namespaces via the pause container, and that they communicate across a flat, NAT-free network. You know how kube-proxy translates fake Service IPs into real Pod IPs directly in the kernel. And you know why Ingress is the industry standard for routing external HTTP traffic.

At this point, we know how to configure our workloads, give them storage, and connect them to the network. But there is one major piece of the puzzle left: when you deploy a Pod, how does Kubernetes decide which worker node it should actually run on?

In the next part of this series, we will dive into the Kubernetes Scheduler to understand node selection, hardware constraints, and how to control exactly where your applications live.

Hope you found this useful!
Reach out to me on Twitter and/or LinkedIn.

In this part, we’ll move from theory to actual usage. The goal is simpler than that: if you are a developer who needs to work with Kubernetes in a project, this should give you the practical foundation to read configs, understand deployments, and not feel lost when you see a real cluster setup.

Imperative vs Declarative

Before we start creating things in Kubernetes, there’s one important idea to understand: there are generally two ways to work with it.

Imperative way

This is the command-driven approach. You directly tell Kubernetes what to do.

kubectl run my-pod --image=nginx
kubectl create deployment my-app --image=nginx
kubectl scale deployment my-app --replicas=3

This style is quick and useful for testing, debugging, or learning. If you just want to spin something up and see what happens, imperative commands are convenient.

But the downside is that commands are not a great long-term source of truth. Once you run them, the cluster changes, but you do not have a clear config file that documents what your system is supposed to look like.

Declarative way

This is the file-based approach(YAML is the preferred way). Instead of telling Kubernetes step by step what to do, you describe the desired state in a file and apply it.

kubectl apply -f pod.yaml
kubectl apply -f deployment.yaml

That YAML file becomes your source of truth. It can be stored in Git, reviewed by your team, reused in different environments, and updated over time.

In real projects, this is the approach you’ll use most of the time. So from this point onward, we’ll mostly think in the declarative way.

Creating a cluster

Before creating Pods or Deployments, we need a cluster.

In managed cloud platforms, you usually create Kubernetes clusters through a UI, CLI, or infrastructure tools. For example, in AWS, GCP, or Azure, the cloud provider gives you ways to define the cluster and the worker nodes you want. Under the hood, you are still describing the shape of the cluster — just often through provider-specific tools.

For learning locally, one of the easiest options is kind, which stands for Kubernetes in Docker. It lets you create a local multi-node Kubernetes cluster using a YAML file.

Here is a simple example:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker

And then you create it with:

kind create cluster --config kind-config.yaml

This gives you:

• 1 control plane node

• 2 worker nodes

That is enough to simulate a more realistic setup than a single-node cluster.

If you are using a managed Kubernetes platform, the exact YAML and commands will differ, but the idea stays similar: you define the structure you want, and the platform creates the cluster for you.

Understanding Kubernetes YAML

Now let’s talk about the most common thing you’ll see in Kubernetes: YAML files.

Almost every Kubernetes resource is defined using the same broad structure:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: nginx
      image: nginx

At a high level, the main parts are:

apiVersion

This tells Kubernetes which API version should handle this resource.

kind

This tells Kubernetes what you are creating. It could be a Pod, Deployment, Service, ConfigMap, Secret, and so on.

metadata

This contains identifying information such as the resource name, labels, and namespace.

spec

This is the most important section. It describes the desired state of the resource. In other words, this is where you define what you actually want Kubernetes to create and maintain.

Writing your first Pod

The first real workload to understand in Kubernetes is a Pod.

Here is a basic Pod YAML:

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
  labels:
    app: my-app
spec:
  containers:
    - name: my-app-container
      image: nginx:latest
      ports:
        - containerPort: 80

You can create it using:

kubectl apply -f pod.yaml

Then inspect it with:

kubectl get pods
kubectl describe pod my-app-pod

Important parts of a Pod spec

In a real project, some fields you’ll commonly work with are:

• containers: The list of containers inside the Pod.

• image: The container image to run.

• ports: Which ports the container exposes.

• env: Environment variables.

• resources: CPU and memory requests/limits.

• volumeMounts: Where storage is mounted inside the container.

• volumes: Storage definitions used by the Pod.

A slightly more realistic example:

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
  labels:
    app: app-pod
spec:
  containers:
    - name: app-container
      image: nginx:latest
      ports:
        - containerPort: 80
      env:
        - name: APP_ENV
          value: "development"
      resources:
        requests:
          cpu: "100m"
          memory: "128Mi"
        limits:
          cpu: "250m"
          memory: "256Mi"

At this point, you do not need to master every field. The main thing is to start recognizing the structure and understand that a Pod spec is just a description of how a containerized workload should run.

Why a plain Pod is not enough

A Pod is fine for learning, testing, or one-off workloads.

But in real applications, a plain Pod has a problem: if that Pod dies, Kubernetes does not automatically guarantee that a new identical one will continue running just because you wanted one. That is where higher-level controllers come in.

And that leads us to ReplicaSets.

Why ReplicaSets exist

A ReplicaSet exists to make sure a certain number of Pod replicas are always running.

If you say you want 3 Pods, the ReplicaSet keeps checking the cluster and tries to maintain exactly 3. If one crashes or gets deleted, it creates another one.

Here is a simple ReplicaSet:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-app-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: nginx-container
          image: nginx:latest
          ports:
            - containerPort: 80

A few important things to notice here:

• replicas: 3 means Kubernetes should keep 3 Pods running.

• selector.matchLabels tells the ReplicaSet which Pods belong to it.

• template contains the Pod definition that should be created.

That template section is basically a Pod spec embedded inside another resource.

What actually happens

Suppose one of the Pods managed by this ReplicaSet gets deleted.

The ReplicaSet notices that the actual number of running Pods is now lower than the desired number. So it creates a new Pod to fix that mismatch.

Deployments

A Deployment sits one level above ReplicaSets.

It manages ReplicaSets for you and gives you better control over updates, rollbacks, and rollout history. If ReplicaSet is about “keep these Pods alive,” Deployment is about “manage this application properly over time.”

Here’s a basic Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
        - name: app
          image: nginx:1.25
          ports:
            - containerPort: 80

If later you change the image version:

image: nginx:1.26

and apply the file again, Kubernetes performs a rolling update. Instead of killing all old Pods at once and creating all new ones at once, it gradually replaces them so the application keeps running during the update.

Useful commands here are:

kubectl apply -f deployment.yaml
kubectl get deployments
kubectl rollout status deployment/app-deployment
kubectl rollout history deployment/app-deployment
kubectl rollout undo deployment/app-deployment

This is why Deployments are the standard way to run stateless applications in Kubernetes. They give you scaling, self-healing, and controlled updates in one place.

DaemonSets

A DaemonSet is different from a Deployment.

A Deployment runs a chosen number of replicas, but a DaemonSet ensures that a specific Pod runs on every matching node. If a new node joins the cluster, Kubernetes automatically creates that Pod there too.

This is useful for workloads that should exist once per node rather than a fixed number across the cluster.

Common examples include:

• Log collection agents.

• Monitoring agents.

• Node-level security tools.

• Network-related agents.

A simple DaemonSet looks like this:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-agent
spec:
  selector:
    matchLabels:
      app: node-agent
  template:
    metadata:
      labels:
        app: node-agent
    spec:
      containers:
        - name: agent
          image: nginx:latest

So the easiest way to remember it is:

• Deployment: “Run 3 copies of this app.”

• DaemonSet: “Run 1 copy of this app on every node.”

Storage and persistence

Why volumes matter

Containers are meant to be lightweight and replaceable. That is great for scaling and recovery, but it creates an important problem: data written inside the container filesystem is usually lost if the container is recreated.

That means if your application uploads files, stores local state, or depends on persistent data, you need a better storage model.

This is where volumes come in.

Basic volume types

To use storage in Kubernetes, it is always a two-step process:

1. You define the storage at the Pod level (using volumes).

2. You plug that storage into your container at a specific folder path (using volumeMounts).

One basic example is emptyDir:

apiVersion: v1
kind: Pod
metadata:
  name: volume-demo
spec:
  containers:
    - name: app
      image: nginx
      volumeMounts:
        - name: temp-storage
          mountPath: /usr/share/nginx/html
  volumes:
    - name: temp-storage
      emptyDir: {}

If you look closely at the YAML, the volumes section at the bottom tells Kubernetes: "Create a temporary empty directory and name it temp-storage."

Then, the volumeMounts section inside the container tells Kubernetes: *"*Take that temp-storage volume we just created and make it accessible inside this container at the path /usr/share/nginx/html."

An emptyDir is created when the Pod starts and exists only as long as the Pod exists. It is useful for temporary scratch space or sharing files between multiple containers in the same Pod, but it is not meant for persistent application data.

Another option is hostPath, which mounts a directory directly from the underlying worker node's filesystem:

volumes:
  - name: host-storage
    hostPath:
      path: /data/app
      type: DirectoryOrCreate #Look for this folder path on the node. If it already exists, use it. If it does not exist, create an empty directory at that path first, and then use it.

This can be useful in local development setups (like kind or Minikube) or for debugging, but it is usually not the right choice for production applications because it permanently ties your Pod's data to one specific physical node.

Persistent Volumes and Persistent Volume Claims

For real persistence, Kubernetes uses Persistent Volumes (PV) and Persistent Volume Claims (PVC).

The easiest way to think about them is this:

• A Persistent Volume is the actual storage resource.

• A Persistent Volume Claim is a request for storage made by an application.

Your Pod does not usually ask for a disk directly. Instead, it asks for a PVC, and that PVC gets bound to a PV.

Here’s a simple PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

And here’s how a Pod uses it:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-storage
spec:
  containers:
    - name: app
      image: nginx
      volumeMounts:
        - name: app-storage
          mountPath: /data
  volumes:
    - name: app-storage
      persistentVolumeClaim:
        claimName: app-pvc

Now the Pod is using persistent storage through the claim.

Access modes

When working with persistent storage, you’ll often see these access modes:

• ReadWriteOnce (RWO) — mounted as read-write by a single node.

• ReadOnlyMany (ROX) — mounted as read-only by many nodes.

• ReadWriteMany (RWX) — mounted as read-write by many nodes.

These matter because not all storage backends support all modes. Think about Amazon EBS (Elastic Block Store). An EBS volume is essentially a virtual hard drive. Just like you cannot plug a single physical USB hard drive into three different laptops at the exact same time, AWS physically does not allow a standard EBS volume to be plugged into multiple EC2 instances (worker nodes) at once. Because of this hardware/cloud limitation, Kubernetes can only offer ReadWriteOnce (RWO) for EBS.

On the other hand, think about Amazon EFS (Elastic File System). EFS is a network file system (like a shared Google Drive or a shared folder on a Wi-Fi network). It is specifically designed to be accessed over the network by hundreds of computers simultaneously. Because the underlying cloud technology supports multiple connections, Kubernetes can offer ReadWriteMany (RWX) for EFS.

Persistent Volumes (PVs) and Reclaim Policies

While modern Kubernetes handles storage automatically, it is important to understand how the underlying Persistent Volume (PV) actually works.

Historically (and sometimes still today), setting up storage was a manual process. A cluster administrator would go into AWS, manually create a 10GB EBS volume, and then write a PV YAML file to tell Kubernetes that this disk exists.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: manual-ebs-vol
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  awsElasticBlockStore:
    volumeID: vol-0abcd123456789
    fsType: ext4
  persistentVolumeReclaimPolicy: Retain

When your Pod creates a PVC (the claim), Kubernetes looks at all the available manual PVs and tries to find a match.

But what happens when your application is deleted and the PVC is destroyed? Does the data stay or get deleted? That is controlled by the Reclaim Policy inside the PV:

• Retain: The PVC is deleted, but the PV and the actual physical disk (and its data) are kept. The volume is considered "released," but no other claim can use it until an administrator manually cleans it up. This is the safest option for critical databases.

• Delete: When the PVC is deleted, Kubernetes automatically deletes the PV and tells the cloud provider to delete the underlying disk (like the AWS EBS volume). The data is permanently gone.

• Recycle: (Mostly deprecated now) This keeps the PV but runs a basic scrub command (rm -rf /volume/*) to wipe the data so a new PVC can claim it.

The problem with manual PVs

Imagine a simple use case: You are a developer deploying a new database, and your PVC asks for 15GB of storage.

If your administrator only pre-created PVs that are 10GB and 50GB, your claim won't fit the 10GB one. Kubernetes might bind you to the 50GB PV instead, wasting 35GB of expensive cloud storage. Or worse, if there are no available PVs left, your Pod will be stuck in a Pending state while you wait for an IT ticket to be resolved so someone can manually provision a new disk.

This manual matching game—guessing how much storage developers will need and pre-creating disks—does not scale well in the cloud.

This exact bottleneck is why modern Kubernetes setups use dynamic provisioning via a StorageClass.

(...and then you transition right into your already-written StorageClass section!)

StorageClass and dynamic provisioning

In modern Kubernetes setups, you usually do not create Persistent Volumes manually. Instead, you use a StorageClass and let Kubernetes dynamically provision the storage when a PVC is created.

Here’s an example StorageClass for AWS EBS:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: gp3

Then your PVC can reference it:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ebs-sc
  resources:
    requests:
      storage: 10Gi

When this PVC is used by a Pod, Kubernetes works with the storage backend to create the actual volume.

This is called dynamic provisioning. It is much more practical than pre-creating every disk manually.

EBS, EFS, and S3

If you are deploying on AWS, the common storage options usually map like this:

EBS
Best for block storage attached to one node at a time. Good for databases or workloads where a Pod needs a dedicated disk. Usually works with ReadWriteOnce.

EFS
Best for shared file storage across multiple nodes and Pods. Useful when many Pods need to read and write the same files. Often used with ReadWriteMany.

S3
This is object storage, not a normal filesystem volume in the same way as EBS or EFS. In most application setups, you do not mount S3 like a regular disk. Instead, the app talks to S3 using an SDK or API. For things like user uploads, backups, images, or documents, this is often the better design.

A simple way to decide is:

• Need one disk for one workload? Use EBS.

• Need shared file access across Pods? Use EFS.

• Need object storage for files and assets? Use S3.

For most application developers, just understanding this difference already saves a lot of confusion.

Config and secrets

ConfigMaps

Applications usually need configuration: environment names, feature flags, URLs, ports, or non-sensitive settings.

You could hardcode those values in the image, but that makes deployments rigid and hard to change. A better approach is to keep the configuration outside the image.

That is where ConfigMaps come in.

Example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  NODE_ENV: "production"
  APP_NAME: "my-service"

You can consume this in a Pod as environment variables:

apiVersion: v1
kind: Pod
metadata:
  name: config-demo
spec:
  containers:
    - name: app
      image: nginx
      envFrom:
        - configMapRef:
            name: app-config

Secrets (and why you shouldn't write them in YAML)

Secrets are used for sensitive data like database passwords, API keys, and private credentials.

Normally, a basic Kubernetes Secret looks like this:

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
stringData:
  DB_PASSWORD: myStrongPassword

This is better than hardcoding passwords directly in your application code, but it introduces a massive problem for real-world projects: How do you store this YAML file?

If you commit this to Git, your password is out in the open. Even if you use Kubernetes' default base64 encoding instead of stringData, base64 is just encoding, not encryption. Anyone who can read your repository can decode your passwords in seconds.

The Best Practice: External Secrets Operator

In modern, real-world systems, the standard best practice is to never store secrets in Kubernetes YAML at all. Instead, you store them in a secure vault (like AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault) and use a tool called the External Secrets Operator (ESO) to bridge the gap.

Here is how the flow actually works:

1. You put your real secrets inside AWS Secrets Manager.

2. You write an ExternalSecret YAML file that simply points to AWS.

3. The operator securely fetches the values from AWS and dynamically creates a native Kubernetes Secret inside the cluster for you.

Here is what your ExternalSecret YAML looks like:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-external-secret
spec:
  refreshInterval: "1h"
  secretStoreRef:
    name: aws-secrets-manager # Points to your AWS config
    kind: ClusterSecretStore
  target:
    name: app-secret-generated # The name of the Kubernetes Secret it will create!
  dataFrom:
    - extract:
        key: production/database/credentials # The exact path in AWS Secrets Manager

Notice that there are no actual passwords in this file. It is completely safe to commit this to your Git repository.

Consuming the Secret in your Pod

Once the External Secrets Operator does its magic, it creates a normal Kubernetes Secret named app-secret-generated in your cluster.

Now, just like we did with ConfigMaps, the cleanest way to inject this into your Pod is to reference the whole thing at once using envFrom and secretRef:

apiVersion: v1
kind: Pod
metadata:
  name: secret-demo
spec:
  containers:
    - name: app
      image: nginx
      envFrom:
        - secretRef:
            name: app-secret-generated # Pulling in the auto-created secret

By combining External Secrets with the envFrom pattern, you achieve the ultimate setup:

• Your Git repositories are completely free of hardcoded passwords.

• You can centrally manage and rotate secrets in AWS.

• Your Kubernetes Deployment YAML stays incredibly short, clean, and secure.

With this, we move from just understanding Kubernetes to actually working with it.

In this part, we started with YAML, looked at how resources are declared, created a Pod, understood why ReplicaSets and Deployments exist, touched on DaemonSets, and then went deeper into storage, configuration, and secrets. These are the things that make Kubernetes feel practical rather than abstract.

In the next part of this series, we’ll move into another major piece of the puzzle: how applications running inside the cluster actually communicate with each other and how traffic reaches them from the outside world.

Hope you found this useful.
Reach out to me on Twitter and/or LinkedIn.

Recently, though, my project demanded it. So this time, I couldn’t back out — I had to get it working. While figuring things out (with a mix of trial, docs, and a bit of help from AI), I finally started to see how it all fits together. This blog series is me sharing that journey. It’s not a full Kubernetes course, but a simple and practical guide that focuses on the fundamentals — enough for any developer to feel comfortable working on projects deployed with Kubernetes.

Why and What?

Imagine an application made up of multiple Docker containers running across multiple servers. In such a setup, you need capabilities like monitoring containers, load balancing traffic between them, automatically restarting failed containers, scaling based on CPU or memory usage, and performing deployments with zero downtime.

While all of this can technically be achieved using manual scripts and cloud provider services, these are common challenges in distributed systems. Kubernetes was introduced to solve these problems in a standardized way, allowing developers to declare the desired state of the system, while Kubernetes handles how to achieve and maintain that state.

Why Containers?

Kubernetes uses containers because they package the application along with all its dependencies, so the same application can run reliably across different machines without environment issues. Containers also start quickly, which makes scaling and recovery faster when traffic increases or failures happen. Multiple containers can run on the same machine without needing separate operating systems, which reduces resource usage and cost.

If Kubernetes were to use raw machines or full virtual machines, each deployment would require setting up and maintaining separate environments, startup times would be slower, scaling would take longer, and overall infrastructure management would become more complex and expensive.

Why Not?

Kubernetes helps applications handle scaling and failures automatically. But it is harder to use because your system is split into many components, like clusters, nodes, and services that all need to work together. It can increase engineering costs because it requires people who understand how to design and manage this system properly.

It also adds extra operational effort because instead of managing a single application on a server, you are managing a whole platform where many applications run together and depend on each other. This makes the system more complex to reason about and operate, especially for small teams that do not need large-scale infrastructure.

Architecture

In order to understand the architecture of k8's, we need to first learn about a few building blocks of k8's shown in the image

Components of k8's

Pod

A Pod in Kubernetes is the smallest unit of deployment. It can contain one or more containers that run together on the same node. A Pod acts as a wrapper around these containers and provides a shared environment/resources for them. Kubernetes uses Pods as the basic unit to schedule, monitor, restart, and manage application workloads in a consistent way.

Node

A node is nothing but a server, a physical server, or a virtual machine, like an EC2. In Kubernetes, there are two types of nodes

• Control Plane / Master Node

• Worker Node

Control Plane / Master Node

They are special nodes of k8s that are responsible for managing the worker nodes, storing information regarding pods and nodes, taking requests from clients, and performing them

Worker Nodes

They are the nodes running your application containers inside pods

Cluster

The complete system of control plane nodes and worker nodes is called a k8s cluster.

kubectl

This is the command-line tool (the “Kubernetes client”) you use to interact with your cluster. Whenever you run commands like creating a pod or checking the status of a deployment, kubectl sends those requests to the Kubernetes system.

API Server

The API Server is like the brain’s messenger. It receives your requests from kubectl, processes them, and then passes the right instructions to different parts of the cluster. It also talks to other control plane components to keep everything in sync.

Scheduler

When you ask Kubernetes to create a Pod, the Scheduler decides which worker node the Pod should run on. It looks at available resources on each node and picks the one that fits best.

Controller Manager

Think of this as the system’s caretaker. The Controller Manager constantly watches what’s happening in the cluster. If something isn’t how it’s supposed to be — like a crashed Pod or a missing node — it takes action to fix it and bring the system back to the desired state.

etcd

etcd is a small but crucial part — it’s a key-value database that stores all the cluster’s information, such as configuration data, the state of Pods, and node details. The API Server reads and writes data here to keep track of what the cluster should look like.

Kubelet

Each worker node has a small agent called Kubelet running inside it. It talks to the API Server and makes sure that the containers (Pods) assigned to that node are actually running and healthy.

Kube Proxy

The Kube Proxy handles networking inside each worker node. It makes sure Pods can talk to each other — even across different nodes — and that traffic flows correctly between services and Pods.

Big Picture

Let's understand the flow of how these components combine and work when a simple command like kubectl run my-pod --image=nginx

1. kubectl → API Server

   • kubectl sends a request to the API Server saying “create a Pod called my-pod with this image.”

   • The API Server checks if the request is valid and if you have permission to do it.

2. API Server → etcd (store desired state)

   • The API Server writes a new Pod object into etcd, which now says: “There should be a Pod named my-pod in the cluster.”

3. Scheduler picks a worker node

   • The Scheduler watches the API Server for Pods that do not have a node assigned yet.

   • It sees my-pod, looks at all worker nodes and their resources, and decides: “Run my-pod on worker node A.”

   • It updates that decision through the API Server, which is again stored in etcd.

4. API Server → kubelet on chosen node

   • The kubelet on worker node A regularly talks to the API Server and asks, “What Pods should I be running?”

   • It sees that my-pod is now assigned to its node.

5. kubelet creates the container

   • The kubelet pulls the nginx image (if not already present) and starts the container inside a Pod on that worker node.

   • It then reports status back to the API Server. “my-pod is running.”

6. API Server updates etcd (current state)

   • The API Server writes the current status of my-pod (Pending → Running) into etcd.

   • When you run kubectl get pods, kubectl again talks to the API Server, which reads from etcd and returns the Pod status.

With this, we come to the end of this first Kubernetes fundamentals article, where we set the stage with the “why,” the core concepts, and a clear view of how the cluster is put together.

In the next part of this series, we’ll move from understanding the system to managing real applications on Kubernetes: how workloads are defined, rolled out, updated, and kept running reliably in production.

Hope you found this useful!
Reach out to me on Twitter and/or LinkedIn.