The operator is currently running as a normal workload with a relatively low API priority level. This means that the API server gives requests coming from the operator the same priority as all other requests from any other workload. See https://kubernetes.io/docs/concepts/cluster-administration/flow-control/ for more information on how the API server provides priority and fairness to API clients.

There is a special priority level called leader-election that's supposed to be used for leader-election requests. In 2.5.1, some users reported that the operator lost its leader status. The logs showed that this was because the lock update request was taking more than the allotted 10s. This could be prevented by defining a FlowSchema for the operator.

The operator should use the leader-election priority for its leader-election requests, and a workload-high for all its other requests. Currently, it's using the workload-low priority for all.