mirror of
https://github.com/dredx/prole.git
synced 2026-09-23 12:03:59 +00:00
391c4f5fc9
GCE L7 Ingresses for knoe-svc-kong (svc.knoe.dev / api.knoe.dev),
supabase-kong (api.0.knoe.dev) and supabase-studio (db.0.knoe.dev) were
all stuck UNHEALTHY: the default GCE healthCheck is HTTP GET `/` on the
backend port, but Kong returns 404 on any unrouted path and Studio
returns a 301 redirect -- neither passes the default probe, so the LB
serves "Server Error" instead of reaching the pod.
Replicate the pattern already working for gitlab-webservice-default:
emit a BackendConfig CRD with a TCP healthCheck on the service port and
annotate the Service with cloud.google.com/backend-config so GCE picks
it up. TCP is sufficient for LB-level liveness -- the backend is "alive"
as long as the process is accepting connections.
- etc/init_kong.sh: new SVC_KNOE_BACKEND_CONFIG_NAME; apply BackendConfig
inside k8s/GCE branch; annotate Service post-apply.
- knoe-supabase chart: new kong/backendconfig.yaml + studio/backendconfig.yaml
(TCP on 8000 / 3000), gated on service.{kong,studio}.backendConfigName.
- knoe-supabase chart: kong/service.yaml + studio/service.yaml pick up
cloud.google.com/backend-config when backendConfigName is set.
- render_supabase.py: sets service.{kong,studio}.backendConfigName in k8s
mode so the above wires up automatically.
Separately, the chart-managed supabase-kong Ingress was being reaped
from the cluster seconds after helm install (manifest present in the
release, gone via `kubectl get`). Root cause TBD -- suspected
meta.helm.sh/* annotation ownership colliding with a GKE/Anthos audit
controller. Workaround: render_supabase.py now emits a standalone
public-ingress-kong.yaml (no helm metadata) that supabase/deploy.sh
applies alongside public-ingress-tls.yaml, and the chart template gains
an `ingress.externallyManaged` guard so it no-ops in k8s mode. Default
`false` keeps k3d/k3s behavior unchanged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
35 lines
1.2 KiB
YAML
35 lines
1.2 KiB
YAML
{{- /*
|
|
GCE L7 BackendConfig for supabase-kong.
|
|
|
|
GCE's default Ingress healthCheck is HTTP GET `/` on the backend port; Kong
|
|
returns 404 on any unrouted path, so the backend never goes HEALTHY and the
|
|
LB serves "Server Error" instead of reaching the proxy. A TCP healthCheck on
|
|
the Kong proxy port is sufficient for our deployment shape -- the backend is
|
|
"alive" as long as Kong is accepting connections, and GCE only probes for
|
|
reachability; per-route health is not required here.
|
|
|
|
The companion Service template (kong/service.yaml) annotates the Service
|
|
with cloud.google.com/backend-config so GCE picks this up.
|
|
|
|
Only rendered when .Values.service.kong.backendConfigName is set
|
|
(render_supabase.py populates it in k8s/GKE mode).
|
|
*/ -}}
|
|
{{- if and .Values.deployment.kong.enabled (.Values.service.kong.backendConfigName | default "") -}}
|
|
apiVersion: cloud.google.com/v1
|
|
kind: BackendConfig
|
|
metadata:
|
|
name: {{ .Values.service.kong.backendConfigName | quote }}
|
|
labels:
|
|
{{- include "supabase.labels" . | nindent 4 }}
|
|
spec:
|
|
healthCheck:
|
|
type: TCP
|
|
port: {{ .Values.service.kong.port | default 8000 }}
|
|
checkIntervalSec: 15
|
|
timeoutSec: 5
|
|
healthyThreshold: 1
|
|
unhealthyThreshold: 3
|
|
connectionDraining:
|
|
drainingTimeoutSec: 30
|
|
{{- end }}
|