-
Notifications
You must be signed in to change notification settings - Fork 61
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
Use nginx-ingress as entrypoint for all hubs #594
Comments
So this means we are deploying support in all our clusters, right? I would agree with that. |
I'm setting this as medium priority and adding to our backlog now...these kinds of "standardize and simplify our infrastructure" issues seem particularly important to make sure that we can iterate quickly and without confusing ourselves in the future |
AFAIK, we have support deployed in all of our clusters. |
This is done now, thanks to @GeorgianaElena! |
For future readers, Farallon is being decommissioned here: #1454. |
For some hubs that don't have the support chart deployed (#388), we use individual LoadBalancer IPs to expose the hubs. This prevents easily exposing something like grafana, and also adds complexity - some hubs use LoadBalancer, and some use nginx-ingress.
We should move everything to nginx-ingress, and new hubs should all use the nginx-ingress entrypoint.
We need to move the following hubs:
We can do so by:
support/
namespaceproxy.https.enabled
tofalse
for the hub, and unsetproxy.service.type
. Do a deploy immediately. Theautohttps
deployment should go away, andproxy-public
should change type. You might have to delete theproxy-public
service before doing a deploy, or the deploy might fail, since it'll try to change the service from a LoadBalancer to a ClusterIP (and this is often not fully supported)This might lead to a minute or two of downtime, so has to be done at a time that'll hopefully affect nobody.
The text was updated successfully, but these errors were encountered: