Kubernetes Course
Kubernetes Objects Overview
You've learned how the cluster works. Now let's talk about what you actually build inside it. Kubernetes gives you a set of building blocks — called objects — and you combine them to run your application. This lesson is your first look at all of them, in plain English, before we go deep on each one.
What Is a Kubernetes Object?
A Kubernetes object is a record stored inside etcd that describes something you want to exist in your cluster. It could be a running container, a network address, a config file, a storage volume — all of these are objects.
Every object has two parts:
What you want. You write this. "I want 3 copies of my payment app, each with 512 MB of memory, always running."
What actually is. Kubernetes writes this. "Right now 2 copies are running. 1 is being started on worker-node-02."
Kubernetes is constantly comparing these two things. If the status doesn't match the spec, something springs into action to close the gap. That's the whole system in one sentence.
Think of it like LEGO
Each Kubernetes object type is a different LEGO brick — a specific shape with a specific job. A Pod holds containers. A Deployment manages a set of Pods. A Service gives them a stable address. A ConfigMap holds configuration. You pick the bricks you need and connect them together. Every real production app is built from exactly these pieces.
The Full Map — Every Object in One View
There are a lot of object types in Kubernetes. Don't try to memorise them all now. Just get a feel for what exists and which category each one belongs to. You'll learn each one properly in the lessons ahead.
The Five You'll Use Every Single Day
You'll eventually need all of those objects. But five of them are the foundation everything else builds on. If you understand these five deeply, you can deploy almost any application to Kubernetes right now. Let's look at each one — just an introduction, we'll go much deeper in the lessons ahead.
A Pod is a wrapper around one or more containers that are meant to run together on the same machine and share the same network. In most cases a Pod has just one container inside it — your app.
Here's the key thing — you almost never create Pods directly. You create a Deployment (see below) and it creates Pods for you. But understanding Pods first makes everything else click.
A ReplicaSet says "I want exactly 3 copies of this Pod running at all times." If one dies, the ReplicaSet creates a new one. If you somehow end up with 4, it deletes one. It keeps the count exactly right, always.
Again — you rarely create ReplicaSets directly either. A Deployment manages ReplicaSets for you. But knowing they exist helps you understand how rolling updates work.
A Deployment is what you use to run your application in production. It creates and manages a ReplicaSet. When you want to update your app to a new version, you update the Deployment — it handles the rolling update for you, replacing old Pods with new ones one at a time so users never see downtime.
Deployments also let you roll back. If version 2 has a bug, one command takes you back to version 1 instantly.
Pods come and go. They get new IP addresses every time they restart. So you can never reliably point other things at a Pod's IP directly. A Service solves this — it gives you one stable address that always routes to whichever Pods are currently healthy behind it.
Your frontend never needs to know which specific Pod is handling its request. It just calls payment-service and the Service takes care of routing to a live Pod.
A ConfigMap stores non-sensitive configuration data — things like database URLs, feature flag settings, API endpoints, or timeout values. Instead of baking these values into your container image, you store them in a ConfigMap and inject them into your Pod at runtime.
This means you can use the same container image in development, staging, and production — just with different ConfigMaps.
How These Objects Connect to Each Other
The objects don't exist in isolation — they reference each other. Here's how a real application is wired together:
The Glue That Connects Everything: Labels
Here's something that surprises a lot of beginners. Kubernetes objects don't connect to each other by name or by ID. They connect through labels — small key-value tags you stick on objects.
For example, you might label all your payment Pods with app: payment-api. Then your Service says "send traffic to any Pod with label app: payment-api." That's it. The Service doesn't care which specific Pods exist — it just finds all matching ones and routes to them.
This is actually genius. Because when you scale up from 3 Pods to 10 Pods, the Service automatically picks up the new ones — they have the same label. When you deploy a new version and old Pods are replaced, the Service follows along automatically. You never have to update the Service's config when Pods change.
Your Quick Reference — All Objects at a Glance
| Object | Plain-English job | You'll need it when... |
|---|---|---|
| Pod | Runs one or more containers together | Always — it's the base unit of everything |
| ReplicaSet | Keeps N copies of a Pod alive | Managed by Deployments — rarely used directly |
| Deployment | Deploys and updates stateless apps | Running any web server, API, or backend service |
| Service | Stable network address for a group of Pods | Anytime two parts of your app need to talk |
| ConfigMap | Stores non-sensitive config your app needs | Any config that differs between environments |
| Secret | Stores passwords, API keys, certificates | Anything sensitive that your app needs at runtime |
| StatefulSet | Deploys apps that need stable identity and storage | Databases, message queues, anything with state |
| DaemonSet | Runs one Pod on every node automatically | Log collectors, monitoring agents, node-level tools |
| Ingress | HTTP routing rules from outside the cluster | Exposing your app to the internet with proper URLs |
| Namespace | Virtual partition inside a cluster | Separating dev/staging/prod or multiple teams |
| PersistentVolume | Storage that outlives a Pod | Anything that needs to save data permanently |
A lot of people try to memorise all the object types in one go. Don't. This lesson exists to give you the map — so when a later lesson introduces a Job or a DaemonSet you already know roughly where it fits. The details come later, lesson by lesson.
The one thing to genuinely take away right now: Deployment + Service + ConfigMap is the pattern behind 80% of what you'll deploy to Kubernetes. Everything else is either a variation on that or a special case.
Open Play with Kubernetes or Minikube and run these commands. Even an empty cluster has objects already running inside it:
kubectl api-resources
# List objects in the default namespace
kubectl get all
# List objects across every namespace
kubectl get all --all-namespaces
# Get just Pods, Services and Deployments together
kubectl get pods,services,deployments
kubectl api-resources is brilliant for exploration — it lists every object type available in your cluster, including the short name you can use as a shortcut. For example po for Pods, svc for Services, deploy for Deployments.
Practice Questions
From memory — no peeking at the tables above.
1. Kubernetes objects don't connect to each other by name or ID. What do they use instead to find and group related objects?
2. Every Kubernetes object has two parts. The part you write — describing what you want to exist — is called the ________.
3. You want to run a log-collection agent on every single node in your cluster automatically — including any new nodes that join in the future. Which object type is built exactly for this?
Knowledge Check
Pick the best answer.
1. You're deploying a web API to production. It needs to always have 3 copies running, update without downtime, and be rollback-able if something breaks. Which object is the right choice?
2. Your frontend Pod needs to reliably reach your backend Pods — even when they restart and get new IP addresses. What do you need?
3. Your app needs three pieces of config injected at runtime: a database URL, a database name, and a database password. How should you store them in Kubernetes?
Up Next · Lesson 8
Pods Explained
Time to go hands-on. We write our first real YAML, deploy a Pod, and explore exactly what happens inside it — containers, networking, shared storage and all.