Redis Concepts

Overview

Redis is a high-performance, in-memory data structure store, widely used as a database, cache, and message broker. Running Redis on a Kubernetes (k8s) cluster via Portworx Data Services (PDS) provides users with a scalable, resilient, and fully cloud-native data platform. By integrating Redis with Kubernetes, PDS enables dynamic deployment, automated management, and improved high availability.

PDS supports the Redis and tracks upstream releases to ensure compatibility and timely availability of new versions. Supported versions are listed here.

As with all data services in PDS, Redis is deployed within Kubernetes and managed by the PDS Deployments Operator. The operator introduces a custom resource called redis, which enables Kubernetes-native management of Redis instances—supporting scaling, configuration, monitoring, and upgrades.

Clustering

PDS uses Redis Sentinel to enable high availability for Redis deployments. Sentinel handles automatic failover, monitoring, and primary election, enabling robust and self-healing Redis clusters.

Key Features of Redis Sentinel

• Automated Failover: Detects primary node failures and automatically promotes a replica to be the new primary.

• Monitoring: Continuously monitors master and replica nodes to detect faults quickly.

• Notification and Discovery: Supports auto-discovery of the new primary and notifies clients accordingly.

For high availability, Redis should be deployed with a minimum of three nodes. One node is elected as the primary (for read/write access), while others function as replicas (read-only). If the primary fails, a replica is promoted automatically.

Redis clusters in PDS are deployed using StatefulSet with persistent storage, and nodes automatically discover each other for seamless cluster formation. Redis pods are distributed across Kubernetes worker nodes using Stork and Portworx volumes for enhanced fault tolerance.

Replication

Application Replication

Redis achieves application-level replication via the primary-replica model. The primary node handles all writes, and replicas asynchronously replicate data. This supports both high availability and horizontal scalability for read operations.

While replicas can enhance read throughput, write operations are handled by a single primary node. For write-intensive applications, vertical scaling is advised.

Storage Replication

In addition to application-level replication, PDS employs Portworx Enterprise for storage-level replication. Each Redis pod uses a persistentVolume, and these volumes can be configured with multiple replicas across worker nodes or availability zones. This setup reduces recovery time (RTO) by ensuring that data is available on multiple nodes.

By combining Redis replication and Portworx storage replication, PDS provides both high availability and rapid recovery in failure scenarios.

Configuration

Redis server configurations can be adjusted via environment variables specified in the application configuration template. These settings allow users to fine-tune performance and operational characteristics.

PDS simplifies the process of customizing and managing these configurations at scale. For a full list of configurable parameters, refer to the PDS Redis allowed configurations.

Scaling

PDS supports both vertical scaling (adjusting CPU/memory) and horizontal scaling (adding read replicas) for Redis clusters.

Vertical Scaling

Vertical scaling modifies pod-level resources (CPU and memory) dynamically. Redis pods are updated in a rolling manner to minimize disruption.

Horizontal Scaling

Horizontal scaling adds new Redis replica nodes. These replicas can handle read traffic but cannot accept writes. Horizontal scaling is useful for scaling out read workloads and increasing fault tolerance.

Connectivity

PDS provisions service endpoints for Redis pods based on user selection (LoadBalancer or ClusterIP). These services provide stable IPs and DNS records. Redis client connections can use:

• Redis primary endpoint (rw): Routes to the master node for write operations.

• Redis replica endpoint (ro): Routes to all replicas for read operations.

• Individual pod endpoints (vip): Routes to specific Redis pods.

Certainly! Here's a rephrased version with a slightly more formal and polished tone:

The default credentials are associated with a Redis user named pds. You can access the connection details, including the password, through the PDS UI.

Service Endpoint Details

Service Name	Details
red-<name>-<namespace>-<pod-id>-vip	Endpoint to a specific pod
red-<name>-<namespace>-rw	Endpoint to primary node (read/write)
red-<name>-<namespace>-ro	Endpoint to all replicas (read-only)

Access Control & User Management

Portworx Data Services (PDS) enhances Redis deployments with built-in support for managing users and ACLs (Access Control Lists). This system ensures consistent and secure access across all Redis nodes.

note

This ACL synchronization capability is unique to PDS and is not available in open source Redis.

Key Capabilities

• A master node (called the origin) manages ACLs centrally and pushes updates.

• Other nodes sync the updated users.acl file as needed.

• PDS ensures a safe fail-over if the origin master becomes unresponsive.

• Redis user settings are automatically included in deployment backups.

Managing Redis Users

You can create, update, and delete users using redis-cli or desktop tools like RedisInsight.

1. Create a user with limited access:

   ACL SETUSER appuser on >mysecurepassword ~app:* +GET +SET

2. Save the ACL file:

   ACL SAVE

note

• User management works only within PDS-managed Redis deployments.

• ACL syncs occur at regular intervals or on detected changes and not instantly in real-time.

Backup and Restore

Redis backup and restore in PDS is powered by Portworx and the Redis RDB snapshot mechanism.

Backups

Backups are taken using Redis RDB snapshots and stored in dedicated Portworx volumes. Backups can be scheduled or taken ad hoc. After a backup is complete, the PDS Backup Operator uses Portworx’s cloud snapshot functionality to replicate the volume to an off-site object store.

This approach supports the 3-2-1 backup strategy; 3 copies of data, on 2 types of media, with 1 copy off-site.

Restore

Redis restore operations are performed out-of-place, which means the data is not restored directly into the original Redis instance or dataset. Instead, it is restored into a new or separate Redis instance, or a different namespace/database. A new Redis cluster is deployed and the data is restored to it. This ensures no accidental data overwrites and allows for forensics or troubleshooting on restored data.

note

Only full database restores are supported.

Monitoring

Each Redis server in PDS includes a Prometheus exporter. Metrics are exposed in the Prometheus format and can be visualized using Grafana or other tools.

Metrics are available through the PDS Control Plane’s Prometheus endpoint and include details like memory usage, keyspace statistics, replication lag, and command stats.

For the complete list of supported metrics and example usage, refer to the PDS Redis Metrics.