Kubernetes State
Config, volumes and stateful workloads — why a database is not a stateless API with a disk attached, and where the abstraction stops helping.
Two objects that inject configuration into pods, one of which is named after a security property it does not, on its own, provide.
A container filesystem dies with the container. A volume is a way of saying which data outlives what — the pod, the node, or the cluster — and each answer has different failure modes.
A stateless replica is interchangeable and can be replaced at any moment. A database replica has an identity, a copy of the data, a position in a replication stream and an opinion about who is the leader.
The workload controller that gives each replica a stable name, its own volume and a defined position in startup and rollout — which makes running stateful systems possible, not advisable by default.
The recurring mistakes that produce most cluster incidents — each one reasonable at the moment it is made, and each one with a specific failure it eventually causes.