Conversation
|
Ah one thing I'm super sure about: Are we 100% sure that we can unconditionally include the readiness probe? Because if I remember correctly, it is tied to the webhook, which in turn is tied to the CRD maintenance toggle. This will be improved by stackabletech/issues#839, but that is not implemented yet. |
| scheme: HTTPS | ||
| periodSeconds: 2 | ||
| failureThreshold: 30 | ||
| timeoutSeconds: 3 |
There was a problem hiding this comment.
It felt weird to have timeout > period, so I asked AI:
timeoutSeconds (3) is larger than periodSeconds (2). The kubelet doesn't run probes in parallel, so nothing breaks, but probes that time out end up running back-to-back every ~3 s. Your startup budget then varies between 60 s (fast failures like connection refused) and about 90 s (timeouts), which makes the config harder to reason about. Keep timeout ≤ period. For example, periodSeconds: 3, timeoutSeconds: 3, failureThreshold: 20 gives a clean 60 s.
And I fully agree with it
| startupProbe: | ||
| httpGet: | ||
| path: /ready | ||
| port: 8443 |
There was a problem hiding this comment.
nit: A named port (in this case we could call it webhook I guess) avoids drift if the port number ever changes.
3 participants
Part of stackabletech/issues#828. Adds the startup probe checking the
/readyendpoint for CRD install status. The/readyendpoint is already served by the operators, only one would still need a merge before rolling this change out:/readyendpoint to operator deployment commons-operator#461