Disclaimer: Redis is a registered trademark of Redis Ltd. Any rights therein are reserved to Redis Ltd. Any use by SAP is for referential purposes only and does not indicate any sponsorship, endorsement, or affiliation between Redis Ltd. and SAP.
This repository adds a new resource type Redis (redis.cache.cs.sap.com) to Kubernetes clusters,
which can be used to deploy redis caches for cluster-internal usage. For example:
apiVersion: cache.cs.sap.com/v1alpha1
kind: Redis
metadata:
name: test
spec:
replicas: 3
sentinel:
enabled: true
metrics:
enabled: true
tls:
enabled: trueThe controller contained in this repository under the hood uses the bitnami redis chart to install redis in the cluster. As a consequence of this fact, the following topologies are supported:
- statically configured master with optional read replicas
- sentinel cluster (i.e. dynamic master with read replicas, master elected by sentinel).
Sharding (redis-cluster) scenarios are not supported.
If spec.sentinel.enabled is false, one redis master node will be deployed, and spec.replicas - 1 read replicas.
Both master and read nodes are reachable at dedicated services; since the master statefulset currently cannot be scaled beyound 1,
only the read part is truly highly available.
If spec.sentinel.enabled is true, then an ensemble of spec.replicas nodes will be deployed, each of which runs the actual redis service, and a sentinel sidecar. As long as a quorum of sentinels is available (more than 50%), they will form a consensus about which of the redis services has the master role, and configure the redis instances accordingly. There will be one service, exposing the sentinels at port 26379, and the redis caches at port 6379; clients which just want to perform read operations, can directly connect to the service at 6379; in order to write to redis, clients have to connect to the sentinel port of the service first, in order to detect the address of the current master, and then connect to the retrieved address at 6379.
Note that the field spec.sentinel.enabled is immutable.
TLS encryption can be turned on by setting spec.tls.enabled. Without further configuration, a self-signed certificate will be created.
As an alternative, if available, certificate and key can be retrieved from cert-manager. With
spec:
tls:
enabled: true
certManager: {}a self-signing issuer will be generated; an existing issuer could be referenced as well, such as:
spec:
tls:
enabled: true
certManager:
issuer:
# group: cert-manager.io
kind: ClusterIssuer
name: cluster-caAOF persistence can be enabled by setting spec.persistence.enabled to true. It may be tweaked by setting
spec.persistence.storageClass and spec.persistence.size; note that the latter fields are immutable.
If spec.metrics.enabled is set to true, an prometheus exporter sidecar will be added to the pods, which can be scraped
at port 9121 (optionally via the corresponding service and ServiceMonitor, if prometheus-operator is used).
By default, a binding secret like the following will be generated:
apiVersion: v1
kind: Secret
metadata:
name: redis-test-binding
type: Opaque
stringData:
caData: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
host: redis-test.testns.svc.cluster.local
masterName: mymaster
password: BM5vR1ziGE
port: "6379"
sentinelEnabled: "true"
sentinelHost: redis-test.testns.svc.cluster.local
sentinelPort: "26379"
tlsEnabled: "true"The format of the secret data can be overridden by specifying a go temmplate as spec.binding.template.
In that go template, the following variables may be used:
.sentinelEnabled(whether sentinel mode is enabled or not).masterHost,.masterPort,.replicaHost,.replicaPort(only if sentinel is disabled).host,.port,.sentinelHost,.sentinelPort,.masterName(only if sentinel is enabled).tlsEnabled(whether TLS encryption is enabled or not).caData(CA certificate that clients may use to connect to redis)
The following attributes allow to tweak the created pods/containers:
spec.nodeSelectorspec.affinityspec.topologySpreadConstraintsspec.tolerationsspec.priorityClassNamespec.podSecurityContextspec.podLabelsspec.podAnnotationsspec.resourcesspec.securityContextspec.sentinel.resourcesspec.sentinel.securityContextspec.metrics.resourcesspec.metrics.securityContext
For topology spread constraints, a special logic applies: if undefined, then some weak spread constraints will be generated, such as
topologySpreadConstraints:
- labelSelector:
matchLabels:
app.kubernetes.io/component: node
app.kubernetes.io/instance: test
app.kubernetes.io/name: redis
maxSkew: 1
nodeAffinityPolicy: Honor
nodeTaintsPolicy: Honor
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: ScheduleAnyway
matchLabelKeys:
- controller-revision-hashThis does not harm but helps to ensure proper spreading of the redis pods across Kubernetes nodes.
In addition, if a supplied constraint misses both labelSelector and matchLabelKeys, then
these attributes will be automatically populated by the controller, as in the above example.
The recommended deployment method is to use the Helm chart:
helm upgrade -i redis-operator oci://ghcr.io/sap/redis-operator-helm/redis-operatorThe API reference is here: https://pkg.go.dev/github.com/sap/redis-operator.
This project is open to feature requests/suggestions, bug reports etc. via GitHub issues. Contribution and feedback are encouraged and always welcome. For more information about how to contribute, the project structure, as well as additional contribution information, see our Contribution Guidelines.
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone. By participating in this project, you agree to abide by its Code of Conduct at all times.
Copyright 2024 SAP SE or an SAP affiliate company and redis-operator contributors. Please see our LICENSE for copyright and license information. Detailed information including third-party components and their licensing/copyright information is available via the REUSE tool.