You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We typically run with a 3-worker node Kubernetes cluster, and run the cstor services with 3 replicas for resiliency. Usually Kubernetes will spread the 3 pods across the 3 worker nodes. However, if a worker node should go down, Kubernetes will schedule a replacement pod on one of the other worker nodes. This puts things into an un-balanced situation where one worker is running two replicas for the service. We would like to be able to turn on pod anti-affinity for these services so that when one worker node goes down, when Kubernetes schedules a replacement pod the pod will get stuck in Pending state until the missing worker node returns, and will then get scheduled on the third node. This would avoid the need to do manual pod rebalancing after a worker node outage.
Here is an example of what is running in our cluster:
We typically run with a 3-worker node Kubernetes cluster, and run the cstor services with 3 replicas for resiliency. Usually Kubernetes will spread the 3 pods across the 3 worker nodes. However, if a worker node should go down, Kubernetes will schedule a replacement pod on one of the other worker nodes. This puts things into an un-balanced situation where one worker is running two replicas for the service. We would like to be able to turn on pod anti-affinity for these services so that when one worker node goes down, when Kubernetes schedules a replacement pod the pod will get stuck in
Pending
state until the missing worker node returns, and will then get scheduled on the third node. This would avoid the need to do manual pod rebalancing after a worker node outage.Here is an example of what is running in our cluster:
The text was updated successfully, but these errors were encountered: