Managing Valkey Cluster in Kubernetes - Percona

Enterprise-ready open source PostgreSQL
Percona Software for PostgreSQL
Open source PostgreSQL software for production workloads
Model infrastructure requirements for PostgreSQL deployments.
Download PostgreSQL software and tools
Enterprise Support and Services
Expert help to run PostgreSQL in production
Open source MySQL for enterprise use
Percona Software for MySQL
Production-ready open source MySQL software
Compare DBaaS vs MySQL on Kubernetes cloud costs
Download MySQL software and tools
Enterprise Support and Services
Expert help to run MySQL in production
Enterprise-grade value for MongoDB®
Percona Software for MongoDB®
Source-available, enterprise-grade compatible software for MongoDB®
Compare MongoDB® deployment options, costs, and trade-offs.
Download MongoDB® software and tools
Enterprise Support and Services
Expert help to run MongoDB® in production
Run and manage Redis or Valkey
Discover the benefits of migrating from Redis to Valkey
Download Valkey software and tools
Enterprise Support and Services
Expert help to run Redis and Valkey in production
Monitoring & Management (PMM)
Coroot Percona Edition
Expert Consulting and Services
Over the last several years, Percona has introduced several rock-star Kubernetes Operators for managing MySQL, Percona XtraDB Cluster, MongoDB, and PostgreSQL. For Valkey, we are actively working with the community to contribute our knowledge, and experience to help brainstorm, develop, and test the official Valkey Operator for Kubernetes.
While the Valkey Operator has not yet released a GA 1.0 version, we wanted to take this opportunity to highlight some recently added features.
Up until recently, there was no native ability to provide configuration parameters to the Valkey server process running inside each deployed pod. This hurdle is now overcome, and you can supply configuration natively within the deployment CR.
For now, these parameters are set on initial cluster deployment. There is already traction underway to allow certain parameters to be dynamically set at runtime. There are a small handful of certain cluster-based parameters that cannot be overridden by the user, otherwise it would break operator functionality.
Managing users is always a tedious task for any database administrator. Creating ACLs for users in Valkey can be a bit confusing coming from a traditional RDBMS using GRANT syntax. To make things just a bit easier, Valkey Operator has added user permissions management to the deployment CR.
Firstly, create your Secret containing usernames, and passwords:
Next, deploy your cluster with users:
There’s quite a lot going on here. Let’s break it down by first looking at the user ‘alice’:
The ‘alice’ user is enabled, with a password found in the referenced Secret and secret key. Next, we can see what commands, or in this case, command groups (Noted with ‘@’) that alice is allowed to execute, and which commands/groups are denied. Lastly, permissions on specific key patterns are identified for maximum security restrictions.
The other user, ‘david’, can access all of the admin-group commands, and cannot read or write to any keys. Note that david’s secret key reference is an array, which means you can provide multiple passwords per user; great for password rotation! Once david confirms the new password, the old password references can be removed from the CR and Secret, and the Valkey Operator will synchronize the ACLs.
Users are dynamic, which means they can be added, removed, and modified without restarting the cluster.