From 23f3f14b7fc3f8cb6ce0119c70452e31bf1582da Mon Sep 17 00:00:00 2001 From: chrisfu Date: Tue, 21 Apr 2026 14:50:09 -0700 Subject: [PATCH] fix(supabase): kong pod needs checksum annotation to rollout on ConfigMap change Follow-up to 0f2fe93. Live post-deploy diagnostics showed that even though helm upgrade rewrote the supabase-kong ConfigMap with the new /healthz route, the existing Kong pod kept serving the old config: the Deployment spec itself never changed, so no rolling restart happened. Kong loads /usr/local/kong/kong.yml at startup and doesn't watch the file, so the healthcheck probe against /healthz got 404 and the GCE backend stayed UNHEALTHY. api.0.knoe.dev stayed broken. Standard helm workaround: annotate the pod template with a sha256 of the ConfigMap template. Any content change bumps the hash, which changes the Deployment spec, which triggers a rolling restart. Pattern matches what vector/deployment.yaml in this chart already does and is widely used in the bitnami / ingress-nginx charts. Studio has no ConfigMap volume mount (verified via grep), so no equivalent annotation is needed there. This lands the permanent B.1 fix from the plan. Whether the live Kong pod needs a manual `kubectl rollout restart` to pick up the current REVISION 2 config -- or whether the /healthz service URL itself is tripping Kong's parser -- is still to be determined from Part A diagnostics before any B.2 / B.3 edits. Co-Authored-By: Claude Opus 4.7 (1M context) --- .../knoe-supabase/templates/kong/deployment.yaml | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/supabase/helm/knoe-supabase/templates/kong/deployment.yaml b/supabase/helm/knoe-supabase/templates/kong/deployment.yaml index 1fe9a5d..64811b0 100644 --- a/supabase/helm/knoe-supabase/templates/kong/deployment.yaml +++ b/supabase/helm/knoe-supabase/templates/kong/deployment.yaml @@ -14,10 +14,20 @@ spec: {{- include "supabase.kong.selectorLabels" . | nindent 6 }} template: metadata: - {{- with .Values.deployment.kong.podAnnotations }} annotations: + # Tie pod spec to the ConfigMap content hash so `helm upgrade` triggers + # a rolling restart whenever kong/config.yaml changes. Without this, + # ConfigMap-only changes (like adding a new route) land silently: the + # file in /usr/local/kong/template.yml updates via the ConfigMap + # volume mount, but Kong loaded declarative config at startup and + # doesn't re-read the file on its own -- old pods keep serving stale + # config and the new route (e.g. /healthz) is never live. Learned this + # the hard way when `helm upgrade` added /healthz but the GCE LB + # health check kept getting 404 because live Kong didn't have it. + checksum/config: {{ include (print $.Template.BasePath "/kong/config.yaml") . | sha256sum }} + {{- with .Values.deployment.kong.podAnnotations }} {{- toYaml . | nindent 8 }} - {{- end }} + {{- end }} labels: {{- include "supabase.kong.selectorLabels" . | nindent 8 }} spec: