Alauda Cache Service E2
  • English

    • Rolling restart

    Set a new Request for Comments (RFC) 3339 timestamp in spec.podAnnotations["kubectl.kubernetes.io/restartedAt"] to trigger workload template updates and rolling Pod replacement. The value must parse as a timestamp and be later than the previously recorded value; reusing or decreasing it does not request a new restart.

    TOC

    Before restartingTrigger the restart

    Before restarting

    • Confirm the Valkey phase is Ready.
    • Confirm every production Cluster shard has a replica, or that the Failover instance has a healthy replica and Sentinel quorum.
    • Stop concurrent scaling, upgrade, storage, access, and configuration changes.
    • Verify external data protection and current persistent volume claim (PVC) health.

    Trigger the restart

    RESTARTED_AT="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
kubectl -n default patch valkey valkey-cluster --type=merge \
  -p "{\"spec\":{\"podAnnotations\":{\"kubectl.kubernetes.io/restartedAt\":\"${RESTARTED_AT}\"}}}"

    Watch progress:

    kubectl -n default get valkey valkey-cluster -w
kubectl -n default get pods -l buf.red/name=valkey-cluster -w
kubectl -n default get events --sort-by=.lastTimestamp

    Do not claim success from Pod timestamps alone. After the phase returns to Ready, verify connectivity, access control list (ACL) authentication, Cluster slot coverage or the Failover primary, replication health, and exporter metrics.

    The Operator uses rolling workload updates, but availability still depends on topology, client retry behavior, Pod disruption, scheduling capacity, and the health of replicas. This procedure does not guarantee zero downtime.