Skip to content

Essentials🔗

Building on Day One

Day One got an application running. Essentials is the layer where Kubernetes stops being magic — what each object actually is, why it's built this way, and what its blast radius is on the cluster you share with everyone else.

Day One showed you that kubectl apply works; here you learn why it works — the design decision behind each object and how Kubernetes reconciles it. Get this mental model right and every higher-level topic (StatefulSets, Ingress, operators, production ops) is just composition. Get it wrong and you'll spend years copying YAML you don't understand and hoping it works.

This tier treats you as a peer — design rationale and operational reality, no hand-holding.

Start Here: Core Primitives🔗

The atomic objects everything else is built from. Work through them in order — each builds on the last.

  • Pods

    What actually runs your container — and why Kubernetes schedules Pods, not containers.

  • Services

    A stable address for ephemeral Pods, and how a selector keeps it pointed at the live ones.

  • ConfigMaps & Secrets

    Configuration and credentials kept out of the image — and a Secret's real limits.

  • Namespaces

    Multi-tenancy boundaries, quotas, and the floor/ceiling of requests and limits.

  • Labels & Selectors

    The query layer that wires Services, controllers, and policy to the right Pods.

The Rest of Essentials🔗

The same foundation, deepening as each group lands:

  • Architecture (coming soon) — control plane vs. nodes, and the reconcile loop

  • Workloads (coming soon) — Deployments, ReplicaSets, Jobs, basic Ingress

  • Security (coming soon) — securityContext, secret hygiene, RBAC, Pod Security Standards

  • Troubleshooting (coming soon) — failure states, the diagnostic method, connectivity

What You'll Take Away🔗

This isn't a tour of kubectl flags. It's the layer of understanding that makes everything above it predictable — apply stops being a leap of faith. By the end you'll be able to:

  • Explain why Kubernetes wraps containers in Pods, and what that costs and buys you
  • Debug Service networking down to endpoints and DNS when it breaks
  • Keep configuration and credentials out of your images — and know a Secret's real limits
  • Use namespaces, quotas, and limits as the multi-tenancy controls they actually are
  • Treat labels and selectors as the query layer that wires the whole system together

The writing is direct and assumes you're here to understand the machine, not to be talked down off a ledge.

A Note on Shared Clusters🔗

You're almost certainly working in a shared cluster — your namespace next to other teams', all backed by the same cluster and running on the same nodes. That changes how you think about every object here.

Blast radius, not reassurance

Most of what you do is namespace-scoped, so the damage from a mistake is usually contained to your namespace. But "usually contained" is not "harmless":

  • A Pod with no resource limits can starve neighbours on the same node — cluster-wide impact from one namespace.
  • Deleting a namespace deletes everything in it, with no undo.
  • A misconfigured selector can silently send your traffic to the wrong Pods.

Throughout Essentials, safety is framed operationally: what breaks, who it affects, and how you recover — not whether you should feel nervous. Know your blast radius and you can move fast.

What's Next?🔗

Start with the object everything else is built on.

Next: Pods Deep Dive — what a Pod actually is, why Kubernetes schedules Pods instead of containers, what containers share inside one, the lifecycle, and the debugging commands you'll reach for daily.