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.
45 lines
1.2 KiB
YAML
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 |