Зачем нужен сентинал, когда кластер Redis развернут на Kubernetes?

Отправлено: Документы говорят

Redis Sentinel обеспечивает высокую доступность Redis. На практике это означает, что с помощью Sentinel вы можете создать развертывание Redis, которое без вмешательства человека устойчиво к определенным видам сбоев.

Я думаю, что мы можем достичь Sentinal возможностей кластера Redis (в K8s) без развертывания Sentinal? Я беру дозорные возможности из документации и подбрасываю кое-какие контраргументы от K8s.

• Monitoring - Sentinel constantly checks if your master and slave instances are working as expected.
  • I'm considering working as expected means pod up or down. This is very native in K8s when you deploy as Deployment(Replicasets) or even StatefulSets
• Notification - Sentinel can notify the system administrator, another computer programs, via an API, that something is wrong with one of the monitored Redis instances.
  • Can't we do it with Operators?(In perspective of redis cluster state, etc )
• Automatic failover - If a master is not working as expected, Sentinel can start a failover process where a slave is promoted to master, the other additional slaves are reconfigured to use the new master, and the applications using the Redis server informed about the new address to use when connecting.
  • I'm considering not working as expected means redis pod is down. In this case, if we deploy redis with help of Operators/StatefulSet+Headless Service. We have stable network ID for master/slaves even pods restart.
• Configuration provider - Sentinel acts as a source of authority for clients service discovery: clients connect to Sentinels in order to ask for the address of the current Redis master responsible for a given service. If a failover occurs, Sentinels will report the new address.
  • As I said in above point, we have the stable network id/name/IP. Clients can always point to a master.

Я новичок в Redis. Пожалуйста, помогите мне, если что-то не так. Спасибо.

Обновление1

Моя цель - избежать сентинала и иметь высокую доступность (в основном master аварийное переключение)