K8S operator for ValKey?

[arpan57]

Hello community,

Do we have an operator for ValKey? We are excited to try ValKey as a redis replacement on a Kubernetes cluster. I briefly tried using existing Redis operator without success.
Please suggest if you have successfully used same or any other operator with ValKey.

Many thanks.

[zuiderkwast]

We (Ericsson) are using an internal fork of this one: https://github.com/AmadeusITGroup/Redis-Operator (The open source one is very old and not very good.) Ours is not really ready to be open sourced, for various reasons. We would really like to see an official open source operator for Valkey Cluster though.

IBM has one for cluster as well: https://github.com/IBM/operator-for-redis-cluster. I don't know of it's an updated fork of the Amadeus one. Also, I don't know the status.

I believe you need different functionality depending on whether you're running cluster or not.

I heard Canonical is working on an operator, but it seems very unclear if it's for cluster or not and if it's even for K8s. From what I heard, it can run on K8s or OpenStack or other platforms as well, so I
don't really know how that plays with K8s. (I wonder if it's using K8s Operator SDK.

[arpan57]

Thank you @zuiderkwast. Appreciate your comment.
We would like to run both ValKey Clusters and ValKey instances depending on the customer requirements. It would be great to see if there are any trusted and working operators for ValKey. I briefly tried using existing Redis operator to build a ValKey cluster but it didn't work.
Thanks.

[zuiderkwast]

Great. Let me know if you have any success.

For the record, we'd need at least the following features for cluster:

• Orchestrate scaling, i.e. add/remove nodes and migrate slots between them.
• Rolling upgrades without service impact.
• Anti-affinity handling, i.e. don't put primary and its replicas on the same worker.

[dmolik]

Hi I started work on an operator: https://github.com/hyperspike/valkey-operator/ I'm still working on finishing up the initial PoC but would love feedback.

I'll be sure to incorporate @zuiderkwast feature requests in the near future.

At the moment I'm working on status updates, upgrading/scaling, and events

[dmolik]

okay that took an embarrassing amount of time but the containers are now plubic

[arpan57]

Switched to context "north".
❯ k get ns
NAME              STATUS   AGE
cilium-spire      Active   33m
default           Active   34m
ingress-nginx     Active   26m
kube-node-lease   Active   34m
kube-public       Active   34m
kube-system       Active   34m

❯ kubectx minikube
Switched to context "minikube".
❯ k get ns
NAME                   STATUS   AGE
default                Active   2d1h
kube-node-lease        Active   2d1h
kube-public            Active   2d1h
kube-system            Active   2d1h
kubernetes-dashboard   Active   2d1h
minikube-pv-hack       Active   21m

[arpan57]

I think I will start a discussion on operator's git/issues. :-)

[dmolik]

weird a namespace should be created. Try this:

kubectl apply -f https://raw.githubusercontent.com/hyperspike/valkey-operator/main/dist/install.yaml

[arpan57]

What I did was, stopped minikube.
$ make minikube
This created the name space (valkey-operator-system) and also the 3 pods :-) All the pods are stuck with FailedScheduling state
At least some success :-)

Events:
  Type     Reason            Age                  From               Message
  ----     ------            ----                 ----               -------
  Warning  FailedScheduling  2m7s (x2 over 2m8s)  default-scheduler  0/4 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/4 nodes are available: 4 Preemption is not helpful for scheduling.
  Warning  FailedScheduling  118s                 default-scheduler  0/5 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/5 nodes are available: 5 Preemption is not helpful for scheduling.
  Warning  FailedScheduling  1s (x2 over 97s)     default-scheduler  0/6 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/6 nodes are available: 6 Preemption is not helpful for scheduling.