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>/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>/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: true
  sentinel: false
  existingSecret: redis-<env>-password-secret
  existingSecretPasswordKey: redis-password

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.

Auth

auth.enabled: true in both envs. Redis requires a password on every connection. The chart reads it from an existing Kubernetes Secret rather than generating one: auth.existingSecret: redis-<env>-password-secret, auth.existingSecretPasswordKey: redis-password (k8s/envs/{dev,prod}/redis/values.yaml).

That Secret is projected by an ExternalSecret (k8s/envs/{dev,prod}/redis/external-secret.yaml) from the per-env GCP Secret Manager key tomoda-redis-password-<env> into the redis-password key. The Tomoda backend reads the same value as REDIS_PASSWORD, so pod and clients stay in sync from a single source of truth.

Network exposure is still constrained independently: the Redis Service is reachable only inside the data namespace, gated by NetworkPolicies on the consumer side and by the absence of any Ingress or LoadBalancer pointing at Redis.

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-dev-master.data.svc.cluster.local	6379
prod	redis-prod-master.data.svc.cluster.local	6379

These hostnames are written into the Tomoda backend-config-<env> ConfigMap. The prod release is named redis-prod (see application.yaml metadata), so redis-prod-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.