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.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
apiVersion: valkey.io/v1alpha1 kind: ValkeyCluster metadata: name: my-valkey-cluster1 spec: shards: 3 replicas: 1 config: maxmemory: 500mb maxmemory-policy: allkeys-lfu maxclients: 5000 commandlog-execution-slower-than: 10000 |
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:
|
1 2 3 4 5 6 7 8 |
apiVersion: v1 kind: Secret metadata: name: valkey-cluster-sample-users data: alicepw: M21wdHlQQHNzdzByZA== davidold: OVYqTHQlYXU4Mk5tdTlyeQ== davidnew: VmFsa2V5I1J1bHojMjIzMw== |
Next, deploy your cluster with users:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
apiVersion: valkey.io/v1alpha1 kind: ValkeyCluster metadata: name: my-cool-valkey-cluster spec: shards: 3 replicas: 1 users: - name: alice enabled: true passwordSecret: name: valkey-cluster-sample-users keys: [alicepw] commands: allow: ["@read", "@write", "@connection"] deny: ["@admin", "@dangerous"] keys: readWrite: ["app:*", "cache:*"] readOnly: ["shared:*", "config:*"] writeOnly: ["logs:*", "metrics:*"] - name: david enabled: true passwordSecret: name: valkey-cluster-sample-users keys: - davidold - davidnew commands: allow: ["@admin"] |
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.
Bring on the encryption! TLS support was also recently added to the Valkey Operator. Create your Secret with the CA, TLS Key, and Cert files, and tell the CR where to find them:
|
1 2 3 4 5 6 7 8 9 10 |
apiVersion: valkey.io/v1alpha1 kind: ValkeyCluster metadata: name: cluster-sample spec: shards: 3 replicas: 1 tls: certificate: secretName: my-valkey-tls-secret |
Once deployed, the Valkey operator will mount the referenced secret to each pod, and add all the proper configuration parameters. By doing so, the operator enforces SSL/TLS communication between each Valkey cluster node, securing node-to-node, and replication traffic within your kubernetes network. Additionally, by creating user certificates signed by the same CA, traffic between your clients, and the Valkey clusters nodes is secured. This configuration is BYOC (bring-your-own-certificate), which works well with the popular CertManager, or other certificate authority you may be using.
As a teaser, here are a couple other features coming soon to Valkey Operator:
Want to contribute to the Valkey Operator? Join any of the discussions/issues on our github, or come introduce yourself in the Valkey Slack community.
