Revision poster: how a request becomes cluster state.
Top row: the four gates a request passes. Middle: how etcd stays consistent and healthy. Bottom: the loop that turns stored intent into reality.
- 1The request passes authentication, authorization and admission in that order.
- 2Only then is it written to etcd, and only the API server talks to etcd.
- 3Use 3 or 5 etcd members: quorum is floor(n/2)+1, so 4 tolerates no more failures than 3.
- 4Compact, then defragment, one member at a time, or NOSPACE rejects all writes.
- 5Controllers observe, compare and act forever; that loop is the self-healing.
- 6Leader election lets several replicas run while only one reconciles.
Self-check: cover the poster and answer
- Why does a 4-member etcd cluster not improve on a 3-member one?
- Which stage rejects a Pod that exceeds a ResourceQuota?
- Why is mutation run before validation?
Every request passes authentication, authorization and admission before etcd, and controllers then reconcile forever.