System Design Space
Knowledge graphSettings

Updated: May 11, 2026 at 8:52 AM

Kubernetes Fundamentals (v1.36): Architecture, Objects, and Core Practices

medium

A practical base on Kubernetes based on the official documentation v1.36: control plane, workload objects, networking, storage, and core operations.

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.

Open documentation

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 behavior can differ between minor versions, so verify the documentation selector.

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.

API requestReconciliationWorker nodes

Clients

kubectl, CI, and platform operators

manifestsAPI requestsGitOps/CI
↓ API request

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

↓ Pod placement

Worker nodes

run containers and report status back

Node A

kubelet + runtimePods and containers

Node B

kubelet + runtimePods and containers

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.

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

ObjectBest fitWhy
DeploymentStateless Web/API servicesrolling update, rollback, and replica self-healing
StatefulSetDatabases, brokers, and other stateful systemsstable identity, ordered rollout, and one volume per replica
DaemonSetWorker-node level agentsone Pod per worker node for log collection, metrics, and security signals
Job / CronJobBatch and scheduled workrun-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 in Gateway API. For new platforms, that is an important signal when choosing the entry layer.

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.

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.

Secrets and supply chain

Secrets should not live in images or Git. Add 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

Enable tracking in Settings