-
Notifications
You must be signed in to change notification settings - Fork 364
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add master and slave redis services #627
Conversation
Good one again! Is follow master pod if master changes? |
It does. Both Master and Replica services use label selectors to select their corresponding pods. So, when the master changes, their selected pods change too. As for the clients who are using these services, since these aren't headless services, the clients wouldn't notice any changes in the IP of the master or replica pods, and as long as the services select their corresponding pods correctly, the clients won't confuse master and replicas with each other. |
I am not sure labels change, see #608 |
The functionality is definitely implemented. Nonetheless, I will try reproducing it and share the results on that issue thread. |
Thanks! |
@hashemi-soroush was it on porpose to use |
@ese there are a number of reasons I chose the I assume the users of this operator come from two groups:
The first group probably starts its infrastructure with a single Kubernetes cluster, but, in my experience, quickly realises Kubernetes isn't a good fit for hosting stateful software off-the-shelf. It needs several configuration customisations which most likely makes the cluster not-well-suited for stateless software. So, it's best to have at least two clusters, one for stateful software and the other for stateless. Now, obviously you need to enable communication between the two clusters, so every database must be exposed externally one way or another. Also, to keep the database safe from the possibility of weak load balancing by its clients, which can result in the downtime of the database, we better expose it with a load balancer layer in the middle. Hence the As for the second group of users, if it's the infrastructure team of a company, the reasoning is exactly same as above, and if it's a separate company that's providing Redis as a service in their own cloud, they have their own Kubernetes cluster and the rest of the reasoning is the same as above. |
All that makes sense. From my point of view if we had implemented configuration options to set up external visibility of these endpoints I had no problem with it letting users set the use case they want. Setting they to load-balancer and open externally the cluster by default its probably an issue for the users that don't want it. |
I understand that there are users who might not prefer the current behaviour (yet). So what exactly is your suggestion? A simple flag in the Redisfailover CRD? Something more detailed? |
I found this repo as I was looking for a way to easily define and deploy HA redis for apps in my cluster. The automatic loadbalancer setup means the current version isn't a good fit for my use case, and I assume it might be the same for others. It'd be great if it was off by default but opt-in via a flag for three main reasons:
|
Fixes #626 .
Changes proposed on the PR: