Core objects
Pods, ReplicaSets, Deployments, StatefulSets, DaemonSets, Jobs and CronJobs, Services, ConfigMaps and Secrets, labels, annotations and namespaces, and how to tell look-alikes apart.
Exam tasks: 1.1 (Kubernetes core concepts: workload, service and configuration objects)
The decision: which object fits the workload described: something that runs forever or to completion, on every node or on some, with or without a stable identity?
Picking a workload object
| Object | Keeps running | Pod identity | Typical use |
|---|---|---|---|
| Pod | No controller: if the node dies, it's gone | Random | Learning, debugging. Almost never created directly |
| ReplicaSet | N identical Pods | Random suffix | Created for you by a Deployment |
| Deployment | N identical Pods, with rolling updates and rollback | Random suffix | Stateless web apps and APIs |
| StatefulSet | N Pods, created and removed in order | Stable: db-0, db-1, each with its own PVC | Databases, queues, quorum systems |
| DaemonSet | One Pod per (matching) node | One per node | Log shippers, node monitoring, CNI agents |
| Job | Until N completions succeed, retrying failures | Random | Batch work, migrations |
| CronJob | Creates a Job on a cron schedule | Random | Nightly reports, cleanup |
Pods
- The smallest deployable unit. A Pod wraps one or more containers that share a network namespace (one IP,
talk over
localhost) and can share volumes. - Put containers in the same Pod only when they must live and scale together: a main app plus a helper. Otherwise give each its own Pod and Deployment.
- Init containers run to completion, one after another, before app containers start.
- Sidecar containers are init containers with
restartPolicy: Always: they start first and keep running alongside the app (stable since v1.33). - Pods are ephemeral and replaceable. A replacement gets a new name and a new IP, which is why you put a Service in front.
Scaling by adding containers
To handle more traffic you add Pods (replicas), not more containers in one Pod. Containers in a Pod are always scheduled to the same node and scale as one unit.
Deployment, ReplicaSet and StatefulSet
- A Deployment owns ReplicaSets. Each change to the Pod template creates a new ReplicaSet, and the Deployment shifts replicas from the old one to the new one: that's a rolling update, and keeping old ReplicaSets is what makes rollback possible.
- A ReplicaSet only keeps a count. It has no update strategy of its own, so you rarely touch one directly.
- A StatefulSet gives each replica a stable ordinal name, a stable DNS name through a headless Service,
and its own PersistentVolumeClaim from
volumeClaimTemplatesthat survives rescheduling.
Exam signal
"Stable network identity", "ordered deployment" or "each replica keeps its own volume" means StatefulSet. "Rolling update of a stateless app" means Deployment. "Runs on every node, including new ones" means DaemonSet.
Jobs and CronJobs
- A Job's Pods use
restartPolicy: OnFailureorNever(neverAlways).completionssets how many must succeed,parallelismhow many run at once, andbackoffLimithow many failures are tolerated. - A CronJob creates Jobs on a schedule written in cron syntax, such as
"30 2 * * *"for 02:30 every day.concurrencyPolicy(Allow,Forbid,Replace) decides what happens if the previous run hasn't finished.
Services
- A Service gives a changing set of Pods (chosen by a label selector) one stable virtual IP and DNS name, and load-balances across them. The matching Pod IPs are tracked in EndpointSlices.
- Types:
ClusterIP(default, internal only),NodePort(a port on every node),LoadBalancer(cloud load balancer),ExternalName(DNS alias). A headless Service (clusterIP: None) returns Pod IPs directly. - Traffic details, DNS and Ingress are in Networking.
Configuration: ConfigMaps and Secrets
| ConfigMap | Secret | |
|---|---|---|
| Holds | Non-sensitive settings, config files | Passwords, tokens, keys, TLS certs |
| Stored as | Plain text | base64-encoded, not encrypted by default |
| Consumed as | Environment variables or files in a volume | Same |
| Size limit | 1 MiB | 1 MiB |
- Mounted as a volume, updates eventually reach the Pod. As environment variables, they're read only at container start.
- Protecting Secrets (encryption at rest in etcd, RBAC, external stores) is in Security.
base64 is encryption
base64 is an encoding: anyone who can read the Secret can decode it in one command. If the question asks how to protect Secret data stored in etcd, the answer is encryption at rest plus RBAC, not "they're base64".
Labels, selectors, annotations and namespaces
- Labels are key-value pairs used to select: Services find Pods, ReplicaSets count Pods, and
kubectl get pods -l tier=backendfilters by them. - Annotations are key-value metadata that is not used for selection: build info, tool settings, contact details. Values can be long.
- Namespaces partition names, RBAC and quotas inside one cluster. Names must be unique per namespace, not cluster-wide. Nodes, PersistentVolumes, StorageClasses and namespaces themselves are cluster-scoped.
- Created by default:
default,kube-system(control plane and add-ons),kube-public(readable by all),kube-node-lease(node heartbeats).
Exam signal
"Attach metadata that selectors use" is a label. "Attach metadata for tools, not for selection" is an annotation. Namespaces isolate names and permissions, but not network traffic: that takes a NetworkPolicy.
Scenarios
A DaemonSet places one Pod on each matching node and adds one automatically when a node joins. A Deployment with a fixed count doesn't track nodes and may put two replicas on the same node. A StatefulSet gives stable identity, not per-node placement. A CronJob creates short-lived Jobs, not a resident agent.
StatefulSet Pods get ordinal names (orders-db-0, orders-db-1) and a dedicated PVC each, both kept across
rescheduling. Deployments and ReplicaSets create interchangeable Pods with random suffixes and share one
template for volumes. A Job runs to completion and is the wrong lifecycle entirely.
A Service selects Pods by labels, and the matching Pod IPs end up in its EndpointSlices. Namespace only scopes where it looks. Annotations are never used for selection, and Pod names aren't matched at all.
Further reading
Cluster architecture
Control plane and node components, etcd and quorum, the API server as the hub, and the reconciliation loop that makes Kubernetes declarative.
The API and kubectl
API groups and versions, object structure, declarative vs imperative management, everyday kubectl, RBAC basics, and which tool builds which kind of cluster.