How to Use Kubernetes: The Beginner's Guide (First Cluster, First Pod, First Deployment, First Service, and the Scale Rule)

CodexFuse Team · 2026-10-31T03:57:27.257Z · 16 min read

How to Use Kubernetes: The Beginner's Guide (First Cluster, First Pod, First Deployment, First Service, and the Scale Rule)

Learning how to use Kubernetes is the step that turns a developer who can run a container into a developer who can run containers at scale. This kubernetes for beginners tutorial walks the complete first loop in one sitting: pick a local cluster tool, start your first cluster, run your first Pod, write your first Deployment manifest, expose it with a Service, reach it from your browser, and scale it up and back down — all on your own laptop, with no cloud account and no credit card required. Before you apply a single manifest, run it through the free Kubernetes YAML analyzer — paste your YAML and it reads every workload, image, and missing limit so the cluster never sees a broken file.

How Do You Use Kubernetes as a Beginner?

You use Kubernetes by declaring what you want running in YAML files called manifests, then handing them to a cluster with kubectl. The cluster compares what you declared against what is actually running and closes the gap — starting containers, restarting crashed ones, and spreading copies across machines. Your whole first session fits this checklist:

1. Install Docker and kubectl — Docker runs the containers; kubectl is the remote control that talks to the cluster.
2. Pick a local cluster tool — minikube for the friendliest path, kind for the fastest Docker-native one.
3. Start your first cluster — one command (minikube start or kind create cluster), then confirm with kubectl cluster-info.
4. Run your first Pod — kubectl run hello --image=nginx puts one container on the cluster.
5. Write your first Deployment manifest — a small YAML file that asks for three copies of your app and applies it with kubectl apply -f.
6. Expose it with a Service — one stable address for your ever-changing Pods, reached locally through NodePort.
7. Scale it — kubectl scale deployment hello --replicas=5, watch the new Pods appear, then scale back down.

Each step below teaches exactly one of these, in order, with commands you can run verbatim.

What Is Kubernetes, and How Is It Different from Docker?

Docker runs one container; Kubernetes runs many containers across many machines and keeps them healthy without you babysitting them. Docker answers "how do I package my app?" — Kubernetes answers "how do I run fifty copies of it, restart the ones that crash, and update them without downtime?" If Docker is a shipping container, Kubernetes is the port authority that schedules every ship, crane, and truck.

Kubernetes is declarative, which is the one mental shift beginners need. You do not tell it "start a container, then another one." You write down the desired state — "three copies of this app, always" — and the cluster's controllers work continuously to make reality match the file. If a Pod crashes, the cluster starts a replacement without being asked; if you change the desired state from three copies to five, it creates the extra two. That self-healing loop is the whole reason Kubernetes exists.

The project came out of Google, built on 15 years of running containers at massive scale, and was donated to the Cloud Native Computing Foundation in 2014 — which is why every major cloud now offers a managed version of it (hugow.dev beginner guide, read October 30, 2026). But you do not need any cloud to learn it: this whole guide runs on your laptop. New to containers themselves? Read the Docker beginner guide first — Kubernetes orchestrates containers, it does not replace Docker.

What Do You Need Before You Start?

You need three things and nothing else: Docker installed, kubectl installed, and a local cluster tool. No cloud account, no credit card, no paid tier anywhere in this guide.

Docker. Both local cluster tools below run on top of Docker (or a compatible container/VM manager), so install it first. minikube officially lists Docker, QEMU, Hyper-V, KVM, Parallels, Podman, VirtualBox, and VMware as supported providers, and asks for 2 CPUs, 2 GB of free memory, and 20 GB of free disk space (minikube.sigs.k8s.io start guide, read October 30, 2026).

kubectl. This is the command-line tool that sends every command to your cluster. On Linux, the official install is:

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
kubectl version --client

The docs track the current stable release (v1.37 at the time of writing), and the one rule to remember is version skew: your kubectl must be within one minor version of the cluster — a v1.37 client works with v1.36, v1.37, and v1.38 control planes (kubernetes.io kubectl install docs, read October 30, 2026). On macOS, brew install kubectl does the same job.

