Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
leader election bugfix: Delete evicted leader pods
Before this patch, when the leader pod is evicted but not deleted, the leader lock configmap is not garbage collected and subsequent operaters can never become leader. With this patch, an operator attempting to become the leader is able to delete the evicted operator pod, triggering garbage collection and allowing leader election to continue. Sometimes, evicted operator pods will remain, even with this patch. This occurs when the leader operator pod is evicted, a new operator pod is created on the same node. In this case, the new pod will also be evicted. When an operator pod is created on a non-failing node, leader election will delete only the evicted leader pod, leaving any evicted operator pods that were not the leader. To replicate the evicted state, I used a `kind` cluster with 2 worker nodes with altered kubelet configuration: `memory.available`: Set about 8Gi less than the host machine `avail Mem` from `top`. `evictionPressureTransitionPeriod: 5s`: Allows kubelet to evict earlier. With these settings in place (and kubelet restarted), a memory-explosion function is triggered, which results in the eviction of all pods on that node. operator-framework#1305 Fixes operator-framework#1305 operator-framework#1874 Fixes operator-framework#1874
- Loading branch information