Repository navigation
Adapt startDelay to control the startupProbe #2843
Description
As emerged in discussion #2835, the default value of startDelay is not helping deployment of Postgres in a common scenario, as it is too low (30 seconds).
Given that now startup probes are in every available Kubernetes distribution, it makes sense to explore the possibility to divert the current setup (which sets initialDelaySeconds of the liveness probe) make use of startup probes.
This is the current implementation:
livenessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: 8000
scheme: HTTP
initialDelaySeconds: <startDelay>
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
readinessProbe:
failureThreshold: 3
httpGet:
path: /readyz
port: 8000
scheme: HTTP
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
This patch is about making this change:
startupProbe:
failureThreshold: <FAILURE_THRESHOLD>
httpGet:
path: /healthz
port: 8000
scheme: HTTP
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
livenessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: 8000
scheme: HTTP
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
readinessProbe:
failureThreshold: 3
httpGet:
path: /readyz
port: 8000
scheme: HTTP
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
where FAILURE_THRESHOLD = ceiling(startDelay / periodSeconds) and periodSeconds is by default set to 10 seconds and FAILURE_THRESHOLD minimum value is 1.
At the same time, change the default startDelay to 3600 seconds.
Metadata
Metadata
Assignees
Labels
No labels
Activity
feat: change default value of `startDelay` to 3600 (#2847)
feat: change default value of `startDelay` to 3600 (#2847)
feat: change default value of `startDelay` to 3600 (#2847)