Closed hashemi-soroush closed 11 months ago
Good one again!
Is follow master pod if master changes?
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 https://github.com/spotahome/redis-operator/issues/608
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 loadBalancer
services? I think that can generate too unexpected hassle to existing clusters due creation of external load balancers in addition to security issues.
Probably changing to internal services before release
@ese there are a number of reasons I chose the loadbalancer
type.
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 loadbalancer
type.
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. It would be ideal to have this possibility in the spec. Given the current behavior, I'm not comfortable forcing all users to have load balancers exposing their Redis endpoints, at the moment who needs to maintain these services always can create them by other means since they don't need any maintenance because redis operator is taking care of the pod labeling
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:
@nastynaz you can find out about the last updates on the issue you're referring to in issue #647 .
Fixes #626 .
Changes proposed on the PR: