feat(helm): add liveness probes to match readiness probes (#445) - #7826
feat(helm): add liveness probes to match readiness probes (#445)#7826LuckTerence wants to merge 1 commit into
Conversation
📝 Contributor License Agreement requiredBefore this PR can merge, every contributor must sign the Infisical CLA. Still needs to sign: Once everyone has signed, the check updates automatically — no need to close and reopen the PR. |
|
| Filename | Overview |
|---|---|
| helm-charts/infisical-standalone-postgres/templates/infisical.yaml | Adds a liveness probe that can restart healthy application processes when PostgreSQL is unavailable because /api/status queries database-backed configuration. |
| helm-charts/infisical-nkp/templates/redis.yaml | Adds a conventional TCP liveness probe for the bundled Redis-compatible service without an established blocking defect. |
Reviews (1): Last reviewed commit: "feat(helm): add liveness probes to match..." | Re-trigger Greptile
| livenessProbe: | ||
| httpGet: | ||
| path: /api/status | ||
| port: 8080 | ||
| initialDelaySeconds: 30 | ||
| periodSeconds: 20 |
There was a problem hiding this comment.
When PostgreSQL is unavailable or slow, /api/status fails because it performs a database-backed configuration lookup, so this liveness probe repeatedly restarts an otherwise recoverable Infisical process and delays recovery.
Knowledge Base Used: Kubernetes Helm packaging
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cffc339990
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| initialDelaySeconds: 30 | ||
| periodSeconds: 20 |
There was a problem hiding this comment.
In the standalone chart, the container does not start serving /api/status until after startup migrations complete: backend/src/main.ts calls runMigrations() before server.listen, and the migration startup lock can wait up to 5 minutes in backend/src/auto-start-migrations.ts. With this new liveness probe starting after 30s and running every 20s, an upgrade or first boot with long migrations, or the default two replicas where one pod waits on the lock, can be restarted by kubelet before it ever binds port 8080, causing CrashLoopBackOff instead of letting migrations finish; use a startupProbe or make the liveness window cover the migration/lock wait.
Useful? React with 👍 / 👎.
Closes #445
The issue predates the chart restructure, so this applies the same intent to the current charts: workloads that only had a
readinessProbenow get a matchinglivenessProbe, so stuck pods get restarted by kubelet instead of just being taken out of rotation.Changes
helm-charts/infisical-standalone-postgres/templates/infisical.yaml: addlivenessProbe(httpGet/api/status:8080, initialDelay 30s / period 20s) next to the existing readiness probe — this chart serves the combined front/back workloadhelm-charts/infisical-nkp/templates/redis.yaml: addlivenessProbe(tcpSocket on the redis port, initialDelay 15s / period 20s)The
infisical-nkpbackend deployment already had both probes; its values (30s/20s for liveness) were used as the reference pattern.Verification
helm lintpasses on both charts (0 failed)helm templateoninfisical-nkprenders the new redis liveness probe correctlyhelm templateon the standalone chart could not be run locally only because Docker Hub rate-limited the bitnami subchart download (429); the added block is static YAML mirroring the adjacent readiness probe