[stable/redis-ha] Added HAProxy to support exposed Redis environments.

[DandyDeveloper]

What this PR does / why we need it:

There's a fundamental problem that numerous people are experiencing with this chart and being accessed externally.

This PR aims to provide an added proxy that performs Redis / Sentinel healthchecks to establish the master and proxy to that master without the client needing to infer the master IP from Sentinel.

It seems to be working, the only problem is, the chart currently means Sentinel occasionally is reporting s_down and forcing the master into a "READ-ONLY" state. I will raise this separately.

Which issue this PR fixes

• Fixes [stable/redis-ha] Can't connect to Redis from outside the Kubernetes cluster #14492
• Fixes [stable/redis-ha] READONLY You can't write against a read only replica #12851

Special notes for your reviewer:

@ssalaues If you don't mind, I'd like to be a contributor to this, and help you maintain for the future.

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

• DCO signed
• Chart Version bumped
• Variables are documented in the README.md
• Title of the PR starts with chart name (e.g. [stable/chart])

[k8s-ci-robot]

Hi @DandyDeveloper. Thanks for your PR.

I'm waiting for a helm member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[DandyDeveloper]

/assign @ssalaues

[ssalaues]

@DandyDeveloper This looks great and should alleviate a lot of the headaches people report with trying to contact the master directly. I'll test this out on my cluster as well so I can better understand the behavior.

@ssalaues If you don't mind, I'd like to be a contributor to this, and help you maintain for the future.

Yeah definitely add yourself as a contributor. I would greatly appreciate the help and you seem like you have an active interest in this chart as well.

This PR aims to provide an added proxy that performs Redis / Sentinel healthchecks to establish the master and proxy to that master without the client needing to infer the master IP from Sentinel

So before I took over maintenance of this chart, it was setup with a "master" service. It worked with the idea was that the pods themselves had RBAC permissions to update their own labels so that anytime a new master was elected, the correct pod would be updated with the correct Kubernetes label. This way the service and the selector always pointed to the master server. However the implementation was very buggy and caused more problems than it solved which is why I removed it for the sake of reliability of the service. This is something that has been on my plate to reliably reimplement as a feature but simply haven't had enough time to see it through.

With that said, my first impression is that while I strongly agree with the motivation behind this PR, it seems that adding an HAproxy deployment to the chart seems excessive when this could be possible in a very Kubernetes native way.

[ssalaues]

/lgtm

[DandyDeveloper]

/verify-owners

[JanMatas]

Hi, thanks for great PR. I encountered the problem you are solving so I tried using this even before it gets merged. I had a problem that nodeSelector is applied to HAProxy deployment but tolerations are not, so the HAProxy pods were not schedulable in my cluster. At least for me, the expected behaviour would be to include tolerations in HAProxy deployment spec as well.

[ssalaues]

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: DandyDeveloper, ssalaues

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• stable/redis-ha/OWNERS [ssalaues]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ssalaues]

@DandyDeveloper @JanMatas I'm approving this since this PR is in a stable state and has been open for quite some time now. But the issue you bring up should be a fairly easy minor fix.

[Deepak-Routray]

@DandyDeveloper Thanks for getting this merged and for resolving the issue. Great Work!!