Distributed Locking in Kubernetes
summary
Distributed locking in Kubernetes compares concrete implementations: single-instance cache (Hazelcast/Redis) for efficiency only, Hazelcast cluster and Redis Redlock for higher availability, and consensus-based CP/etcd/Zookeeper for stronger consistency. It states leases (Kubernetes Lease resource or ConfigMap) require renewal, shows Redlock needs clock sync and can still fail if a process stalls, and demonstrates a working fenced approach using monotonic fencing tokens with CP/raft to guarantee correctness at the cost of complexity and lower throughput.
AI-written summary · about
chapters (9)
- 0:00Why distributed locks matter
- 5:02Single instance lock manager
- 10:25Clustered lock manager issues
- 17:15Redlock algorithm explained
- 23:24Consensus-based locking
- 28:01Kubernetes-native locking
- 31:15Fencing tokens for correctness
- 40:55Choosing the right strategy
- 42:39Resources and thanks
related talks
48mHow to build distributed concurrency primitives
45mjava.util.concurrent for Distributed Coordination
20mJeff Klink, Sera4 | KubeCon + CloudNativeCon Europe 2020 – Virtual
34mDistributed applications and Kubernetes
23mProtecting your resources with sanlock
41mKubernetes Security Jumpstart
47mjava.util.concurrent for Distributed Coordination
29mReliable and Cost-Effective: Open Storage Strategies for Kubernetes