search

bitnami / charts

Bitnami Helm Charts
https://bitnami.com
Other
8.9k stars 9.17k forks source link

seperating redis and sentinel container from a single pod #17038

Open abhishekGupta2205 opened 1 year ago

abhishekGupta2205 commented 1 year ago

Name and Version

bitnami/redis , latest

What is the problem this feature will solve?

in present , if i enable sentinel in my helm chart then 2 containers will be formed inside one single pod only . As i need minimum of 3 sentinel , so i need to spawn 3 pods , which needs more cpu and memory . INstead if we seperate the containers in differnt pods and can customise the no of redis servers and no of sentinel pods needed , more resources can be saved.

What is the feature you are proposing to solve the problem?

resources consumption will be reduced . if i need only 2 redis servers , one master and one replica , i need to create 3 pods for fulfilling sentinel quorum.

What alternatives have you considered?

No response

andresbono commented 1 year ago

I think your feature request makes sense. You are using this cluster topology: Master-Replicas with Sentinel , right? Can you share the values of architecture and replicas you are using?

abhishekGupta2205 commented 1 year ago

@andresbono , currently my architecture is amd64 and my replica count is 3 as minimum i need 3 sentinels . yes , i am using master -slave with sentinel .

andresbono commented 1 year ago

Redis was using IP addresses to be configured before useHostnames was implemented. This can be one of the reasons why sentinels were tied to the workload containers (master/replicas).

As you will need 3 sentinels for a robust deployment, I would suggest that you use replicaCount: 3 even though you only need 1 master and 1 replica. Basically what you are currently doing.

Nevertheless, we will try to review the chart as a whole looking for possible improvements, taking into account your feature request.

github-actions[bot] commented 1 year ago

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

troll-os commented 3 months ago

Beside resource consumption, the pattern of having 3 sentinels decoupled might allow to ensure Quorum.

I want to migrate away from an operator that doesn't work well in cases of failovers

I'm currently testing failover on this chart with a replicaCount to 3, if I lose 2 sentinel nodes (in the actual coupled setup) the last failover never occurs, my application which relies on streams hangs forever or at best will hit a "Can't write again read-only replica" type of error.

Any updates on this ?