Closed dobrac closed 11 months ago
What are the possible use cases here?
For me, the use cases are the following:
type - exposing Dragonflydb instance outside of Kubernetes using LoadBalancer (for example, MetalLB) loadBalancerIP - sets the desired IP address for the MetalLB loadBalancerSourceRanges - limits access to the service to only specified source IP ranges to protect the Dragonflydb more and not expose it everywhere publicly
We have servers not running in Kubernetes that need to access the Dragonfly DB. This allows us to do that.
Given that LoadBalancerIP is deprecated and it is recommended to use annotation for that, would it work for you if we include type
and annotations
in the crd? It seems loadBalancerSourceRanges
is not a common configuration among operators (you can still use service.beta.kubernetes.io/load-balancer-source-ranges annotation).
PR for context - https://github.com/dragonflydb/dragonfly-operator/pull/125/files#diff-577f217c38fb3c5f7ec4e7d5367d08de9efe1d2fc3cf6de1a64fb7fb3bc498f3
I've just noticed that LoadBalancerIP is deprecated. The annotation will be enough for this. About loadBalancerSourceRanges, I don't know of any alternative in annotations - for MetalLB. Even in the link provided, it says it's deprecated, and you should use loadBalancerSourceRanges. Though, It may be related to MetalLB mainly, so that's why it isn't that common configuration among operators.
The PR looks good 👍 thanks.
Hello, I would really appreciate it (if that's not yet possible) to support a few service spec keys:
type: (e.g. LoadBalancer) loadBalancerIP: (e.g. xxx.xxx.xxx.xxx) loadBalancerSourceRanges: (array of CIRDs)
Is that possible?