Kubernetes Primer: A Beginner's Guide to Container Orchestration

May 25, 2025

What is Kubernetes

K8S is a tool to orchestrate container workloads. Docker, which packs your apps into neat containers. Great! But what if you have hundreds, thousands, or even more containers? Managing all that manually is a nightmare. That’s where Kubernetes (K8s) steps in.

What is K8s? It’s the ultimate tool for handling massive container workloads. Think of it as a conductor for your container orchestra. It makes sure everything runs smoothly, automatically.

The Big K8s Ideas

Controllers (The “Set It and Forget It” Part): Imagine your home thermostat. You set a desired temperature, and it keeps your room at that temperature, no matter what. K8s controllers do the same for your applications. You tell K8s what you want (e.g., “I need 5 copies of this app running”), and it constantly works to make sure that state is maintained. If something breaks, K8s fixes it!

Container Orchestration Engine (The Smart Shipper): If Docker packs your goods, K8s is the smart shipping company. It doesn’t just move containers; it intelligently decides where they should run, ensures they have the resources they need (like storage and networking), and keeps them healthy.

K8s Cluster: A Quick Look

In the real world, you usually don’t have to build a Kubernetes cluster from scratch. Cloud providers (like AWS, Google Cloud, Azure) offer “managed K8s services” that give you a ready-to-use cluster with a few clicks. Super handy!

But it’s good to know what’s inside. A K8s cluster essentially has two main parts: the Control Plane and the Worker Nodes.

1. The Control Plane (The Brains)

This is the “head” of your Kubernetes cluster. It makes all the decisions and manages the overall state. You typically don’t run your applications directly on the Control Plane.

API Server: This is the main gateway for communicating with your cluster. Everything you do (like deploying an app or checking its status) goes through the API server. Think of it as K8s’s front desk.
Controller Manager: This is where all those “controllers” we talked about earlier live. It runs various control loops to ensure your desired state is maintained.
Scheduler: When you tell K8s to run an application, the Scheduler is responsible for deciding where in the cluster (which Worker Node) that application should run, based on available resources.
etcd: This is a super-fast, reliable key-value store. It’s like the cluster’s memory, storing all the configuration data, desired states, and actual states of your K8s objects.

2. Worker Nodes (The Muscle)

These are the machines (virtual or physical) where your actual applications (containers) run.

Kubelet: This is an agent that runs on each Worker Node. It communicates with the Control Plane, ensuring that containers are running in the Pods (your application units) on its node as instructed. It’s the Control Plane’s eyes and hands on the ground.
kube-proxy: This networking helper ensures that network communication within the cluster (between your applications) and to your applications from the outside world works correctly.
Container Runtime: This is the software that actually runs your containers. While Docker was once the go-to, Kubernetes is now designed to work with various runtimes (like containerd), making it more flexible.

K8s Objects: Your Application’s Blueprints

When you’re working with Kubernetes, you’re interacting with “objects.” These are the actual things you define and deploy to make your applications run. You’ll typically describe these objects using YAML files – it’s just a structured way to tell K8s what you want.

Every K8s object in a YAML file has a few key parts:

apiVersion: Specifies the K8s API version you’re using (e.g., v1, apps/v1).
kind: Defines the type of object you’re creating (e.g., Pod, Service, Deployment).
metadata: Information about the object:
- name: A unique name for your object.
- namespace: A way to logically separate objects within your cluster (like folders).
- labels: Key-value pairs that help organize and select objects (super important for linking things together!).
- annotations: Non-identifying metadata (like comments or tool info).
spec: This is the “specification” or “configuration” for your object. It’s where you define the desired state – what you want the object to do (e.g., which container image to use, how many replicas, resource limits).

Here’s a super basic example of a Pod object:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-example
spec:
  containers:
    - name: nginx-container
      image: nginx:latest # The Docker image to use
      ports:
        - containerPort: 80 # What port the container listens on

1. The Pod: Smallest Unit

A Pod is the smallest deployable computing unit in Kubernetes. It typically contains one application container, but it can hold multiple tightly coupled containers that need to share resources (like a main app container and a “sidecar” container for monitoring or logging).

2. Storage: Keeping Your Data Safe

Containers are designed to be ephemeral – they can come and go. But what about your data?

Volumes: Provide storage for containers.

Ephemeral: Data lives only as long as the Pod (good for temporary files).
Persistent: Data survives Pod restarts or deletions.

PersistentVolume (PV): Represents a piece of actual storage in your cluster (e.g., an AWS EBS volume, a Google Cloud Disk, or a network file system like NFS). This is provisioned by an administrator or dynamically by K8s.

PersistentVolumeClaim (PVC): This is your application’s request for storage. You ask for a certain size and access mode, and K8s tries to match it with an available PV.

Container Storage Interface (CSI): This is a standard interface that allows Kubernetes to connect to various storage systems (cloud providers, on-premise solutions). Cloud providers usually set this up for you so you can easily request storage.

The flow: Your app (in a Pod) requests a PVC, which is then linked to a PV, which uses a CSI driver to talk to the actual storage.

3. Networking: Connecting Your Apps

By default, only Pods get their own internal IP address. To make your applications discoverable and accessible, K8s provides Services.

Services: Define a logical set of Pods and a policy for accessing them. Services use labels to find the Pods they manage.

ClusterIP: Exposes the Service on an internal IP address within the cluster. Great for internal communication between your apps.
NodePort: Exposes the Service on a specific port on each Worker Node’s IP address. This makes your service accessible from outside the cluster via the node’s IP.
LoadBalancer: Automatically provisions an external cloud load balancer (like AWS ELB) for your Service, making it publicly accessible and distributing traffic.

Ingress Controllers: For more advanced external access, Ingress manages external access to services within the cluster, typically HTTP/S routes. An Ingress Controller (like Nginx Ingress or HAProxy) acts as a smart router, allowing you to define rules for routing traffic to different services based on domain names or paths. Ingress is often the preferred way to expose web applications to the public.

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: 80 # The port your container listens on
  selector:
    app: nginx # This links the service to Pods with this label
  type: LoadBalancer # Asks for a cloud load balancer

Container Network Interface (CNI): Similar to CSI for storage, CNI is a standard that allows K8s to integrate with different network plugins, enabling advanced networking features like network policies and service meshes (e.g., Istio, Cilium for very complex traffic management).

4. Workloads: Managing Your Apps’ Lifecycles

These are higher-level objects that manage your Pods, ensuring they run correctly and scale as needed.

Deployment: The most common way to run stateless applications. You tell a Deployment how many replicas of your Pod you want, and it ensures that number is always running. If a Pod fails, it automatically replaces it. Great for web servers!

StatefulSet: Designed for stateful applications (like databases) that require stable, unique network identifiers and persistent storage. Each Pod in a StatefulSet gets a unique ID and consistently attached storage.

DaemonSet: Ensures that a copy of a specific Pod runs on every (or selected) Worker Node in your cluster. Ideal for cluster-wide tasks like monitoring agents, logging collectors, or security tools.

Remember, Kubernetes uses Namespaces for logical separation. For example, kube-system is a reserved namespace for K8s’s own core services. It helps keep things organized!