Your First Cluster & kubectl

In one line

kubectl is your one tool for every interaction with a cluster — get, describe, apply, delete, and logs cover the overwhelming majority of what you'll type, on any cluster, for the rest of this course.

0/4 · 0%

Key ideas

01
For learning and local development, a full multi-machine cluster isn't necessary — tools like minikube or kind (Kubernetes IN Docker) run a genuinely real, complete Kubernetes cluster entirely inside a single machine (often literally inside Docker containers), giving you a real cluster to practice against with zero cloud cost.
02
kubectl get <resource> lists resources of a given type (kubectl get pods, kubectl get nodes, kubectl get deployments) — add -o wide for more columns, or -o yaml to see the FULL underlying object definition exactly as the API server stores it, genuinely useful for understanding what a resource actually looks like beneath kubectl's summarized table view.
03
kubectl describe <resource> <name> shows a detailed, human-readable summary of one specific resource, including its recent EVENTS (a genuinely essential troubleshooting source, covered fully in Phase 6) — this is usually the very first command to run when something isn't behaving as expected.
04
kubectl apply -f <file.yaml> is THE standard way to create or update resources — it's DECLARATIVE (Topic 0.1's reconciliation model in action): you describe the desired end state in YAML, and apply tells the API server to make the cluster match it, whether that resource already exists (updating it) or not (creating it fresh).
05
kubectl logs <pod-name> shows a container's stdout/stderr output — add -f to follow it live (exactly like tail -f, Linux's own course covered this pattern directly), and --previous to see the logs from a container's PREVIOUS run, genuinely essential when a container has already crashed and restarted and you need to see what happened right before it died.
06
kubectl exec -it <pod-name> -- <command> runs a command inside a running container interactively — kubectl exec -it my-pod -- /bin/sh drops you into an actual shell inside the container, exactly like Docker's own docker exec, genuinely useful for live debugging when logs alone aren't enough to understand what's happening.

Code & diagrams

kubectl-essentials.shmarkdown

The handful of commands that cover the overwhelming majority of real, everyday Kubernetes usage.

# See what's running
kubectl get pods
kubectl get pods -o wide          # more detail, including node and IP
kubectl get pods -o yaml          # the FULL underlying object definition

# See everything about one specific resource, including recent events
kubectl describe pod hello-pod

# Apply a YAML file — create if it doesn't exist, update if it does
kubectl apply -f my-app.yaml

# View a container's logs
kubectl logs hello-pod
kubectl logs -f hello-pod                # follow live, like tail -f
kubectl logs --previous hello-pod        # logs from before its last restart

# Get an interactive shell inside a running container
kubectl exec -it hello-pod -- /bin/sh

# Delete a resource by file or by name
kubectl delete -f my-app.yaml
kubectl delete pod hello-pod

# See what kubectl is actually configured to talk to right now
kubectl config current-context
kubectl cluster-info

Explain it without notes

Why is kubectl apply -f considered the standard way to manage resources, rather than separate explicit create/update commands?

You need to figure out why a pod crashed a few minutes ago and has since restarted. Which specific kubectl command shows you what it actually printed right before it died?

Practice

If you have access to any cluster (or set up a local minikube/kind cluster), run kubectl get pods -o yaml on any existing pod and read through the full object definition, identifying at least three fields you recognize from this phase's topics.

Create a pod, view its logs, delete it, recreate it, and use kubectl exec to get an interactive shell inside it — the complete everyday loop, once.

Trade-offs

↔
A local cluster (minikube/kind) is free and fast to experiment on, but it genuinely doesn't replicate everything a real multi-node production cluster involves (multiple real machines, real cloud networking, real load balancers) — it's an excellent, low-risk place to build command fluency and understand the core model, but concepts like true multi-node scheduling and cloud-specific networking are still worth eventually trying against a real managed cluster (even a small, temporary one) before calling yourself confident with them.

Done when you can

I can use kubectl get, describe, apply, logs, and exec confidently.
I understand why kubectl apply -f is the standard way to manage resources declaratively.
I have practiced the full create → inspect → debug → delete loop at least once on a real cluster.