The user-scheduler deployment current has a desired size 2
spec:
replicas: 2
Only 1 user-scheduler pod can be active at a time.
1 user-scheduler pod acquires the leader-lock, and handles user requests for new hubs.
The other user-scheduler just waits.
I0723 23:54:51.705523 1 leaderelection.go:352] lock is held by user-scheduler-fc9c5b9bf-2chsl_184ca957-05ce-404b-867c-4ff2438352d4 and has not yet expired
I0723 23:54:51.705546 1 leaderelection.go:253] failed to acquire lease jupyterhub/user-scheduler-lock
This is a good pattern for highly available applications, but
I don't think the user-scheduler goes down frequently.
user-scheduelr doesnt take long to start up
the hub pod doesn't have a backup
So its not clear if this is offering any benefit at all.
The user-scheduler deployment current has a desired size 2
Only 1 user-scheduler pod can be active at a time.
1 user-scheduler pod acquires the leader-lock, and handles user requests for new hubs. The other user-scheduler just waits.
This is a good pattern for highly available applications, but
So its not clear if this is offering any benefit at all.