Files
helm-charts/zipline/values.yaml
T
jklein 7f1ef4055f Refine probes based on k3d cluster verification
Every chart was installed twice in a throwaway k3d cluster (origin/main
vs this branch) with real Postgres/Redis/dex instances and observed for
readiness ordering, stability and dependency-outage behavior. Findings:

- voucher-vault: Django only accepts Hosts 127.0.0.1 and the configured
  DOMAIN; the default probe Host (pod IP) always got 400. Probes now
  send 'Host: 127.0.0.1'.
- zipline: /api/healthcheck includes the database, so liveness now uses
  '/' (readiness/startup keep /api/healthcheck). Verified live: on a
  Postgres outage the pod turns NotReady within 30s and is never
  restarted by the kubelet.
- outline: '/' also returns 500 when the database is down, so there is
  no dependency-free endpoint; all three probes use /_health.
2026-08-21 18:44:13 +02:00

45 lines
1.2 KiB
YAML

config:
storage: 50Gi
storageClass: longhorn
secretRef:
db: null
zipline: null
domain: null
maxUploadFileSize: 30m
zipline:
# Zipline v4 exposes /api/healthcheck (checks server and database health);
# the endpoint is enabled by default (config.features.healthcheck). Since it
# includes the database, it is used for readiness/startup only; liveness
# uses "/" so a database outage does not restart the pod.
livenessProbe:
httpGet:
path: /
port: zipline-server
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /api/healthcheck
port: zipline-server
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
# The startup probe gates liveness/readiness. Zipline runs database
# migrations on startup, so grant a generous budget: 10s * 30 = 300s.
startupProbe:
httpGet:
path: /api/healthcheck
port: zipline-server
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 30
resources:
requests:
cpu: 0.1
memory: 265Mi
ephemeralStorage: 100Mi
limits:
cpu: 1
memory: 768Mi
ephemeralStorage: 200Mi