The module lifecycle stage: Preview

The module has requirements for installation

Valkey

A namespaced resource that allows creating the final configuration and serves as the source of truth for the state of a specific deployed valkey service.

ValkeyClassName

The name of the class that will be associated with a specific resource.
Without a created ValkeyClass, deploying the service is impossible.

spec:
  valkeyClassName: default

Instance

A section that describes the resources of the service being created.
Must pass validation according to the sizingPolicy of the corresponding class:

spec:
  instance:
    memory:
      size: 1Gi
    cpu:
      cores: 1
      coreFraction: 50
    persistentVolumeClaim:
      size: 1Gi
      storageClassName: default

Configuration

A section describing the configuration of the valkey service.
Must pass validation according to the overridableConfiguration and validations of the corresponding class:

spec:
  configuration:
    maxMemory: "512Mi"
    maxMemoryPolicy: Volatile-lfu

Supported Valkey Versions

The only supported Valkey version is 9.0.1

Our images for running Valkey containers are based on distroless architecture.

Valkey server-side TLS

Valkey supports server-side TLS configuration through the spec.tls section.

Server-side TLS defines how TLS certificates for the Valkey service itself are managed.

Two modes are supported:

  • CertManager — the certificate is issued and managed by cert-manager.
  • CustomCertificate — a custom TLS certificate from a Kubernetes Secret is used.

If the tls section is not specified, the default mode is CertManager.

Server-side TLS with cert-manager

In CertManager mode, the certManager section must be specified.

Exactly one of the following fields must be set:

  • clusterIssuerName;
  • issuerName.

Example with ClusterIssuer:

spec:
  tls:
    mode: CertManager
    certManager:
      clusterIssuerName: selfsigned

Example with namespaced Issuer:

spec:
  tls:
    mode: CertManager
    certManager:
      issuerName: valkey-issuer

Parameters:

  • clusterIssuerName — cert-manager ClusterIssuer name;
  • issuerName — cert-manager Issuer name in the service namespace.

The clusterIssuerName and issuerName fields cannot be specified at the same time.

Server-side TLS with a custom certificate

In CustomCertificate mode, the customCertificate section must be specified.

spec:
  tls:
    mode: CustomCertificate
    customCertificate:
      serverTLSSecret: valkey-server-tls
      serverCASecret: valkey-server-ca

Parameters:

  • serverTLSSecret — name of a kubernetes.io/tls Secret with the tls.crt and tls.key keys;
  • serverCASecret — name of a Secret with the ca.crt key.

The certificate from serverTLSSecret must contain SAN entries with the DNS names of the Valkey service.
Otherwise, clients with full TLS verification will reject the connection.

TLS Secret example:

apiVersion: v1
kind: Secret
metadata:
  name: valkey-server-tls
type: kubernetes.io/tls
data:
  tls.crt: BASE64_ENCODED_CERT
  tls.key: BASE64_ENCODED_KEY

Example Secret with a CA certificate:

apiVersion: v1
kind: Secret
metadata:
  name: valkey-server-ca
type: Opaque
stringData:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

Users and roles

Valkey users are described in the spec.users section. Each user requires a name (name) and a role (role). The password is set in exactly one of the following ways:

  • hashedPassword — a SHA-256 digest of the password, hex-encoded and lower-cased;
  • secretRef — a reference to an existing Secret in the same namespace that holds the plaintext password;
  • storeCredsToSecret — the operator generates a password and saves it to a Secret with the given name in the same namespace.

Roles

Role Permissions Purpose
ReadOnly Read access to all keys and channels. The KEYS command is denied. Services that only read data.
ReadWrite All commands except the @admin and @dangerous categories. The INFO command is allowed. Applications.
Monitoring No access to keys or channels. Allows INFO, CONFIG GET, CLIENT LIST, CLIENT INFO, SLOWLOG, LATENCY, MEMORY, CLUSTER INFO. Metrics collection.

Behavior

  • If a user’s password cannot be resolved (for example, the Secret from secretRef does not exist), the user is skipped, but the service keeps running. Once the problem is fixed, the user is created automatically.
  • When a password changes, the user’s active sessions are terminated.
  • A Secret created via storeCredsToSecret cannot be edited manually. To generate a new password, delete the Secret and the operator will recreate it.

Warning. The built-in default user is disabled: connections without a password are rejected. To connect, declare users in spec.users.

spec:
  users:
    - name: app
      role: ReadWrite
      storeCredsToSecret: app-valkey-creds
    - name: reader
      role: ReadOnly
      secretRef:
        name: reader-password
        key: password
    - name: exporter
      role: Monitoring
      hashedPassword: <sha256-hex-password>

Status

The status of the Managed Valkey service is reflected in the Valkey resource.
The Conditions structure clearly shows the current status of the service

