Explore the cluster
A Kubernetes cluster is a set of machines (nodes) running a
shared control plane. The control plane decides what should run
where; the worker nodes actually run your containers.
This sandbox is a tiny single-node cluster — one node that plays
both control plane and worker roles. That's enough to learn every
concept; production clusters just have more of the same parts.
List the nodes:
kubectl get nodes
Ask the cluster who it is:
kubectl cluster-info
See which Kubernetes version is running:
kubectl version --short
Look at the pods that already exist (the control-plane components run
as pods themselves in the kube-system namespace):
kubectl get pods -A
When the node shows STATUS Ready, click Verify step.
Hint
`kubectl get nodes` lists every node; the single-node sandbox shows one entry called `cac-lab`.
Create a pod from YAML
A pod is the smallest unit Kubernetes runs. It's a thin wrapper
around one or more containers that always live on the same node and
share a network namespace.
Kubernetes uses declarative configuration: you describe the
end-state in YAML and let the cluster make it true. Look at the
starter manifest:
cat pods/healthy-monolith.yaml
It declares a single pod called healthy-monolith running the
hello-app:1.0 sample image on port 8080.
Send it to the cluster:
kubectl apply -f pods/healthy-monolith.yaml
Watch the pod start:
kubectl get pods
STATUS will progress ContainerCreating → Running. Once it says
Running, click Verify step.
Hint
`kubectl apply -f pods/healthy-monolith.yaml` then `kubectl get pods`.
Inspect the running pod
Every Kubernetes object has a desired state (what you asked for)
and a current state (what the controllers see). describe shows
both, plus the events the cluster recorded along the way — image
pulls, scheduling decisions, probe results.
Print the long form:
kubectl describe pod healthy-monolith
Useful sections to scan:
- Containers → State —
Running, Waiting, or Terminated with
a reason.
- Conditions —
Ready: True once the readiness probe passes.
- Events (at the bottom) — the timeline of what just happened.
For a machine-readable view, ask for JSON or YAML output:
kubectl get pod healthy-monolith -o yaml | head -40
Find which node the pod landed on:
kubectl get pod healthy-monolith -o wide
When you see Ready: True, click Verify step.
Hint
`kubectl describe pod healthy-monolith` — look for `Status: Running`.
Logs and exec
Two commands you'll reach for constantly: logs (what did the
container print on stdout?) and exec (run a command inside the
container).
Tail the container's logs:
kubectl logs healthy-monolith
For a long-running app, follow new output as it arrives:
kubectl logs -f healthy-monolith
Press Ctrl-C to stop following.
Run a one-off command inside the container — useful for debugging
without rebuilding the image:
kubectl exec healthy-monolith -- hostname
Now write a sentinel file inside the container so the verify script
can find it:
kubectl exec healthy-monolith -- sh -c 'echo cac-101-here > /tmp/sentinel'
For an interactive shell (when you need to poke around):
kubectl exec -it healthy-monolith -- sh
Type exit to return.
When the sentinel file exists, click Verify step.
Hint
`kubectl exec healthy-monolith -- hostname` writes a sentinel string to a marker file.
Delete the pod
Pods are cattle, not pets. When you're done — or when you want to
test recovery — delete them.
kubectl delete pod healthy-monolith
Watch the pod terminate:
kubectl get pods
STATUS flips to Terminating; eventually the pod disappears from
the listing.
Confirm it's really gone:
kubectl get pod healthy-monolith
You should see Error from server (NotFound). That's the success
signal.
A bare pod is a one-shot — nothing brings it back. In the next lab
you'll wrap pods in a Deployment, which keeps a replica count
alive and supports rollouts, rollbacks, and scaling.
Click Verify step.
Hint
`kubectl delete pod healthy-monolith`.