Kubernetes Foundations
Kubernetes is a control plane for running containerized workloads. Its central idea is reconciliation: users declare desired state through API objects, and controllers continually work to make observed state match it.
Core Objects
A Pod is the smallest deployable unit and usually contains one application container plus optional helpers. A Deployment manages ReplicaSets to roll out replicated Pods. A Service gives stable networking to changing Pods. A ConfigMap and Secret inject configuration. An Ingress or gateway routes external traffic.
Kubernetes does not remove the need for application design. A stateless service with clear health checks fits naturally. A stateful service requires careful storage, backup, disruption, and upgrade planning.
Desired State
The API server stores desired state. Controllers observe, compare, and act. This is why manual changes inside a Pod are usually lost: the Pod is cattle, not the durable source of truth.
Scheduling and Labels
Kubernetes uses labels and selectors to connect objects. A Service finds Pods through labels. A Deployment manages Pods through selectors. Monitoring, policy, cost allocation, and ownership systems often use the same metadata. Sloppy labels make operations harder because the platform cannot answer which team owns a workload or which version is failing.
The scheduler places Pods on nodes based on requested resources, constraints, taints, tolerations, affinity, and available capacity. If a Pod has no memory request, scheduling decisions become guesswork. If every workload demands strict node affinity, the cluster may fragment capacity and fail to place otherwise healthy workloads.
Declarative Does Not Mean Simple
YAML is not the hard part of Kubernetes. The hard part is understanding the consequences of declared state. A readiness probe changes traffic routing. A resource limit changes runtime behavior. A security context changes permissions. A disruption budget changes upgrade safety. Every field is an operational statement.
Example: Service Discovery
A Deployment may create three Pods with label app: api. A Service selects app: api and gives them a stable virtual IP and DNS name. During a rollout, old and new Pods may coexist. Readiness determines which receive traffic. This is why application startup and shutdown behavior matters to Kubernetes correctness.
Study Task
Read one Deployment manifest and annotate every operational promise: replicas, labels, image, ports, probes, resource requests, security context, and update strategy. Then identify which promises are missing.
Operational Review
Kubernetes foundations should be reviewed through object relationships. A Pod runs containers, a Deployment manages replicated rollout, a Service gives stable access, and labels connect the pieces. If those relationships are unclear, debugging becomes guesswork.
A useful manifest review asks whether the workload declares ownership, health, resource needs, security context, and rollout expectations. Missing fields are not always wrong, but they should be intentional. A missing readiness probe means the platform may send traffic too early. Missing requests mean scheduling is less reliable. Missing labels make ownership and cost harder to trace.
The platform also needs a source of truth. Manual kubectl edit changes may be overwritten by controllers or GitOps tools. Students should learn to ask where desired state lives and which controller is responsible for reconciling it.
Replica Intent
apiVersion: apps/v1
kind: Deployment
spec:
replicas: