Hello team, Regarding the deployment of GoodData.CN in Kubernetes, I wanted to get a clarification for the following: I am able to set the values (in Helm) for service.redis.hosts (e.g.,

redis.host.example

), but I am unable to set the value for the redis database number: • Does

gooddata-cn

write keys to the next available database? The default database (index 0)? Multiple? • If it uses one DB, then can I specify the host as such: e.g.,

redis.host.example/5

? • Is this Redis service stateless? Or does it perform regular backups/snapshots? Do you recommend persistence? Thank you for your time!

Hi, you can't specify redis db number, default

0

is used. This is particularly important if your Redis is running in clustered configuration, there's only db 0. And even the Redis author himself doesn't consider using multiple databases as a good idea [link] so I'd recommend to avoid it if possible. To your other questions: There are basically two deployment methods for Redis compoment. 1. Use built-in Redis deployed as a helm sub-chart, that is by default deployed as 3-node StatefulSet (1 master, 2 replicas) with persistence and sentinel. GoodData CN uses sentinel to connect to redis-ha StatefulSet and uses db 0. Failover is done automatically using sentinel protocol. 2. The other option is to deploy Redis-compatible service manually as a external service (e.g. cloud-based ElastiCache) and configure GoodData CN helm chart to connect to it. In this case you need to set

deployRedisHA: false

and use

service.redis

value object to configure connection parameters, as shown in docs. It's up to you what topology you choose, if you'll use redis cluster or just plain replication. In case of redis-ha sub-chart deployment, the db is periodically stored to persistent volume, but we don't do anything else with that dumps. You may add extra tooling that would perform volume snapshots, send it to S3 or whatever you like. But in my opinion it is not worth of effort. The redis keeps only precomputed result caches so in case you'll lose all 3 replicas at once, no big disaster will happen, sooner or later, data will be recomputed and stored in redis. I hope I answered to all your questions. If not, do not hesitate to ask again.

Thank you @Robert Moucha, everything is clear now on my side!

@Robert Moucha Thanks for the amazing reply. 1. What is the specific reason for using

StatefulSets

? Is it to guarantee that each pod will use the same volume in case of restarts or failures?

that is by default deployed as 3-node StatefulSet (1 master, 2 replicas)

2. Does it requires the cluster to have >= 3 nodes? Or are we talking only about the number of replicas of the pods?

1. StatefulSet preserves hostnames and since we use headless service on top of this statefulset, your redis pods always get the same hostnames (without random suffix as with Deployment). It ensures reasonable stablity for redis clients when they discover redis member nodes. Also, rollout upgrades are done differently and are better suited for pods with persistent volumes. 2. the total number of pods in statefulset is 3; one pod is configured as read-write master, the other two are read-only replicas. when master pod stops responding or terminates, one of remaining replica pods takes over the master role (based on leader election results), sentinel updates topology and starts to redirect client writes to the new master. when the original master comes back online, it joins cluster as a new replica. Refer to public docs for details.