-
Notifications
You must be signed in to change notification settings - Fork 65
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
Add carbonplan cluster + hubs #391
Conversation
I've deleted everything and recreating it from scratch.
|
When rotating the master, you might run into kube-dns not evicting since that would violate its pdb. You can temporarily work around this by reducing the availability guarantee:
However, once done, you should undo the change
|
OK, I left some comments, I will try to deploy this one from scratch tomorrow and report back how it goes! |
I am pretty sure that was the problem preventing my kops rolling-update to succeed... |
- staging and prod clusters that are exactly the same, with just domain differences - Uses traditional autohttps + LoadBalancer to get traffic into the cluster. Could be nginx-ingress later on if necessary. - Manual DNS entries for staging.carbonplan.2i2c.cloud and carbonplan.2i2c.cloud. Initial manual deploy with `proxy.https.enabled` set to false to complete deployment, fetch externalIP of `proxy-public` service, setup DNS, then re-deploy with `proxy.https.enabled` set to true. Ref 2i2c-org#291
We have three sets of labels: 1. What components of a JupyterHub can run here? core / user 2. What components of a dask gateway can run here? core / scheduler / worker 3. What are the features of the node pool we care about? For example, if we want to be on an r5.xlarge node, we should target the existing node.kubernetes.io/instance-type label This gives us flexibility without adding too much overhead.
dask-gateway requires that the image used for it contains the `dask-gateway` package. The scheduler image is the same image as the user notebook image, to make sure that versions match. The previously used image did not have dask-gateway installed
Otherwise it doesn't know which instance group to scale up when a pod wants a node with that label
With 2i2c-org@3c344a4, we're trying to normalize labels in our clusters. Primarily, we want to have three sets of labels that can be composed as needed. 1. What components of a JupyterHub can run here? core / user 2. What components of a dask gateway can run here? core / scheduler / worker 3. What are the features of the node pool we care about? For example, if we want to be on an r5.xlarge node, we should target the existing node.kubernetes.io/instance-type label This gives us flexibility without adding too much overhead. 2i2c-org#391 changes the base hub template to use these new labels. We should change our GKE clusters to have these labels too before we can deploy that PR. This PR adds these labels in addition to the existing labels, to avoid any disruption
I'll need to deploy and merge #397 first before merging this, so as to not break existing clusters. |
Ok this one is ready to merge :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have been reviewing this one as it was evolving.
Last final check LGTM
This is great @yuvipanda!
Feel free to push the green button!
@damianavila done! |
with just domain differences
into the cluster. Could be nginx-ingress later on if necessary.
carbonplan.2i2c.cloud. Initial manual deploy with
proxy.https.enabled
set to false to complete deployment,fetch externalIP of
proxy-public
service, setup DNS,then re-deploy with
proxy.https.enabled
set to true.Depends on #389 and #390
Ref #291