Kubernetes·July 6, 2026·7 min read

Kubernetes for Beginners: kubectl, Pods, and Your First Cluster

Most people meet Kubernetes the hard way. They copy a YAML file off a tutorial, run kubectl apply -f, watch it break, and then spend an hour Googling error messages they have no context for. The cluster feels like a black box, and every command is a guess. It does not have to start that way. If you learn to read a cluster before you try to change one, Kubernetes stops being intimidating and starts being a system you can reason about.

This post walks through the three skills that turn that black box into something you understand: reading cluster state, creating objects the right way, and debugging a Pod when it misbehaves. Each one maps to a hands-on lab you can run in your browser, in a real Kubernetes cluster, with no setup on your machine.

First Skill: Read the Cluster Before You Touch It

Here is something most beginners are never told. Real Kubernetes work is mostly reading. On-call engineers spend far more time running kubectl get and kubectl describe than they spend writing manifests. Every troubleshooting session, every exam task, and every code review starts the same way: by looking at what the cluster currently thinks is true.

Kubernetes is an API-driven system. Every Pod, Service, and Node is a typed object stored by the API server. The kubectl command is just a client that reads and writes those objects. Four verbs do almost all of the reading:

kubectl get lists objects. Add -o wide for more columns, or -o yaml to see the full object the server actually stores, including fields you never typed.
kubectl describe shows a single object in detail, including the events the cluster emitted while managing it. This is where you find out why something is stuck.
kubectl explain is an offline manual for every resource. Run kubectl explain pod.spec.containers and it tells you exactly what fields exist and what they mean.
kubectl api-resources lists every kind of object the cluster knows about, and which ones live in a namespace.

Why -o yaml is the source of truth

When you run kubectl get pod my-pod -o yaml, you see the real object, including all the defaults Kubernetes filled in for you. This is the single best way to stop being confused by "extra fields" in other people's YAML. They did not type them either.

The best way to make these verbs feel natural is to drive a cluster that already has workloads running, so you have something real to inspect. Practice this yourself by exploring a pre-built cluster. You can open the Drive Your First Cluster with kubectl Verbs lab on cloudlearn.io.

Hands-on LabBeginner35 minutesDrive Your First Cluster with kubectl VerbsPractice kubectl get, describe, and explain on a pre-built kind cluster before touching any YAML.cloudlearn.ioPractice hands-on

Second Skill: The Bridge Between Imperative and Declarative

Once you can read a cluster, the next question is how to create things in it. This is where a lot of beginners get stuck for weeks, because two commands look interchangeable but are not: kubectl create and kubectl apply.

Think of it as a spectrum. On one end is the imperative style: kubectl run nginx --image=nginx:alpine spins up a Pod in one line, with no file to save. On the other end is the declarative style: a YAML manifest you keep in Git and reconcile into the cluster with kubectl apply -f. Production teams live on the declarative end, because manifests are reviewable, version-controlled, and repeatable.

The part most tutorials skip is that one flag connects the two ends. Add --dry-run=client -o yaml to an imperative command and instead of creating anything, Kubernetes prints the manifest it would have created:

kubectl run nginx --image=nginx:alpine --dry-run=client -o yaml > pod.yaml

Now you have a starter YAML file you did not have to write by hand. That is the fastest way to bootstrap a manifest, and every experienced engineer uses it.

apply and create are not the same

Run kubectl apply -f pod.yaml twice and the second run says unchanged. Run kubectl create -f pod.yaml on an object that already exists and it errors with AlreadyExists. apply is idempotent because it records what you last applied in an annotation and computes the difference. create just tries to make a brand-new object every time.

Seeing this happen in front of you, by creating the same Pod three different ways and diffing the results, is what makes it stick. Practice the full comparison by opening the Imperative vs Declarative Pod Creation lab on cloudlearn.io.

Hands-on LabBeginner40 minutesImperative vs Declarative Pod Creation Side by SideCreate the same Pod three ways and see how kubectl run, dry-run YAML, and hand-written manifests all converge on apply.cloudlearn.ioPractice hands-on

Third Skill: Inspect, Create, and Debug a Pod

A Pod is the smallest thing Kubernetes schedules, and it is the wrapper that every bigger object eventually creates for you. A Deployment makes Pods. A Job makes Pods. So if you can confidently create and debug a single Pod, you have the foundation for everything else.

When a Pod misbehaves, four verbs do the diagnostic work:

kubectl get pods -w watches the Pod move through its lifecycle: Pending, then ContainerCreating, then Running.
kubectl describe pod shows the events. This is how you read a failure like ImagePullBackOff instead of guessing at it.
kubectl logs prints what the container itself wrote to its output.
kubectl exec -it drops you inside the running container so you can check the filesystem and network from within.

A useful exercise is to break a Pod on purpose. Typo the image tag, apply it, and watch kubectl describe report ImagePullBackOff in its events. Fixing a failure you caused yourself teaches the debugging loop far better than reading about it.

Containers in a Pod share more than a name

Put two containers in one Pod and they share a network namespace, so they can reach each other on localhost, and they can share files through an emptyDir volume mounted in both. This is the foundation of the sidecar pattern you will see everywhere later.

Walk through the whole loop, from authoring a Pod to debugging a broken one to proving multi-container sharing, by opening the Inspect, Create, and Debug Your First Pod lab on cloudlearn.io.

Hands-on LabBeginner1 hourInspect, Create, and Debug Your First Pod with kubectlAuthor a Pod, watch its lifecycle, debug an ImagePullBackOff with describe, then prove a multi-container Pod shares localhost networking and an emptyDir volume.cloudlearn.ioPractice hands-on

How the Three Skills Build on Each Other

These labs are designed as a path, not a menu. The order matters:

Read first. You cannot debug what you cannot inspect, so the read-only verbs come before anything else.
Create the right way. Once you can read state, you learn how objects get into the cluster and why apply is the habit to build.
Debug with confidence. With reading and creating in hand, breaking and fixing a Pod becomes a calm, repeatable loop instead of a panic.

Every lab runs in an in-browser environment with a real single-node cluster and kubectl, helm, and k9s already installed. There is nothing to set up locally, which means you can focus on the concepts instead of fighting your laptop.

Where This Leads

These three skills are the literal first week of the CKAD (Certified Kubernetes Application Developer) path, and they transfer directly to the CKA exam too. More importantly, they are what real Kubernetes work feels like day to day: read the cluster, create what you need, debug what breaks.

Start with the first lab, work through them in order, and by the end you will have done the things most people only read about. The best way to learn Kubernetes is to drive a real cluster, so open the first lab and follow along.