Redis¶

Single-instance Redis per environment, deployed from the Bitnami Helm chart through Argo CD's multi-source pattern. Used by the Tomoda backend for sessions, rate limits, and short-lived caches — not as a persistence-of-record store.

Argo CD Application¶

k8s/envs/<env>/middleware/redis/application.yaml declares two sources:

Chart — registry-1.docker.io/bitnamicharts/redis at chart version 24.1.2.
Values — the same devops Git repo, referenced as $values, pointing at k8s/envs/<env>/middleware/redis/values.yaml.

This split lets the chart upgrade independently of the values file. Both envs sync into the data namespace.

Values (both envs)¶

image:
  registry: docker.io
  repository: bitnamilegacy/redis
  tag: 8.2.1

architecture: standalone
replicaCount: 1
auth:
  enabled: false
  sentinel: false

The bitnamilegacy/redis repository pins the image source to Bitnami's legacy registry (post-2024 reorg) at Redis 8.2.1. There is no master/replica or Sentinel topology — standalone means a single Redis pod with no failover. This is acceptable because the data is recoverable (no source-of-truth state) and the deploy/restart blast radius is small.

No auth¶

auth.enabled: false is intentional. The Redis pod is reachable only via its ClusterIP Service inside the data namespace; ingress is gated by NetworkPolicies on the consumer side (the Tomoda backend Deployments in tomoda / prod) and by the absence of any Ingress or LoadBalancer pointing at Redis. The Tomoda backend still has a REDIS_PASSWORD env (from GSM), but Redis won't enforce it — it's there so adding auth later doesn't require a backend deploy.

If you ever expose this Service outside the cluster, flip auth.enabled: true and wire the password into the Helm values from the same tomoda-redis-password GSM key the backend reads.

Persistence¶

Env	PVC size	Notes
dev	`5Gi`	RDB/AOF snapshots survive pod restart
prod	`10Gi`	Larger room for prod working set

Both use the cluster default StorageClass.

Resources¶

Env	Requests	Limits
dev	50m CPU, 64Mi memory	100m CPU, 128Mi memory
prod	10m CPU, 128Mi memory	1 CPU, 1024Mi memory

Metrics¶

Dev's values.yaml enables metrics.enabled: true, which runs the Bitnami Redis exporter sidecar and registers a ServiceMonitor in the monitoring namespace under release: monitoring — kube-prometheus-stack picks it up automatically.

Prod's values.yaml does not set the metrics block, so the exporter is off in prod. This is a gap: prod Redis has no Prometheus scrape today. If Redis becomes an alert source or SLO target, mirror the dev metrics block into the prod values file. Tracked here as a deliberate gap, not an accidental one.

DSNs (application-facing)¶

The Bitnami chart names its Service <release>-master. Applications connect to:

Env	Hostname	Port
dev	`redis-master.data.svc.cluster.local`	6379
prod	`prod-redis-master.data.svc.cluster.local`	6379

These hostnames are written into the Tomoda backend-config-<env> ConfigMap. The prod release is named prod-redis (see application.yaml metadata), so prod-redis-master is the rendered Service name.

Operations¶

Bounce — kubectl -n data rollout restart statefulset/<release>-master. With architecture: standalone there is no quorum to worry about; persistence survives the restart.
Console — use Redis Insight for a GUI, or kubectl -n data exec -it <release>-master-0 -- redis-cli for ad-hoc commands.
Storage expansion — bump master.persistence.size in values.yaml; commit and let Argo CD apply. PVC expansion on standard-rwo is online.
Chart upgrade — change targetRevision on the chart source. Review the Bitnami release notes — values keys do drift between major chart versions.