Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any configuration available for browsers should wait till instances are available #8

Open
gs-skreddy opened this issue Jul 25, 2022 · 1 comment

Comments

@gs-skreddy
Copy link

gs-skreddy commented Jul 25, 2022

Currently we deployed callisto in kubernetes. We are facing one issue that
suppose if all the worker node resources are exhausted and still there are some more browser pods are pending for scheduling
then we are observing that by that time of new worker nodes comes up

  1. pods are not waiting in pending state, but expectation is they should be in pending state till new nodes comes up.
  2. they are waiting for 20sec and scheduling in already exhausted nodes, hence those nodes are restarting

note: we are using t3.xlarge instance types for worker nodes but planning to move to c5.xlarge
Is there any configuration for browser pods to wait till new worker nodes comesup?

@srntqn
Copy link
Member

srntqn commented Jul 26, 2022

@gs-skreddy Hi!

Callisto doesn't schedule pods, it just requests new resource (browser pod) using Kubernetes API.

Looks like you need to check your k8s scheduler configuration, usually scheduler is quite rational at pods placement and it's trying to avoid the nodes with the resources pressure.

Regarding Callisto resources you can change the browser pods manifest or use helm values to introduce things like tolerations and affinity. It can be helpful if you want to improve scheduling in your cluster.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants