Migrating from Redis Sentinel (Bitnami Helm on EKS) to Valkey: Sentinel/Failover Support, Helm Deployment, and Zero-Downtime Master Switchover.

[ariefshaik7]

Valkey Sentinel HA on Kubernetes: Can it Avoid the Redis/Bitnami Failover Issues We Encountered on EKS?

Hi Valkey community,

We're evaluating a migration from Redis OSS to Valkey and would like to understand the current state of Valkey HA deployments on Kubernetes, particularly for Sentinel-based failover.

Current Environment

• Amazon EKS
• Bitnami Redis Helm chart
• StatefulSet deployment
• 1 master + 2 replicas
• Redis Sentinel enabled
• Persistent volumes

The Problem We Ran Into

Our issue is not that Sentinel failed to elect a new master. Failover eventually worked, but the operational behavior during failover caused application impact.

We traced the problem to a combination of Bitnami chart defaults and Sentinel configuration:

1. Hardcoded preStop behavior

The chart executes:

CLIENT PAUSE 22000 WRITE

during pod termination.

This caused client connections to freeze for ~22 seconds. Instead of receiving a clean disconnect and reconnecting to a new master, applications experienced request timeouts and ETIMEDOUT errors.

2. Sentinel downAfterMilliseconds default

The deployment was using:

downAfterMilliseconds: 60000

which meant Sentinel waited up to 60 seconds before considering the master unavailable.

This significantly delayed failover initiation.

3. Pod termination immediately after failover

After failover was triggered, the pod could terminate before clients had fully discovered and switched to the new master.

To improve behavior, we ended up modifying Helm chart configuration and lifecycle handling around Sentinel failover, preStop hooks, and timing parameters.

Questions About Valkey

1. Does Valkey support the same Sentinel architecture (1 master + replicas + Sentinel) in production Kubernetes environments?

2. Is there an official Valkey Helm chart that supports:

   • Replication
   • Sentinel
   • Persistent storage
   • StatefulSet-based HA deployments

3. For teams running Valkey with Sentinel in production:

   • How do you handle graceful failover during node termination?
   • Are there recommended lifecycle hooks or Kubernetes patterns?
   • Have you encountered similar issues with CLIENT PAUSE behavior during pod shutdown?

4. Are there recommended Sentinel settings for Kubernetes deployments?

   • down-after-milliseconds
   • failover-timeout
   • quorum
   • pod termination grace periods

5. Is the operational experience materially different from Redis OSS, or would we expect to maintain similar customizations around failover behavior and lifecycle management?

6. Has anyone migrated from the Bitnami Redis Sentinel chart to a Valkey-based deployment?

   • What chart/operator did you use?
   • Did it reduce the amount of failover-related tuning required?

Goal

We're looking for a highly available in-cluster cache/data store on EKS where planned or unplanned master failovers cause minimal application disruption.

The main question is whether Valkey provides a cleaner operational path for Sentinel-based HA on Kubernetes, or whether the same lifecycle and failover tuning is still required.

Any production experiences, recommendations, or migration stories would be greatly appreciated.