setting up memcached in HA format

Dragonfly Technical
1

hey all,

I was trying to setup memcached in an HA format, ie: with the dragonfly operator sending the requests to underlying dragonflydb instances. I’ve set it up using the kubectl apply commands as seen here:

https://www.dragonflydb.io/docs/getting-started/kubernetes-operator

I’ve set up the instances with the following parameters:

  --alsologtostderr
  --primary_port_http_enabled=false
  --admin_port=9999
  --admin_nopass
  --maxmemory=1Gi
  --proactor_threads=1
  --memcached_port=11211

however when I try to connect to the HA primary, it doesn’t export 11211:

telnet dragonfly-sample 11211
Connection refused.

I know that redis is available:

telnet dragonfly-sample 6379
Connected to dragonfly-sample

so… whats going on here? is memcached support available in the operator and if so what am I doing wrong here?

thanks much for any help here

2

looking at the operator source code it looks like this isn’t supported. three questions, is this correct, if so why is it not supported, and how easy would that support be to add? well, ok, a fourth - if I’m incorrect in saying that it isn’t supported, how do you actually implement this?

3

hey @meaningful-vole @dignified-nautilus - could you confirm that this is the case? does dragonfly support memcached in HA format the way that we are describing above?

if not how easy would it be to implement and is it on the deployment schedule?

thanks much for any info here

4

@zingy-umbrellabird Dragonfly does supprot HA with memcached . Might be some changes that need to be done on the operator side to be able to connect with the memcached port, @happy-giraffe can answer this

5

Ah. So I dont think we expose the port on the service yet! Should be easy to add

6

@happy-giraffe could you possibly let me know when this is integrated and when I can try it via the dragonfly kubernetes operator setup above? I’d love to try it out

7

Expect a fix this week! :slightly_smiling_face: WIll update you once a release is done with it.

8

k thanks @happy-giraffe

9

@tarun - any idea on a time? we are in the process of demoing memcached replacements

10

Hi @zingy-umbrellabird , we will release this week (once dragonfly v1.16 is released)

11

Hey, v1.1.2 released - https://github.com/dragonflydb/dragonfly-operator/releases/tag/v1.1.2. use memcachedPort field instead of the --memcached_port arg

12

@devoted-kiwi - ok I think I’ve got it, you need to modify the ‘kind: dragonfly’ section to add this when used with the operator correct?

its a little bit confusing because all of the other arguments to the operator are in the dragonfly-operator.yaml file so it took a bit of time to figure out.

However, when I’m running it in our environment I’m getting:

I20240409 18:01:29.512708 1 proactor_pool.cc:146] Running 16 io threads
E20240409 18:01:29.512779 1 dfly_main.cc:168] There are 16 threads, so 4.00GiB are required. Exiting…

this seems to be insensitive to the changes that I’m making there wrt to the requests and limits in that same file. ie: if I set the requests and limits to:

resources:
requests:
cpu: 100m
memory: 50Mi
limits:
cpu: 100m
memory: 75Mi

it does not matter. I still hit this 4GB error and we don’t have 4GB to spare for this in our environment.

Also, it looks like the actual dragonfly resources are put into the default namespace, not into the namespace where the operator itself is located. How can you co-locate the two?

The documentation looks very spare on these two issues. I would have thought that dragonflydb.io/v1alpha1 would have inherited the namespace that the operator was in and put the associated resources in the same one - the default setup you have there collides if you have more than one instance of it.

Likewise, I would have thought that the number of threads, etc. would have been exposed to the user so they could be configured.

Anyways I’m probably missing some info from perusing the docs, so if you could help out here it would be greatly appreciated.