Core Concepts — The Restaurant Blueprint

Before the manager can hire chefs and assign stations, everyone needs to learn the vocabulary. Kubernetes has a small set of core objects — once you understand these, every Kubernetes configuration makes sense.

The Big Picture

A Cluster is the restaurant. Nodes are the kitchen stations. Pods are individual chefs. Deployments are the hiring plan. Services are the order window.

Pods — The Individual Chefs

A Pod is the smallest unit Kubernetes manages. It's a wrapper around one or more containers that share the same network and storage. In practice, most Pods run a single container.

A simple Pod

apiVersion: v1
kind: Pod
metadata:
  name: web-chef
  labels:
    app: campus-library
spec:
  containers:
    - name: web
      image: campus-library:1.0.0
      ports:
        - containerPort: 3000

Remember

You almost never create Pods directly. You create Deployments, and Kubernetes creates Pods for you. Pods are the "chefs" — but the manager (Deployment) decides how many to hire.

Deployments — The Hiring Plan

A Deployment tells Kubernetes how many replicas of a Pod to run, which image to use, and how to update them. It's the manager's hiring plan.

A Deployment — run 3 web chefs

apiVersion: apps/v1
kind: Deployment
metadata:
  name: campus-library
spec:
  replicas: 3
  selector:
    matchLabels:
      app: campus-library
  template:
    metadata:
      labels:
        app: campus-library
    spec:
      containers:
        - name: web
          image: campus-library:1.0.0
          ports:
            - containerPort: 3000

This tells Kubernetes: "Always keep 3 copies of the web chef running. If one falls sick, replace it."

What happens when a Pod dies?

The Deployment notices and immediately creates a new Pod. That's self-healing — the manager never leaves a station unattended.

Remember

Deployments are what you use 99% of the time. They handle scaling, rolling updates, and rollbacks automatically.

Services — The Order Window

Pods have internal IP addresses that change every time they're recreated. A Service provides a stable IP address and DNS name that routes traffic to all matching Pods.

A Service — stable front door

apiVersion: v1
kind: Service
metadata:
  name: campus-library-svc
spec:
  selector:
    app: campus-library
  ports:
    - port: 80
      targetPort: 3000
  type: ClusterIP

Now any Pod in the cluster can reach the web app at campus-library-svc:80.

Service types

Type	Purpose	Analogy
ClusterIP	Internal only (default)	Kitchen order window — only staff can order
NodePort	Expose on a static port on every node	Takeout window — anyone on the street can order
LoadBalancer	Cloud provider's load balancer	Drive-through — public traffic distributed evenly

Remember

Services are the stable address for your Pods. Without a Service, Pod IPs are ephemeral and unreliable.

Namespaces — Different Kitchens in the Same Restaurant

Namespaces partition a cluster into virtual clusters. Use them to separate environments (dev, staging, prod) or teams.

Create a namespace

kubectl create namespace campus-dev

Use a namespace

kubectl get pods -n campus-dev

In a manifest

apiVersion: v1
kind: Pod
metadata:
  name: web-chef
  namespace: campus-dev

Remember

Namespaces are organizational, not security boundaries. They separate resources visually but don't isolate them by default.

ConfigMaps and Secrets — The Recipe Book and the Safe

ConfigMaps — non-sensitive configuration

ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DB_HOST: "db-svc"
  APP_PORT: "3000"

Secrets — sensitive configuration

Secret (values are base64-encoded)

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  DB_PASSWORD: c2VjcmV0

Use them in a Pod

spec:
  containers:
    - name: web
      image: campus-library:1.0.0
      envFrom:
        - configMapRef:
            name: app-config
        - secretRef:
            name: app-secrets

Common mistake

Secrets are base64-encoded, not encrypted. Use a secrets management tool (Vault, AWS Secrets Manager) for production.

Persistent Volumes — The Walk-In Freezer

Pods are ephemeral. When a Pod dies, its data is gone. PersistentVolumes (PV) and PersistentVolumeClaims (PVC) provide storage that survives Pod restarts.

PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-storage
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Use it in a Pod

spec:
  containers:
    - name: db
      image: postgres:16
      volumeMounts:
        - mountPath: /var/lib/postgresql/data
          name: db-storage
  volumes:
    - name: db-storage
      persistentVolumeClaim:
        claimName: db-storage

Remember

PV is the freezer (storage). PVC is the chef's request: "I need 10GB of storage." Kubernetes fulfills the request from available storage.