The mental model behind every kubectl command: control plane vs nodes, pods, deployments, services, config, storage and namespaces, and how labels tie them together.
You declare the desired state in YAML and send it to the API server. The control plane stores it in etcd, and controllers keep reconciling the cluster until reality matches it. You never start containers yourself; you describe what should exist.
Control plane
kube-apiserver: the only entry point (kubectl talks to it)etcd: key-value store holding all cluster statekube-scheduler: picks a node for each new podkube-controller-manager: runs the reconcile loopsWorker node
kubelet: starts and watches pods on the nodekube-proxy: implements Service networking| Object | What it is |
|---|---|
| Pod | Smallest unit: 1+ containers sharing network and volumes. Disposable. |
| Deployment | Manages ReplicaSets: N identical stateless pods, rolling updates. |
| StatefulSet | Pods with stable names and their own storage (databases, Kafka). |
| DaemonSet | One pod per node (log agents, monitoring). |
| Job / CronJob | Run to completion / on a schedule. |
| Service | Stable virtual IP + DNS name in front of changing pods. |
| Ingress | HTTP(S) routing from outside to Services by host/path. |
| ConfigMap / Secret | Config and sensitive values injected as env or files. |
| PV / PVC | Storage: PVC is the request, PV is the actual disk. |
| Namespace | Logical partition for names, quotas and RBAC. |
A Service finds pods by selector, a Deployment owns pods by matchLabels, an HPA targets a Deployment by name. Wrong or mismatched labels are the most common reason "nothing connects".