A local cluster tool. That is the next decision, and it is a small one.

kind vs minikube: Which Local Cluster Should You Pick?

Pick minikube if you want the friendliest beginner path with the most hand-holding; pick kind if you want the fastest cluster that lives entirely inside Docker. Both are officially endorsed for local learning on the Kubernetes tools page, and both create a real cluster on your laptop (kubernetes.io install-tools page, read October 30, 2026).

This guide uses minikube for the main path because its service-access helpers make the "see it in your browser" moment effortless, and notes the kind equivalent wherever it differs. Either choice teaches you the same Kubernetes.

How Do You Start Your First Cluster?

You install the tool, run one start command, and verify with kubectl cluster-info. The whole thing takes a few minutes on a decent laptop.

Install minikube. On macOS: brew install minikube. On Windows: winget install Kubernetes.minikube (Chocolatey users: choco install minikube). On Linux, the binary download is: curl -LO https://github.com/kubernetes/minikube/releases/latest/download/minikube-linux-amd64 followed by sudo install minikube-linux-amd64 /usr/local/bin/minikube (minikube.sigs.k8s.io start guide, read October 30, 2026).

Start it. From a terminal with administrator access (but not logged in as root):

minikube start

minikube provisions the cluster and — this part is easy to miss — writes a kubeconfig file for you at ~/.kube/config. That file is how kubectl knows which cluster to talk to; you never edit it by hand as a beginner, just know it exists. Then verify:

kubectl cluster-info

If it prints a URL response, kubectl is correctly connected to your cluster (kubernetes.io kubectl docs, read October 30, 2026). The kind path is kind create cluster — kind points your kubeconfig at the new cluster automatically — followed by the same kubectl cluster-info check (dev.to kind quick-start guide, read October 30, 2026).

What Is a Pod, and How Do You Run Your First One?

A Pod is the smallest thing Kubernetes runs — usually one container, wrapped with its own IP address and lifecycle. You launch your first one with a single imperative command:

kubectl run hello --image=nginx

On modern clusters this creates exactly one Pod running the nginx image. (One history note that saves confusion: before Kubernetes 1.18, kubectl run created a Deployment; since 1.18 it creates a Pod directly — so old tutorials that expect a Deployment from this command are simply outdated, dev.to kubectl-run explainer, read October 30, 2026.) Check it:

kubectl get pods

You should see hello with STATUS Running. If you see ContainerCreating, wait a few seconds — the node is still pulling the image. kubectl get pods is the command you will run more than any other in Kubernetes; make it muscle memory now, because the next section teaches you to read it like a dashboard.

Reading kubectl get pods when something goes wrong

Learn this before you scale anything, because scaling a broken app just gives you five broken copies. The STATUS column tells you the story: Pending means the Pod is waiting (usually the image is still downloading); ImagePullBackOff means Kubernetes cannot fetch the image at all — nine times out of ten it is a typo in the image name; CrashLoopBackOff means the container starts and immediately dies, so the app itself is broken. For the details behind any status, kubectl describe pod <name> shows the event log, and kubectl logs <name> shows what the app printed before it died. Fix the cause, delete the Pod (kubectl delete pod hello), and move on.

How Do You Create Your First Deployment?

You write a small YAML manifest describing a Deployment and hand it to the cluster with kubectl apply -f. This is the declarative workflow from the checklist — the file is the desired state, and the cluster makes it real. Paste your manifest into the YAML validator first; indentation is the number-one syntax killer, and a validator catches it before the cluster complains.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
  labels:
    app: hello
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: nginx
        ports:
        - containerPort: 80

Read it top to bottom: this is a Deployment named hello that must always keep replicas: 3 Pods alive, and each Pod runs one nginx container on port 80. The critical detail is that selector.matchLabels must exactly match the labels under template.metadata — if they disagree, the Deployment finds zero Pods and silently does nothing. Apply it:

