Release notes

v0.1.8

Summary

Documentation update. The user guide now covers server-side TLS, and the release notes for earlier versions were corrected.

Highlights

• New guide on server-side TLS: managed by cert-manager or using your own certificate.
• The v0.1.6 and v0.1.7 release notes now show which change shipped in which version.

v0.1.7

Summary

Valkey instances can now be monitored by the observability module through opagent. The monitoring mode is set per instance with the new spec.observability field.

Access to Valkey now requires authentication, and the Valkey agent can access only its own instance.

Highlights

Metrics collection is now on by default. Valkey instances created before this release need their StatefulSet recreated to pick up the new mode.

Connections without a password stop working: declare users in spec.users before upgrading.

New features

• New spec.observability field in the Valkey resource: Enabled (metrics and alerts), EnabledWithoutAlerts (metrics only) or Disabled.

Breaking changes

• The built-in default user is disabled. Clients that connect without AUTH are rejected, and their existing connections are dropped after the upgrade.

Known issues

• Changing spec.observability on an existing instance takes effect only after its StatefulSet is recreated.

v0.1.6

Summary

The Valkey status is now built from per-phase reports (ReconcilePhases) and the live workload state, so conditions show more accurately what is happening with the instance.

Valkey instances can now declare their own users with roles. Users and passwords are managed declaratively and applied to a running instance without a restart.

Improved validation of Valkey resource names.

Highlights

The new logic for displaying conditions in the Valkey status solves the problem of controller race conditions and provides a more accurate reflection of the service’s state.

• New spec.users field with ReadOnly, ReadWrite and Monitoring roles.

• Password via hashedPassword, storeCredsToSecret or secretRef.

• User and password changes are applied without restarting the pod.

• The default user stays open in this release - existing clients keep working. Declare users now: default will be closed later.

• Invalid Valkey resource names are rejected immediately when the resource is created.

Fixes

• Fixed sizing validation on Valkey update and a stuck finalizer when the ValkeyClass has been deleted.
• Valkey resource names longer than 50 characters or incompatible with Kubernetes Service naming rules now produce an immediate validation error

v0.1.5

Summary

This release significantly improves Managed Valkey operability and release process maturity. Webhook and controller now run as separate components, Valkey configuration is delivered through a ConfigMap and applied by the agent without a pod restart, and the module ships its own CRDs, documentation and structured bilingual release notes.

Highlights

• Webhook and controller are split into separate deployments.
• Valkey configuration is delivered via ConfigMap and applied by the agent to a live instance, without a pod restart.
• Reload TLS certs in a running Valkey instance without restarting the pod.
• Release notes/changelog flow is now bilingual and CI-automated.

v0.1.4

Improvements

• valkey-json is included in the standard delivery.
• The certificate TTL is reported in the Valkey resource status.

Fixes

• Minor fixes in how the resource status is composed.

v0.1.3

Improvements

• Every Valkey pod now gets a managed-agent native sidecar, which watches the Valkey configuration and updates it on changes in the CR.
• Added TLS support in two modes: CertManager and CustomCertificate.

Fixes

• Roles for resources have been updated in accordance with RBAC v1.

Miscellaneous

• Go updated to 1.26.3 (was 1.25.7).

v0.1.2

Improvements

• Added a mutating webhook for ValkeyClass, so class defaults are applied on admission.
• The operator readiness probe now waits for the controller cache to be synced before reporting readiness.
• The operator is deployed on master nodes with a high availability strategy and replica count.

Fixes

• Added migrations for legacy objects created without module labels, and removal of the deprecated class.
• Fixed a panic in the operator when updating a condition while status.conditions is nil.

v0.1.1

First release of the Managed Valkey module. This version implements the basic capabilities for deploying and managing Valkey instances (a Redis-compatible in-memory data store) in a DKP cluster.

Features

Creating standalone Valkey instances

Added the namespaced Valkey CRD, which deploys a standalone Valkey instance. When creating a resource, the user specifies compute resources (CPU cores and core fraction, memory), storage parameters and the Valkey configuration.

Configuration templates via ValkeyClass

Added the cluster-wide ValkeyClass CRD, which allows administrators to create named templates for instances. Every Valkey resource must reference an existing class, and its configuration is checked against that class before the service is deployed. A class defines the allowed sizing policies, the list of configuration parameters a user may override, class-level configuration values and custom validation rules.

When the module is enabled, a ValkeyClass named default is created automatically.

Validation via webhooks

All create and update operations on Valkey and ValkeyClass resources go through admission webhooks. The webhooks verify the correctness of parameters: sizing policies of the associated class, the whitelist of overridable configuration parameters, and custom rules set by the administrator.

Custom CEL validation rules

Administrators can define arbitrary validation rules for Valkey resources in ValkeyClass using CEL (Common Expression Language) expressions, which allows organization-specific constraints to be implemented without changing the operator’s code.

Service state in the resource status

The state of the service is reflected in the conditions of the Valkey resource.

Support for distroless images

Valkey images are based on the distroless architecture, which improves security by minimizing the number of components in the container.