Prerequisites: none. This is a root note. Everything else in the vault assumes the vocabulary built here, so if a later article links back to [[kubernetes]], this is the page it means.
This note is deliberately shallow. It is not here to teach you Kubernetes from zero, it is here to pin down the handful of words the other articles lean on so they never have to stop and define them. If a term below is already second nature, skim it. If one is fuzzy, this is where it gets cleared.
Open a terminal with kubectl pointed at devata. Everything here is read-only.
A cluster is a pool of machines you talk to as one
devata is four machines, but you almost never address them one at a time. A Kubernetes cluster pools a set of machines so that instead of logging into a box and starting a process, you hand the cluster a description of what should be running and let it decide where. That shift, from “run this here” to “make this true somewhere,” is the whole idea. The thing you talk to is an API, and the cluster’s job is to keep reality matching what you declared.
See the machines:
kubectl get nodesEach row is a node, one real machine in the pool. Some nodes run the control plane, the components that hold the desired state and make placement decisions. The rest are workers, where your actual workloads land. On a small cluster the same machine can do both. The official Kubernetes components page names every piece if you want the full map later.
A pod is the thing that actually runs
You do not hand Kubernetes a container directly. You hand it a pod, the smallest unit it schedules: one or more containers that share a network address and run together on one node. When you read that “a pod got an IP” or “a pod was rescheduled,” this is the object meant.
kubectl get pods -A -o wideThe -A shows every namespace, which is just a grouping label that carves the cluster into folders like kube-system (the cluster’s own machinery) and monitoring (where Grafana and Prometheus live). The -o wide adds the node each pod sits on and the IP it was given. Those pod IPs, and how a request reaches one through a stable front address, are exactly what going-cilium-only takes apart in detail.
That stable front address has a name: a Service. For now hold one sentence about it, that a Service is a fixed identity standing in front of a changing set of pods, so callers reach the Service and never have to track which pods exist right now. The mechanism underneath is the subject of its own article, not this one.
kubectl is just an API client
Every command above is kubectl translating your request into an HTTP call to the control plane’s API server and printing what comes back. Nothing about the cluster requires this particular tool, it is one client among several, which is why the same cluster can be driven by a script, a CI job, or a GitOps controller later. Hold that thought, because moving from “things I typed into kubectl” to “things a controller applies from a repo” is the direction devata is heading.
When you want to try something destructive, do not try it here. The habit the rest of the vault builds on is spinning up a throwaway cluster on your laptop with kind, breaking it freely, and deleting it, so the real cluster is never the place you learn what happens when something is removed.