From chroot to Kubernetes: Choosing the Right Redis Container Strategy

1. Origin

The presenter explains why the topic was chosen: a question from a Redis community about running Redis in Docker with host networking and local volume mounts sparked the need to evaluate container solutions.

2. Overview of Container Technologies

The history of containerization is traced from early Unix chroot (1979) and BSD jails (2000) to Linux‑level virtualization such as Linux VServer (2001) and OpenVZ (2005). Both technologies patch the kernel to provide isolated process namespaces and separate /proc / /sys views.

Linux introduced namespaces (2002) for resource isolation (PID, network, etc.) and later user namespaces (2013). Three primary namespace operations are described:

Clone : create a process in a specific namespace.

Unshare : detach a process from its current namespace, e.g., unshare -n for a new network namespace.

Setns : attach an existing process to a namespace.

In 2008, cgroups were added to the Linux kernel to limit CPU, memory, disk, and network usage. Combined with namespaces, cgroups form the foundation of modern containers.

Subsequent projects include LXC (2011) and CloudFoundry (which uses LXC and Warden), LMCTFY (Google’s early container runtime, later contributed to libcontainer), and the evolution of Docker (2013) with its image registry Docker Hub. Docker initially used LXC, then switched to libcontainer, which was donated to the OCI and later became containerd and runc.

Security concerns around Docker’s root‑owned daemon led to the development of Kata Containers (lightweight VMs) and Firecracker (AWS). The talk also mentions alternative runtimes such as rkt (now discontinued) and Podman (daemon‑less).

3. Redis Introduction

Redis is presented as a widely used in‑memory key‑value store with three primary use cases: caching, persistent database storage, and message queuing. Key characteristics include a single‑threaded event loop (with optional I/O threading since Redis 6.0), in‑memory data storage, and high‑availability options via Redis Sentinel and Redis Cluster .

4. Redis Containerization Comparison

4.1 Deployment

For single‑machine multi‑instance deployments, process‑level isolation is essential. The presenter recommends using cgroups and namespaces (or lightweight virtualization such as Kata Containers) to isolate CPU, memory, and network resources. Docker and systemd‑nspawn both support these mechanisms; Docker requires a simple docker run with port mapping, while systemd‑nspawn needs a configuration file.

4.2 Scaling (Horizontal Expansion / Shrinkage)

Two scaling scenarios are covered:

Single‑instance maxmemory adjustment : Use docker update --memory to modify cgroup limits, then change Redis’s maxmemory setting.

Cluster scaling : Add or remove Node instances and re‑assign Slot ranges. The presenter notes that dynamic cgroup quota updates are required for memory changes.

4.3 Monitoring & Alerting

Monitoring should be automatic and independent of the underlying container technology. Using Redis Exporter together with Prometheus is recommended; placing both exporter and Redis server in the same network namespace enables simple 127.0.0.1:6379 access.

4.4 Fault Recovery

Instance restart : Use systemd restart policies or Docker’s --restart=always / on-failure.

Master‑slave failover : Ensure data persistence (RDB/AOF) and allocate sufficient resources; in Kubernetes, vpa can auto‑adjust resources.

Data restoration : Enable both RDB snapshots and AOF logs to recover state after failures.

4.5 Node Changes

When adding nodes to a Redis Cluster, the new node’s IP must be added to the cluster configuration. The presenter shows a Kubedb operator example that creates three core resources: PVCs for persistence, Services for discovery, and StatefulSets for ordered pod management.

Commercial offerings such as Redis Enterprise (by Redis Labs) also use Kubernetes operators with similar patterns.

5. Q&A Highlights

Ensuring that instances on the same physical host are not master‑slave pairs requires manual intervention after failover.

Adding new nodes to a Kubernetes Redis Cluster involves updating the cluster config with the new node’s IP, preferably via an operator.

Deploying a Redis Cluster without an operator can be done with StatefulSets and an init container that adjusts the configuration before the main container starts.

Overlay networks introduce additional latency compared to host networking.

Separate Redis clusters per system are recommended to avoid configuration conflicts and cascading failures.

Persistence choices (RDB vs. AOF) depend on data volume and performance requirements; both can be enabled for maximum safety.

6. Conclusion

For simple scenarios, Docker or any tool that leverages cgroups and namespaces suffices. When higher scalability and orchestration are needed, Kubernetes operators (e.g., Kubedb) or native StatefulSets with appropriate PVCs, Services, and resource requests/limits are the preferred solutions.

Images illustrating the timeline of container technologies, Redis architecture, and operator resources are included throughout the presentation.