What actually is Kubernetes? 📦

A gentle introduction...

W J Pearce

Aug 24, 2025

Last Week: 2025 AI Roadmap 🛣️

Next Week: You Really Need to Learn GHAS!

This Week: What actually is Kubernetes? 📦

This week is a gentle introduction to Kubernetes.

I’m learning it myself through my day job, and I thought it’d be fun if you followed along with me.

Why bother?

Simple: the industry wants you to know it. Recruiters look for it, and salaries reflect it, even junior roles Kubernetes as a massively desirable skill source.

If you want to get hired faster or negotiate a higher salary, it pays to learn the tools the industry actually uses. Kubernetes is one of them.

What?

Kubernetes (K8s) is one of those buzzwords you hear tons in cloud and DevOps circles. But what actually is it, and why should you learn it?

So yes, you can deploy Docker on an EC2 and get your app up and running pretty rapid but that’s not how companies are doing it… especially at scale.

At its core, Kubernetes is a system that manages and scales your applications automatically. It keeps things running even if a server goes down, spreads workloads across resources, and heals itself when something breaks. Instead of manually fiddling with networking, scaling, and failover, you just tell Kubernetes the state you want and it makes sure what you have running matches.

Clusters and Nodes

The first building block is the cluster. Think of it as the whole Kubernetes system.

A cluster is made up of multiple nodes.
Each node is just a server (physical or virtual) that runs workloads.
If one node fails, Kubernetes moves the work somewhere else.

Inside the cluster we talk about two planes:

Control Plane – the brain of the cluster (stores state, makes decisions).
Data Plane – where your actual applications live and run.

The Control Plane (the brains)

The control plane has a few key parts:

API Server – the front door. All requests go through here.
etcd – the memory, a highly available key value store that records cluster state.
Scheduler – decides which node new workloads should run on.
Controller Manager – enforces state, making sure what’s deployed matches your config (very Terraform like imo).
Cloud Controller Manager (CCM) – connects Kubernetes to your cloud provider.

On each node you’ll also find:

Kubelet – the agent that runs your workloads and checks they’re healthy.
Kube-Proxy – handles networking rules so workloads can talk to each other.

💡 If you’re using a managed cluster (like EKS on AWS, AKS on Azure, or GKE on Google Cloud), most of this is handled for you. You don’t have to build the control plane yourself, but it’s decent to understand what’s going on under the hood.

Pods: the Core Unit

Kubernetes doesn’t just run containers directly, it wraps them in Pods.

A Pod is the smallest deployable unit in Kubernetes.
A Pod can run one or more containers.
Containers inside the same pod share networking and storage.

Example: you could put a web server and a logging process inside the same Pod, so they can talk to each other easily.

Interfaces (the plug and play bits)

Kubernetes is modular. It defines standard interfaces that can be swapped out depending on your needs:

CRI (Container Runtime Interface) – controls how containers are run.
CNI (Container Network Interface) – controls networking between pods.
CSI (Container Storage Interface) – controls how storage volumes are provisioned.

This means you can mix and match providers (e.g. different container runtimes, networking plugins, or storage backends) without breaking your workloads.

Thinking in Objects

All Kubernetes resources are defined as objects in YAML or JSON. These follow familiar patterns:

Dictionary – key/value pairs that describe a single object.
- Example thinking about cars:

{ colour: blue, type: manual, mileage: 20k }
List/Array – a set of values of the same type.
- Example: Car Colour
[“red”, “blue”, “green”]

List of Dictionaries – multiple objects grouped together.

- Example: a list of cars, each with their own properties.

cars:
  - colour: blue
    type: manual
    mileage: 20000
  - colour: red
    type: automatic
    mileage: 5000
  - colour: black
    type: hybrid
    mileage: 12000

Once you learn to read these patterns, Kubernetes manifests start to feel predictable.

I’ve taken this example straight from KodeKloud. It’s where i’m learning this and I highly recommend you check them out.

A First Look at YAML

Here’s what a very simple Pod manifest looks like:

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

Run it with:

kubectl apply -f my-first-pod.yaml

Kubernetes will pick a node, deploy the Pod, and keep it alive.

We just covered clusters, control planes, pods, and how everything is defined in YAML.

For now, just remember: Kubernetes is “state driven orchestration.” You declare what you want, and it makes it happen.

Use this as a starting point, install Kubernetes and have a play.

Should I continue sharing my Kubernetes notes here?

WJPearce - CyberBrew

Enjoyed this? Why not check out my other reads…