mirror of
https://github.com/dredx/prole.git
synced 2026-09-24 17:34:31 +00:00
9738ae22dc
Second instance of the "chart Ingress ghosts out of the cluster shortly after helm install" pattern. Earlier we worked around it for the kong ingress by emitting a standalone manifest; studio/ingress.yaml now shows the same symptom -- helm creates it, cluster reports `supabase-studio is missing` seconds later, db.0.knoe.dev returns ERR_CONNECTION_CLOSED. Rather than duplicate the externally-managed workaround for a second ingress, this retires studio's ingress entirely and merges db.0.knoe.dev onto the already-working supabase-kong ingress. Kong's declarative config has always had a `dashboard` service block that forwards `/` to supabase-studio:3000 (templates/kong/config.yaml). So traffic for db.0.knoe.dev flowing through supabase-kong lands on Studio exactly the same way it would have through the separate ingress, just with one extra hop through Kong. From a user perspective: identical. From our perspective: one ingress, one static IP, one BackendConfig, no ghosting for Studio. GCE supports multiple ManagedCertificates per ingress via a comma-separated `networking.gke.io/managed-certificates` annotation; each cert covers its own SAN. We already had both supabase-api-managed-cert (api.0.knoe.dev) and supabase-studio-managed-cert (db.0.knoe.dev) Active, so stitch them both onto the shared kong ingress and SNI routes cleanly. Changes in supabase/helm/render_supabase.py: - `studioIngress.enabled` flips to false in k8s mode (chart's studio/ingress.yaml is already gated on this value, so it no-ops) - `service.studio.backendConfigName` cleared in k8s mode (chart's studio/backendconfig.yaml and the studio Service annotation both gate on this, so they no-op too -- single source of truth stays in render_supabase.py) - Standalone kong-ingress generator now merges studioIngress.hosts as additional rules, same supabase-kong:8000 backend (Kong handles the internal routing to Studio) - Same generator merges studio's ManagedCertificate into the kong ingress annotation as a comma-separated cert list Studio's Service keeps existing (needed for Kong's in-cluster `http://supabase-studio:3000` upstream). Only the public-facing Ingress and BackendConfig go away. Deployment-side follow-ups (not code): - db.0.knoe.dev DNS must be repointed from 136.110.189.6 (the supabase-studio static IP) to 34.120.221.5 (the supabase-api static IP, which is what this merged ingress is bound to). - Once DNS is cut over, the supabase-studio global static IP is orphaned and can be released to free the quota slot. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| generated | ||
| knoe-supabase | ||
| render_supabase.py | ||