What if you could learn the most important parts of Kubernetes by running five small examples instead of reading five hundred pages of documentation? That is the promise behind the official tutorials, and it mostly holds up. The trick is knowing which examples teach the most with the least setup, and which ones quietly waste an afternoon.
Kubernetes is an open-source container orchestration system for automating deployment, scaling, and management of containerized applications. It was originally developed by Google and released as open source in 2014. Since then, the project has grown into the default way teams run containers in production. But the concepts only click when you type the commands yourself.
This article walks through the examples that actually build understanding, in the order that works. It covers what each example teaches, the mistakes people hit, and how to tell you have learned the lesson. Anyone curious about where this fits in the wider ecosystem can also browse the cloud coverage on 9481.org, which tracks how these tools show up in real deployments.
Why Examples Beat Documentation for Learning Kubernetes
Kubernetes has a reputation problem. The documentation is accurate and thorough, but it is organized around concepts, not around the order a beginner needs them. A reader who starts with the architecture page meets controllers, kubelets, and etcd before ever running a container.
Examples flip that order. You deploy something, watch it break, fix it, and only then read the concept page that explains why. The official Kubernetes Basics tutorial follows exactly this logic, walking through deploy, explore, expose, scale, and update as a single sequence. That structure is not an accident. It mirrors how the system itself works.
There is a second reason examples matter. Kubernetes is declarative. You describe the state you want, and controllers work to make reality match. That idea is abstract until you scale a Deployment from one replica to four and watch four Pods appear. A single command teaches the concept better than a paragraph ever could.
The First Example: Deploy and Explore a Pod
Every learning path starts with a Pod, the smallest deployable unit in Kubernetes. A Pod holds one or more containers that share network and storage. Most examples start with Pods before moving to Deployments because the Pod is the thing everything else manages.
The canonical first example deploys an nginx container. In the official tutorial, you create a Deployment with `kubectl create deployment`, then inspect it. The commands look like this:
- Create the Deployment with a name and container image.
- Run `kubectl get pods` to see the Pod that appears.
- Run `kubectl describe pod` to read events, container status, and the assigned node.
- Run `kubectl logs` to see the container’s output.
What does this teach? That a Pod is scheduled onto a node, that it has an IP address, and that kubectl is your window into all of it. The kubectl command-line tool is the interface for nearly every example in this article, and the kubectl command reference is worth bookmarking early because it lists every verb and flag you will meet.
The common mistake here is skipping `describe`. Beginners jump straight to `get pods` and see a status of CrashLoopBackOff with no idea why. The describe output shows the events, and the events usually name the problem: a bad image tag, a missing secret, a resource limit that is too low.
The Second Example: Expose a Deployment with a Service
A Pod with an IP address is not reachable from outside the cluster in any useful way. The next example fixes that with a Service, which exposes a set of Pods as a network service. The official docs explain the exposure types in detail on the Service concept page, and the example is one command:
`kubectl expose deployment` with `–type=LoadBalancer` or `–type=NodePort`.
The two types behave differently, and the difference is a classic exam question and a classic production headache. Here is the practical comparison:
| Service type | What it does | When to use it |
|---|---|---|
| ClusterIP | Gives the Service an internal-only IP | Service-to-service traffic inside the cluster |
| NodePort | Opens a port on every node | Local testing and bare-metal clusters |
| LoadBalancer | Asks the cloud provider for an external IP | Public-facing services on managed clouds |
| ExternalName | Maps to a DNS name | Reaching services outside the cluster |
On a local cluster, a LoadBalancer Service will sit in a pending state forever because there is no cloud provider to hand out an address. That is not a bug, and it confuses almost everyone the first time. Use NodePort locally, or install a tool that simulates a load balancer.
The lesson this example teaches is that labels are the glue. A Service finds its Pods through a label selector, not through a name. Change the label on a Pod and the Service loses it. That single fact explains a huge share of “my service returns nothing” problems.
The Third Example: Scale and Watch Replicas Appear
Scaling is the example where Kubernetes stops feeling like Docker with extra steps. The official tutorial uses `kubectl scale` to move a Deployment from one replica to several. Within seconds, new Pods appear.
The mechanics matter more than the command. A Deployment manages ReplicaSets, and ReplicaSets manage Pods. When you scale, you are not touching Pods directly. You are changing a number in a spec, and a controller reconciles the difference. The Deployment concept page explains this ownership chain and the rollback behavior that comes with it.
A practical tip that saves real time: run `kubectl get pods -w` in a second terminal before scaling. The watch flag streams changes as they happen, so you see Pods move from Pending to ContainerCreating to Running. Watching the reconciliation happen is the moment the declarative model clicks for most people.
The common mistake is scaling a bare Pod instead of a Deployment. A bare Pod has no controller, so if it dies, nothing replaces it. Almost every production workload should be a Deployment, a StatefulSet, or a DaemonSet, never a loose Pod.
The Fourth Example: Rolling Updates and Rollbacks
This example is the one that sells Kubernetes to skeptics. You update the container image in a Deployment, and the system replaces Pods gradually instead of all at once. If the new version misbehaves, one command rolls it back.
The sequence is short:
- Update the image with `kubectl set image`.
- Watch the rollout with `kubectl rollout status`.
- Check the history with `kubectl rollout history`.
- Undo with `kubectl rollout undo`.
What this teaches is that declarative updates are safer than imperative ones. You describe the new desired state, and the controller handles the transition while keeping the service available. The rollback works because Kubernetes keeps old ReplicaSets around, which is also why a Deployment with a long history consumes more cluster resources than you might expect.
The mistake here is updating an image tag that does not exist. The rollout stalls, old Pods keep serving traffic, and the new ReplicaSet has Pods stuck in ImagePullBackOff. Running `kubectl rollout status` with a timeout catches this immediately instead of leaving you to discover it from a monitoring alert.
The Fifth Example: Declarative Manifests with kubectl apply
Every example so far used imperative commands. Real work uses files. The pattern used throughout official tutorials is `kubectl apply -f .yaml`, which reads a manifest and reconciles the cluster toward it.
A minimal manifest for a Deployment has four parts: apiVersion, kind, metadata, and spec. The spec contains the replica count, the label selector, and the Pod template. Writing one by hand is the single best exercise for understanding how the pieces fit, because every field maps to something you already saw in the imperative examples.
Practical advice from people who do this daily: keep manifests in version control from day one, even for throwaway experiments. The habit costs nothing and pays off the first time you need to recreate a cluster. It also makes the difference between `apply` and `create` obvious. Apply is idempotent and safe to rerun. Create fails if the object already exists.
For readers who want to follow how these practices evolve across releases and tooling, the news section at 9481.org is a reasonable place to keep an eye on the broader infrastructure conversation.
Local Clusters: Where to Run These Examples
None of the examples above require a cloud account. Two official projects cover almost every learning scenario: (Wikipedia: Containerization (computing)))
- Minikube runs a single-node cluster in a virtual machine or container on your laptop. It is the friendliest starting point and supports add-ons like dashboards and ingress controllers.
- kind runs Kubernetes nodes as Docker containers. It starts faster and is popular for testing multi-node behavior and CI pipelines.
Both are Kubernetes SIG projects, so they track upstream releases closely. The practical difference: Minikube is easier for a first cluster, kind is easier for repeatable test environments. Either works for every example in this article.
A tip that prevents a common frustration: check your machine’s memory before starting. A local cluster with default settings can consume several gigabytes, and a laptop already running a browser with forty tabs will struggle. Give the cluster at least four gigabytes and close what you do not need.
Mistakes That Trip Up Almost Everyone
Certain errors show up so often they deserve their own list.
Forgetting the namespace. Resources live in namespaces, and kubectl defaults to the one in your current context. A Pod that “disappeared” is usually in a different namespace. Add `-n` to be explicit.
Editing live objects by hand. Running `kubectl edit` on a resource managed by a manifest creates drift. The next `apply` overwrites the change, and nobody remembers why. Change the file, then apply.
Ignoring resource requests and limits. Examples rarely set them, so beginners never learn. Without requests, the scheduler cannot place Pods sensibly. Without limits, one runaway container can starve a node.
Assuming a Service is reachable. A Service only routes to Pods whose labels match its selector and whose readiness probes pass. If either condition fails, the endpoint list is empty and traffic goes nowhere.
Skipping cleanup. Leftover Deployments and Services accumulate. Run `kubectl delete` on what you created, or tear down the local cluster entirely.
How to Know You Have Actually Learned It
There is a simple test. Can you deploy an application, expose it, scale it, break it, and recover, without looking anything up? If yes, the core examples have done their job.
The next step is not more examples of the same kind. It is examples with constraints: a Pod that must run on a specific node, a Service that must only accept traffic from one namespace, a Deployment that must survive a node failure. Each constraint forces you to learn one more piece of the system.
For readers who want to see how these patterns appear in production tooling and platform work, the blog at 9481.org covers related ground. The main thing is to keep typing commands. Kubernetes rewards muscle memory more than reading.
Conclusion
The best Kubernetes examples are not the most complex ones. They are the five that build on each other: deploy a Pod, expose it with a Service, scale the replicas, roll out a new image and roll it back, then rewrite the whole thing as a manifest. Each one teaches a concept that the next one depends on, and each one fails in ways that teach you something the documentation cannot.
Start with a local cluster, keep the commands short, and clean up after yourself. The declarative model will feel strange for an afternoon and obvious by the end of the week.
Frequently Asked Questions
What is the simplest Kubernetes example for a beginner?
The simplest is deploying a single nginx container and inspecting the resulting Pod with `kubectl get pods` and `kubectl describe pod`. It requires one command, teaches what a Pod is, and shows how kubectl reports cluster state. The official Kubernetes Basics tutorial uses exactly this starting point.
Do I need a cloud account to run Kubernetes examples?
No. Local tools like Minikube and kind run a full cluster on a laptop. A cloud account only becomes necessary when you want to test cloud-specific features such as LoadBalancer Services that receive a real external IP address.
What is the difference between a Pod and a Deployment?
A Pod is the smallest deployable unit and runs one or more containers. A Deployment is a controller that manages Pods through ReplicaSets, adding scaling, rolling updates, and rollbacks. You almost never create bare Pods in production because nothing replaces them if they fail.
Why does my LoadBalancer Service stay in pending state?
On a local cluster there is no cloud provider to allocate an external IP, so the Service waits indefinitely. This is expected behavior, not a failure. Use a NodePort Service for local testing, or install a tool that simulates load balancer provisioning.
How long does it take to learn the Kubernetes basics?
Most people can run the core examples and understand what they do in a few days of focused practice. Reaching the point where you can debug a failing rollout without looking anything up typically takes a few weeks of regular use. Depth comes from constraints, not from more tutorials.
Should I use kubectl apply or kubectl create?
Use `kubectl apply` for anything you intend to keep. It is declarative and idempotent, so rerunning it reconciles the cluster toward your manifest. `kubectl create` fails if the object already exists, which makes it useful mainly for one-off experiments.
