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.
Cluster Configuration
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.
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.
User Access Control List (ACL)
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:
apiVersion: v1 kind: Secret metadata: name: valkey-cluster-sample-users data: alicepw: M21wdHlQQHNzdzByZA== davidold: OVYqTHQlYXU4Mk5tdTlyeQ== davidnew: VmFsa2V5I1J1bHojMjIzMw==
Next, deploy your cluster with users:
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.
TLS Support
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:
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.
On The Horizon
As a teaser, here are a couple other features coming soon to Valkey Operator:
- Data Persistence: The ability to enable background snapshots of the in-memory dataset for backup, and recovery. Additionally, supporting the AOF (append-only file) for streaming changes.
- Simple Replication: The operator currently only supports Valkey in cluster mode. Be on the lookout for traditional primary -> N-replica configurations, along with Sentinel monitoring.
Join Us
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.
The post Managing Valkey Cluster in Kubernetes appeared first on Percona.
This post explains how to perform a Rolling Index Build on a Kubernetes environment running Percona Operator for MongoDB. Why and when to perform a Rolling Index Build? Building an index requires: CPU and I/O resources Database locks (even if brief) Network bandwidth If you have very tight SLAs or systems that are already operating […]
This is a follow-up to my colleagues Nickolay and Phong’s Store and Manage Logs of Percona Operator Pods with PMM and Grafana Loki and Agustin’s Turbocharging Percona Monitoring and Management With Loki’s Log-shipping Functionality blog posts. Here, I focus on making PostgreSQL database logs from a Kubernetes cluster deployed with the Percona Operator for PostgreSQL […]
PostgreSQL major versions are released every year, with each release delivering better performance and new features. With such rapid innovation, it is inevitable that there will be a need to upgrade from one version to another. Upgrade procedures are usually very complex and require thorough planning. With the 2.4.0 release of Percona Operator for PostgreSQL, […]
