Kubernetes stops looking chaotic once its objects start reading as a model for how an application lives, fails, and gets updated inside a cluster.
In real design work, the chapter shows how workload objects, scheduling, networking, storage, resource requests and limits, probes, and rollout strategies must be tied to a service’s SLO rather than configured as isolated checkboxes.
In interviews and engineering discussions, it helps draw an honest line between where Kubernetes provides control and scale leverage and where it adds unnecessary platform burden.
Practical value of this chapter
Design in practice
Map workload objects, scheduling, and cluster networking to concrete service SLO targets.
Decision quality
Treat resource requests, limits, probes, and rollout strategies as core reliability guardrails.
Interview articulation
Explain how the control plane, worker nodes, and namespace boundaries work together in production.
Trade-off framing
Highlight where Kubernetes provides scale leverage and where it adds unnecessary operational burden.
Official docs
Kubernetes Documentation
The official source for architecture, objects, networking, storage, and operational practices.
Kubernetes orchestrates containers: it accepts a desired-state description, stores it as API objects, and uses the control plane to gradually bring the cluster toward that state. The core idea is not a magical deployment button, but continuous reconciliation between what the team declared and what is actually running on worker nodes.
Current version and context
Docs branch
Documentation v1.36
As of May 11, 2026, the official Kubernetes docs mark v1.36 as the current branch.
Latest release
Kubernetes v1.36.0
Release 1.36.0 was published on April 22, 2026 on the official releases page.
Rule of thumb
Always check the docs version
API details and object behavior shift between minor versions, so advice from someone else's article can easily produce the wrong result on your cluster. Check the version selector in the docs first.
High-level architecture
In Kubernetes, the control plane stores and reconciles state, the scheduler selects worker nodes for Pods, the kubelet runs containers, and Service, Ingress, or Gateway API provides stable network access.
Clients
kubectl, CI, and platform operators
Control plane
accepts intent, stores state, and runs reconciliation loops
kube-apiserver
API, admission, RBAC
etcd
cluster state
scheduler
Pod → node
controller manager
reconciliation loops
access and admission
authentication, authorization, policies
cloud controller
provider integration
Worker nodes
run containers and report status back
Node A
Node B
Stable entry and routing
Service / Ingress / Gateway API
stable endpoint, service discovery, and north-south entry to Pods
Feedback loop
health, readiness, and actual state flow back through the API
Read the map from left to right: clients describe desired state, the control plane accepts and reconciles it, worker nodes run Pods, and the service layer provides stable network access.
Core API objects
Namespace
Divides a cluster for teams, environments, resource quotas, and access policies.
Pod
The smallest scheduling unit: one or more tightly coupled containers sharing a network context. The scheduler places a whole Pod, not an individual container — that is what decides which parts fail and recover together.
Deployment
Manages a ReplicaSet, gradually updates Pods, and supports rollback for stateless services.
Service
Provides a stable access point to dynamic Pods and enables service discovery inside the cluster.
ConfigMap & Secret
Keeps configuration and sensitive data outside the container image.
PersistentVolume & PVC
Connects persistent storage with an application's claim for storage in stateful systems.
Workload objects: what to use when
| Object | Best fit | Why |
|---|---|---|
| Deployment | Stateless Web/API services | rolling update, rollback, and replica self-healing |
| StatefulSet | Databases, brokers, and other stateful systems | stable identity, ordered rollout, and one volume per replica — without this a stateful database loses data on rescheduling |
| DaemonSet | Worker-node level agents | one Pod per worker node for log collection, metrics, and security signals |
| Job / CronJob | Batch and scheduled work | run-to-completion execution and scheduled starts |
Network and traffic
Service as the basic entry point
Service provides a stable address over Pods and enables service discovery. External traffic is usually handled through an Ingress Controller or Gateway API.
Ingress status in the docs
The official documentation marks Ingress as frozen: new capabilities are being developed only in Gateway API. In practice that means a new platform is better built on Gateway API from the start — otherwise you will be migrating the entry layer a year later for features Ingress will never get.
Storage and stateful applications
- PersistentVolume describes a real storage resource in the cluster or cloud provider.
- PersistentVolumeClaim is the application's declarative request for storage.
- StorageClass and dynamic provisioning can allocate volumes automatically.
- Stateful systems commonly use StatefulSet with one PVC per replica, so data survives Pod restarts and rescheduling.
Security minimum
Access and identity
The baseline loop is authentication, authorization, admission control, and RBAC. Namespaces and ServiceAccount usage provide a workable starting model for permissions — skip it and every Pod in the cluster gets more rights by default than it needs.
Secrets and supply chain
A secret committed to an image or Git stays in history forever and leaks with it. So keep secrets outside: rotation, an external secret manager, and container-image supply-chain scanning in CI/CD.
First-launch and operations checklist
- First launch: define the namespace strategy, resource requests, resource limits, and baseline network policy.
- First launch: agree on rollout policy and readiness, liveness, and startup probes.
- Operations: add HPA/VPA or cluster autoscaling to connect real load with capacity planning.
- Operations: provide observability through cluster logs, metrics, traces, and events.
- Operations: regularly review RBAC, secret management, and container-image supply-chain scanning.
Sources
Related chapters
- Why know Cloud Native and 12 factors - Context for Kubernetes as the core platform layer in cloud-native architecture and operating models.
- Containerization - The layer beneath Kubernetes: without a grasp of the runtime, images, and container lifecycle, Pod behavior inside the cluster stays magical.
- Kubernetes Patterns (short summary) - A practical catalog of probes, sidecars, operators, and rollout strategies for Kubernetes platforms.
- Service Mesh Architecture - Once you have many services, plain Service and Ingress stop being enough: go here for service-to-service traffic management, mTLS, and routing policy on top of Kubernetes.
- CKA: Exam preparation - Hands-on practice for core Kubernetes operations skills, terminal tasks, and troubleshooting scenarios.
- Identity, Authentication and Authorization - AuthN/AuthZ foundations for RBAC, ServiceAccount usage, admission policy, and cluster security boundaries.
- Designing Distributed Systems (short summary) - Distributed-system patterns that are often implemented and automated through the Kubernetes platform.