Redis Sentinel cluster bootstrap takes too long on initial startup

[rinatvafin]

Hello.

Has anyone faced an issue with the initial startup of a 3-node Redis Sentinel cluster?
During startup, the init container of the first pod checks for the existence of a Redis master node. Since the second and third pods are not created yet, each check takes about 240 seconds to time out in my environment.
As a workaround, I added explicit timeouts to the init container scripts, for example:

EXISTING_MASTER=$(redis-cli -t 5 ...)

This significantly reduced the bootstrap time.
However, I’m not sure if this is the correct or recommended approach, or if the initial startup logic should be handled differently.
With the default init script, the initial bootstrap of a 3-node Redis Sentinel cluster takes 10+ minutes, which seems excessive.
Any suggestions or best practices would be appreciated.

[zOnlyKroks]

During initial bootstrap, the init container loops through all sentinel pods (0, 1, 2) trying to query for an existing master. Since these pods don't exist yet on first startup, each redis-cli connection waits for the TCP connection timeout (~240 seconds) before failing. Adding explicit timeouts like redis-cli -t 3 or redis-cli -t 5 to these discovery queries reduces bootstrap time from 10+ minutes to under 30 seconds by failing fast instead of waiting for TCP timeouts.

I am planning to implement a fix for this in the near future.