仓库指标
- Star
- (2,871 star)
- PR 合并指标
- (PR 指标待抓取)
描述
Description: I'm working on repackaging the helm chart for use in a different system and noticed that the main deployment has liveness and readiness but not startup probe.
Liveness:
livenessProbe:
httpGet:
path: /healthz
port: 8081
initialDelaySeconds: 15
periodSeconds: 20
Readiness:
readinessProbe:
httpGet:
path: /readyz
port: 8081
initialDelaySeconds: 5
periodSeconds: 10
If a startup probe was included that referenced the same liveness end point ie /healthz then the initial delay could be dropped from both other probes and the startup probe could be more frequent eg 1s or 2s and it would guarantee fastest route to readiness.
If the hard coded delays overshoot you're waiting too long for no reason. If the hard coded delays undershoot you get failures that then need to be verified good delaying the readiness.
Am I missing something? Is there are a good reason for this that I'm ignorant of? Seems like an easy win. :-)
Repro steps: Read helm charts or render out and then read since helm is all but unreadable.
Environment: v1.3.0 < latest AFAIK