The map
- Not started
- In progress
- Done
- Builds on
- 01The cluster's brainDesired state, pods, placement0/3
- 02Running and reaching your appRollouts, Services, routing, config0/4
- 03Keeping it healthyProbes, resources, autoscaling0/3
- 04State, security and extensionStorage, access, operators0/3
- 05Next: system designSame ideas, at service scale
- Sidecar and service meshLibrary ↗Native sidecar containers are what a mesh's proxies run as. This is the pattern: TLS, retries and telemetry moved into a proxy beside each pod.
- BulkheadLibrary ↗Requests, limits, quotas and separate node pools are bulkheads for compute. The pattern explains how to size and separate them so one workload cannot sink the rest.
- Graceful degradationLibrary ↗A readiness probe that takes every pod out of the Service turns a slow dependency into a total outage. Serving a reduced answer is usually the better failure mode.
- Rate limitingLibrary ↗Gateways and ingress controllers are where most clusters enforce per-client budgets. This is how those limits work and where to apply them.
- Leader electionLibrary ↗Controller managers and operators run several replicas but let only one act, using a Lease object in the API. This is the general technique.
Written for Kubernetes 1.33 and later; the links point to the current kubernetes.io documentation. Recent changes are called out where they matter: native sidecar containers (stable in 1.33), in-place pod resize (stable in 1.35), the IPVS proxy mode deprecation (1.35), the Gateway API as the recommended successor to Ingress, and the retirement of the ingress-nginx controller (March 2026). The manifests are complete examples that pass strict schema validation for Kubernetes 1.34; the shell output is illustrative.