Significant types:

  • LastValidConfigurationApplied - An aggregating type that shows whether the last valid configuration has been successfully applied at least once.
  • ConfigurationValid - shows whether the configuration has passed all validations of the associated ValkeyClass.
  • ScaledToLastValidConfiguration - shows whether the number of running replicas matches the specified configuration.
  • Available - shows whether the master replica of the service is running and accepting connections.
  • UsersSynced - shows whether all users have been synchronized and brought to the described state.
  • DatabasesSynced - shows whether all logical databases have been synchronized and brought to the described state.
conditions:
    - lastTransitionTime: '2025-09-22T23:20:36Z'
      observedGeneration: 2
      status: 'True'
      type: Available
    - lastTransitionTime: '2025-09-22T14:38:04Z'
      observedGeneration: 2
      status: 'True'
      type: ConfigurationValid
    - lastTransitionTime: '2025-09-22T14:38:06Z'
      observedGeneration: 2
      status: 'True'
      type: DatabasesSynced
    - lastTransitionTime: '2025-09-22T14:38:47Z'
      observedGeneration: 2
      status: 'True'
      type: LastValidConfigurationApplied
    - lastTransitionTime: '2025-09-22T23:20:36Z'
      observedGeneration: 2
      status: 'True'
      type: ScaledToLastValidConfiguration
    - lastTransitionTime: '2025-09-22T14:38:05Z'
      observedGeneration: 2
      status: 'True'
      type: UsersSynced

A False status indicates a problem at one stage or another, or incomplete state synchronization.
For such a state, a reason and message with a description will be specified.

---
    - lastTransitionTime: '2025-09-23T14:53:33Z'
      message: Syncing
      observedGeneration: 1
      reason: Syncing
      status: 'False'
      type: LastValidConfigurationApplied
    - lastTransitionTime: '2025-09-23T14:54:58Z'
      message: Not all the instances are running still waiting for 1 to become ready
      observedGeneration: 1
      reason: ScalingInProgress
      status: 'False'
      type: ScaledToLastValidConfiguration
---

Usage Examples

Basic Usage

Without persistent data storage.

  1. Create a namespace named valkey.
  2. Create a Valkey resource
kubectl apply -f managed-services_v1alpha1_valkey.yaml -n valkey
apiVersion: managed-services.deckhouse.io/v1alpha1
kind: Valkey
metadata:
  name: valkey-sample
spec:
  valkeyClassName: default
  configuration:
    maxMemory: "256Mi"
    maxMemoryPolicy: Volatile-lfu
    save: ""
    appendOnly: "No"
  instance:
    memory:
      size: "512Mi"
    cpu:
      cores: 1
      coreFraction: "25%"
    persistentVolumeClaim:
      size: "1Gi"
  1. Wait until the cluster is created and all conditions are True:
  kubectl get valkey valkey-sample -n valkey -o wide -w
  1. To connect, use the redis-cli client and the d8ms-vlk-valkey-sample service
  redis-cli -h d8ms-vlk-valkey-sample -p 6379

Using AOF Storage

  1. Create a namespace named valkey.
  2. Create a Valkey resource
kubectl apply -f managed-services_v1alpha1_valkey.yaml -n valkey
apiVersion: managed-services.deckhouse.io/v1alpha1
kind: Valkey
metadata:
  name: valkey-sample
spec:
  valkeyClassName: default
  configuration:
    maxMemory: "256Mi"
    maxMemoryPolicy: Volatile-lfu
    save: ""
    appendOnly: "Yes"
  instance:
    memory:
      size: "512Mi"
    cpu:
      cores: 1
      coreFraction: "50%"
    persistentVolumeClaim:
      size: "1Gi"
  1. Wait until the cluster is created and all conditions are True:
  kubectl get valkey valkey-sample -n valkey -o wide -w
  1. To connect, use the redis-cli client and the d8ms-vlk-valkey-sample service
  redis-cli -h d8ms-vlk-valkey-sample -p 6379

Using RDB Storage

  1. Create a namespace named valkey.
  2. Create a Valkey resource
kubectl apply -f managed-services_v1alpha1_valkey.yaml -n valkey
apiVersion: managed-services.deckhouse.io/v1alpha1
kind: Valkey
metadata:
  name: valkey-sample
spec:
  valkeyClassName: default
  configuration:
    maxMemory: "256Mi"
    maxMemoryPolicy: Volatile-ttl
    save: "60 5"
    appendOnly: "No"
  instance:
    memory:
      size: "512Mi"
    cpu:
      cores: 1
      coreFraction: "50%"
    persistentVolumeClaim:
      size: "1Gi"
  1. Wait until the cluster is created and all conditions are True:
  kubectl get valkey valkey-sample -n valkey -o wide -w
  1. To connect, use the redis-cli client and the d8ms-vlk-valkey-sample service
  redis-cli -h d8ms-vlk-valkey-sample -p 6379