kubectl apply -f deployment.yaml
kubectl get deployments
kubectl get pods

kubectl get pods now shows three hello-* Pods, all Running. Delete one by hand — kubectl delete pod hello-abc123 — and run kubectl get pods again: the Deployment has already started a replacement. That self-healing is the difference between a Pod and a Deployment, and it is why you almost never create bare Pods in real work.

Pods vs Deployments: What's the Difference?

A Pod is one running instance; a Deployment is the manager that keeps the right number of those instances alive. You can think of a Pod as a single worker and a Deployment as the foreman with a headcount sheet.

Pods are ephemeral by design — when one is recreated it gets a new IP address, and nothing mourns it (hugow.dev beginner guide, read October 30, 2026). A Deployment wraps Pods in a ReplicaSet and adds the behaviors production needs: it maintains your replica count through crashes and node failures, it performs rolling updates (replacing Pods a few at a time so your app never goes down), and it can roll back with kubectl rollout undo deployment/hello if an update misbehaves. The beginner rule is simple: experiment with kubectl run Pods, but ship everything as a Deployment.

How Do You Expose Your App with a Service?

A Service gives your ever-changing Pods one stable address. Pods come and go with fresh IPs, so nothing outside should ever talk to a Pod directly — the Service holds a fixed ClusterIP and DNS name and forwards traffic to whichever Pods currently match its selector.

For local learning, the NodePort type is the path of least resistance — it opens the Service on a fixed high port of every node. Save this as service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: hello-service
spec:
  type: NodePort
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30080

Apply it and open it in your browser:

kubectl apply -f service.yaml
minikube service hello-service --url

The command prints a URL — open it and you will see the nginx welcome page served from inside your cluster. On kind, NodePort is the same story: the dev.to kind guide maps a host port to the node port in its cluster config, then reaches the Service at localhost:30080 (dev.to kind quick-start, read October 30, 2026).

Now the gotcha every beginner hits: LoadBalancer is the standard way to expose a Service on real clouds, but your laptop has no cloud load balancer. If you create a Service of type LoadBalancer on minikube, kubectl get svc shows the external IP stuck at <pending> — and it will stay there until you run minikube tunnel in a separate terminal, which builds the network route and assigns the IP (it asks for your password, and it must keep running; Ctrl-C tears the route down). This is straight from the minikube accessing-apps handbook: without the tunnel, the IP stays pending (minikube.sigs.k8s.io handbook, via mirror read October 30, 2026). The three Service types to remember: ClusterIP (internal only, the default), NodePort (internal plus a node port, your local-learning friend), and LoadBalancer (cloud-style, needs the tunnel locally).

How Do You Scale Your App?

You change the replica count with one command and the Deployment does the rest:

kubectl scale deployment hello --replicas=5

Run kubectl get pods and watch two new Pods spin up to join the original three. Scale back down with --replicas=1 and watch the extras terminate. Notice the order of operations this guide enforced: you learned to read Pod statuses before you ever scaled, so if a scaled-up Pod misbehaves you already know where to look.

Scaling pairs with updates. Change the image in your Deployment manifest (say, to a newer nginx tag), kubectl apply -f deployment.yaml again, and follow the rollout with kubectl rollout status deployment/hello — Kubernetes replaces Pods gradually so the Service never drops traffic. If the new version breaks, kubectl rollout undo deployment/hello walks it back. This scale-and-roll pattern is the daily rhythm of Kubernetes operations (BoxPiper Kubernetes tutorial, read October 30, 2026).

What Are the Beginner Mistakes That Waste Your First Day?

Every one of these has eaten somebody's afternoon. Learn them from a table instead.

Where Do You Go After Your First Cluster?

