At-most-one semantics guarantee that a StatefulSet never runs more than one pod with the same identity concurrently. Ordinal names such as quiz-1 provide that identity within a namespace. section 16.2.2
This guarantee matters during node failures. Unlike a ReplicaSet, a StatefulSet does not immediately create a replacement while the original pod may still be running on an unreachable node. section 16.2.2
A typical failure sequence looks like this:
- Disconnect a node; the control plane marks it NotReady and the affected pod eventually becomes Terminating. section 16.2.2
- Force-delete the pod when necessary; its replacement remains Pending until scheduling and storage constraints allow it to run. section 16.2.2
- Inspect scheduling and volume events, including unreachable-node taints, volume affinity conflicts, or a Multi-Attach error. section 16.2.2
Testing a disconnected node
With quiz-1 on kind-worker2, bring down that node's network interface. Observe kind-worker2 become NotReady and quiz-1 enter Terminating; after deletion, watch the replacement progress from Pending toward ContainerCreating. section 16.2.2
$ docker exec kind-worker2 ip link set eth0 down #1
Use the node-network command to reproduce the failure scenario in a kind cluster. section 16.2.2
