Redis Operator 在 Kubernetes 上使用哨兵自动故障转移功能创建,配置,管理高可用性 redis .zip

# redis-operator [](https://github.com/spotahome/redis-operator) [](https://goreportcard.com/report/github.com/spotahome/redis-operator) Redis Operator creates/configures/manages redis-failovers atop Kubernetes. ## Requirements Kubernetes version: 1.21 or higher Redis version: 6 or higher Redis operator is being tested against kubernetes 1.25 1.26 1.27 and redis 6 All dependencies have been vendored, so there's no need to any additional download. ## Operator deployment on Kubernetes In order to create Redis failovers inside a Kubernetes cluster, the operator has to be deployed. It can be done with plain old [deployment](example/operator), using [Kustomize](manifests/kustomize) or with the provided [Helm chart](charts/redisoperator). ### Using the Helm chart From the root folder of the project, execute the following: ``` helm repo add redis-operator https://spotahome.github.io/redis-operator helm repo update helm install redis-operator redis-operator/redis-operator ``` #### Update helm chart Helm chart only manage the creation of CRD in the first install. In order to update the CRD you will need to apply directly. ``` REDIS_OPERATOR_VERSION=v1.3.0 kubectl replace -f https://raw.githubusercontent.com/spotahome/redis-operator/${REDIS_OPERATOR_VERSION}/manifests/databases.spotahome.com_redisfailovers.yaml ``` ``` helm upgrade redis-operator redis-operator/redis-operator ``` ### Using kubectl To create the operator, you can directly create it with kubectl: ``` REDIS_OPERATOR_VERSION=v1.3.0 kubectl create -f https://raw.githubusercontent.com/spotahome/redis-operator/${REDIS_OPERATOR_VERSION}/manifests/databases.spotahome.com_redisfailovers.yaml kubectl apply -f https://raw.githubusercontent.com/spotahome/redis-operator/${REDIS_OPERATOR_VERSION}/example/operator/all-redis-operator-resources.yaml ``` This will create a deployment named `redisoperator`. ### Using kustomize The kustomize setup included in this repo is highly customizable using [components](https://kubectl.docs.kubernetes.io/guides/config_management/components/), but it also comes with a few presets (in the form of overlays) supporting the most common use cases. To install the operator with default settings and every necessary resource (including RBAC, service account, default resource limits, etc), install the `default` overlay: ```shell kustomize build github.com/spotahome/redis-operator/manifests/kustomize/overlays/default ``` If you would like to customize RBAC or the service account used, you can install the `minimal` overlay. Finally, you can install the `full` overlay if you want everything this operator has to offer, including Prometheus ServiceMonitor resources. It's always a good practice to pin the version of the operator in your configuration to make sure you are not surprised by changes on the latest development branch: ```shell kustomize build github.com/spotahome/redis-operator/manifests/kustomize/overlays/default?ref=v1.2.4 ``` You can easily create your own config by creating a `kustomization.yaml` file (for example to apply custom resource limits, to add custom labels or to customize the namespace): ```yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: redis-operator commonLabels: foo: bar resources: - github.com/spotahome/redis-operator/manifests/kustomize/overlays/full ``` Take a look at the manifests inside [manifests/kustomize](manifests/kustomize) for more details. ## Usage Once the operator is deployed inside a Kubernetes cluster, a new API will be accesible, so you'll be able to create, update and delete redisfailovers. In order to deploy a new redis-failover a [specification](example/redisfailover/basic.yaml) has to be created: ``` REDIS_OPERATOR_VERSION=v1.2.4 kubectl create -f https://raw.githubusercontent.com/spotahome/redis-operator/${REDIS_OPERATOR_VERSION}/example/redisfailover/basic.yaml ``` This redis-failover will be managed by the operator, resulting in the following elements created inside Kubernetes: - `rfr-<NAME>`: Redis configmap - `rfr-<NAME>`: Redis statefulset - `rfr-<NAME>`: Redis service (if redis-exporter is enabled) - `rfs-<NAME>`: Sentinel configmap - `rfs-<NAME>`: Sentinel deployment - `rfs-<NAME>`: Sentinel service **NOTE**: `NAME` is the named provided when creating the RedisFailover. **IMPORTANT**: the name of the redis-failover to be created cannot be longer that 48 characters, due to prepend of redis/sentinel identification and statefulset limitation. ### Persistence The operator has the ability of add persistence to Redis data. By default an `emptyDir` will be used, so the data is not saved. In order to have persistence, a `PersistentVolumeClaim` usage is allowed. The full [PVC definition has to be added](example/redisfailover/persistent-storage.yaml) to the Redis Failover Spec under the `Storage` section. **IMPORTANT**: By default, the persistent volume claims will be deleted when the Redis Failover is. If this is not the expected usage, a `keepAfterDeletion` flag can be added under the `storage` section of Redis. [An example is given](example/redisfailover/persistent-storage-no-pvc-deletion.yaml). ### NodeAffinity and Tolerations You can use NodeAffinity and Tolerations to deploy Pods to isolated groups of Nodes. Examples are given for [node affinity](example/redisfailover/node-affinity.yaml), [pod anti affinity](example/redisfailover/pod-anti-affinity.yaml) and [tolerations](example/redisfailover/tolerations.yaml). ## Topology Spread Contraints You can use the `topologySpreadContraints` to ensure the pods of a type(redis or sentinel) are evenly distributed across zones/nodes. Examples are for using [topology spread constraints](example/redisfailover/topology-spread-contraints.yaml). Further document on how `topologySpreadConstraints` work could be found [here](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/). ### Custom configurations It is possible to configure both Redis and Sentinel. This is done with the `customConfig` option inside their spec. It is a list of configurations and their values. Example are given in the [custom config example file](example/redisfailover/custom-config.yaml). In order to have the ability of this configurations to be changed "on the fly", without the need of reload the redis/sentinel processes, the operator will apply them with calls to the redises/sentinels, using `config set` or `sentinel set mymaster` respectively. Because of this, **no changes on the configmaps** will appear regarding this custom configurations and the entries of `customConfig` from Redis spec will not be written on `redis.conf` file. To verify the actual Redis configuration use [`redis-cli CONFIG GET *`](https://redis.io/commands/config-get). **Important**: in the Sentinel options, there are some "conversions" to be made: - Configuration on the `sentinel.conf`: `sentinel down-after-milliseconds mymaster 2000` - Configuration on the `configOptions`: `down-after-milliseconds 2000` **Important 2**: do **NOT** change the options used for control the redis/sentinel such as `port`, `bind`, `dir`, etc. ### Custom shutdown script By default, a custom shutdown file is given. This file makes redis to `SAVE` it's data, and in the case that redis is master, it'll call sentinel to ask for a failover. This behavior is configurable, creating a configmap and indicating to use it. An example about how to use this option can be found on the [shutdown example file](example/redisfailover/custom-shutdown.yaml). **Important**: the configmap has to be in the same namespace. The configmap has to have a `shutdown.sh` data, containing the script. ### Custom SecurityContext By default Kubernetes will run containers as the user specified in t