You now own the core loop: cluster, Pod, Deployment, Service, scale. The honest next-steps list, in the order that pays off: learn ConfigMaps and Secrets so configuration stops living inside your manifests; learn namespaces so experiments stop colliding with each other; then try Helm, which packages whole applications as reusable charts. Managed clusters — Google GKE, Amazon EKS, Azure AKS — are the production branch of this same knowledge, and they bill by the underlying VMs, so the what is VPS hosting mental model carries straight over. CI that deploys to your cluster is the step after that. None of it is required today — you have a running cluster on your laptop, and that is the whole foundation.

Sources

• Kubernetes official docs — Install Tools page (kind and minikube endorsed for local learning) — https://kubernetes.io/docs/tasks/tools/ — read October 30, 2026
• Kubernetes official docs — Install kubectl on Linux (v1.37 current, curl + sudo install commands, version-skew rule, kubeconfig at ~/.kube/config, kubectl cluster-info check) — https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/ — read October 30, 2026
• minikube official docs — start guide (2 CPUs / 2 GB RAM / 20 GB disk requirements; brew install minikube, winget install Kubernetes.minikube, Linux binary download; minikube start) — https://minikube.sigs.k8s.io/docs/start/ — read October 30, 2026
• minikube official handbook — accessing apps (NodePort via minikube service --url; LoadBalancer needs minikube tunnel in a separate terminal, external IP stays <pending> without it) — https://minikube.sigs.k8s.io/docs/handbook/accessing/ — via mirror, read October 30, 2026
• hugow.dev Kubernetes beginner guide (Google origins, CNCF 2014 donation; Pods ephemeral with new IPs on recreate; Deployment manages ReplicaSets) — https://blog.hugow.dev/posts/kubernetes-beginner-guide.html — read October 30, 2026
• dev.to kind quick-start guide (Docker + kind + kubectl prerequisites, kind create cluster, NodePort port-mapping config, automatic kubeconfig context) — https://dev.to/mortennordbye/getting-started-with-kubernetes-a-quick-start-guide-2ldm — read October 30, 2026
• dev.to kubectl-run explainer (pre-1.18 created a Deployment, post-1.18 creates a Pod directly) — https://dev.to/naveens16/why-kubectl-run-command-is-often-misunderstood-45h — read October 30, 2026
• BoxPiper Kubernetes tutorial 2026 (kubectl scale, kubectl rollout undo, self-healing and rolling-update model) — https://www.boxpiper.com/posts/kubernetes-tutorial-key-concepts-for-beginners-with-code-snippets — read October 30, 2026
• ByteGoblin Kubernetes hands-on tutorial (minikube-first learning path, Deployment + Service arc) — https://bytegoblin.io/blog/a-beginners-guide-to-learning-kubernetes-hands-on-tutorial.mdx — read October 30, 2026

Frequently Asked Questions

Is Kubernetes hard to learn for beginners?

It feels hard for the first hour because the vocabulary is new — Pod, Deployment, Service — but the beginner loop is only seven steps and runs entirely on your laptop. Most developers reach "I deployed and scaled an app" in a single afternoon; the depth (networking, storage, security) comes later and is optional at first.

Do I need to pay for anything to learn Kubernetes?

No. minikube and kind are free and open source, and they run a real cluster on your own machine — no cloud account, no credit card, no trial that expires. You only start paying when you move to managed cloud clusters like GKE, EKS, or AKS for production.

Can I learn Kubernetes without knowing Docker?

You can follow this guide without deep Docker knowledge, but the container basics make everything click faster — Kubernetes never builds images, it only runs the ones Docker builds. If the image/container vocabulary feels foreign, the Docker beginner guide is the right prerequisite.

Why does my LoadBalancer Service show <pending> as its external IP?

Because your laptop has no cloud load balancer to provision one. On minikube, run minikube tunnel in a separate terminal and keep it running — it builds the network route and the IP appears. Or sidestep the issue entirely with a NodePort Service and minikube service <name> --url.

What is the difference between kubectl apply and kubectl create?

kubectl create makes a resource once and fails if it already exists — it is imperative. kubectl apply is declarative: it compares your manifest against the live object and updates only what changed, so you can re-run it safely after every edit. Beginners should default to apply with manifest files.