Alauda Cache Service E2
  • English

    • Introduction

    Alauda Cache Service E2 deploys and operates Valkey instances on Kubernetes through declarative custom resources. The Valkey Operator reconciles the desired state, creates the data-plane workloads and Services, and performs lifecycle operations such as scaling, configuration updates, upgrades, and node recovery.

    All instance operations are CLI-based. This product does not provide a Web Console. Use kubectl, valkey-cli, and Kubernetes-native automation.

    TOC

    Release and server versionsArchitecturesImplemented capabilitiesResponsibility boundary

    Release and server versions

    The next major product release is 2.0.0. It supports these Valkey server lines:

    Supported lineUse in spec.version
    Valkey 7.2"7.2"
    Valkey 8.1"8.1"
    Valkey 9.1"9.1"

    Do not use 8.0 or 9.0, even if a compatibility enum in an installed custom resource definition (CRD) accepts those values. The 2.0.0 Operator image map selects only the 7.2, 8.1, and 9.1 server lines. A schema enum value for another line does not establish product support.

    Architectures

    ArchitectureAPI valueDescriptionMinimum production shape
    ClusterclusterDistributes 16,384 hash slots across shards.At least 3 shards and at least 2 members per shard.
    FailoverfailoverRuns one primary-replica group monitored by an odd-numbered Sentinel deployment.At least 2 data members and 3 Sentinels.
    ReplicareplicaRuns one primary-replica group without Sentinel.Choose 1 member only for non-high-availability use; use at least 2 when replication is required.

    spec.replicas.replicasOfShard is a legacy field name. In the implemented workload, it is the total member count per Cluster shard, or the total data-node count for Failover and Replica. For example, replicasOfShard: 2 creates one primary and one replica after reconciliation.

    Implemented capabilities

    • in-place shard and member changes, including Cluster slot rebalancing;
    • rolling version upgrades and rolling restarts;
    • Valkey access control list (ACL) users backed by Kubernetes Secrets;
    • ClusterIP, NodePort, and LoadBalancer Services;
    • IPv4 or IPv6 single-stack Services;
    • optional cert-manager-issued mutual TLS (mTLS);
    • optional persistent storage through persistent volume claims (PVCs);
    • node selectors, tolerations, the implemented affinity policies, and Pod security context;
    • Valkey metrics through an exporter sidecar;
    • hot configuration updates for supported parameters;
    • hardened credential handling: hashed ACL passwords, encrypted configuration credentials, and redacted CONFIG GET output for credential directives on the delivered images.

    Responsibility boundary

    The Operator reconciles Kubernetes resources and Valkey topology. Application owners remain responsible for workload-specific key design, client retry and timeout behavior, and capacity objectives. Backup, restore, and disaster recovery are not product capabilities in 2.0.0. Cluster or Failover redundancy protects against some Pod or node failures but is neither backup nor disaster recovery.

    Use the high-level Valkey resource for desired-state changes and User for ACL accounts. Treat generated Cluster, Failover, Sentinel, StatefulSet, Service, ConfigMap, and Secret resources as operator-owned implementation details.

    Valkey replication is asynchronous. A ready redundant topology can improve availability, but replica reads can be stale and an acknowledged write is not guaranteed to survive every primary failure. Client consistency and retry requirements must account for that server behavior.

    See Current limitations for unsupported capabilities and the boundaries of fixed NodePort assignment, PVC retention, and monitoring integration.

    Protocol and server-behavior references: Valkey Cluster specification, Valkey replication, and Valkey Sentinel.

    Valkey and the Valkey logo are trademarks of LF Projects, LLC.