Operations
Backup And Restores
Custom Secret
Monitoring
tpl
Modify Redis Parameters
Database reconfiguration involves modifying parameters, settings, or configurations to optimize performance, security, or availability. Parameter changes fall into two categories:
Type | Restart Required | Scope | Example Parameters |
---|---|---|---|
Dynamic | No | Immediate effect | max_connections |
Static | Yes | After restart | shared_buffers |
For static parameters, KubeBlocks minimizes downtime by:
- Modifying and restarting replica nodes first
- Performing a switchover to promote the updated replica as primary (typically completes in milliseconds)
- Restarting the original primary node
KubeBlocks Redis Addon does not implement any dynamic reload action for Dynamic Parameters
, thus changes on any parameters will cause a restart.
This guide demonstrates how to modify static parameters of a Redis cluster managed by KubeBlocks using a Reconfiguring OpsRequest.
Prerequisites
Before proceeding, ensure the following:
- Environment Setup:
- A Kubernetes cluster is up and running.
- The kubectl CLI tool is configured to communicate with your cluster.
- KubeBlocks CLI and KubeBlocks Operator are installed. Follow the installation instructions here.
- Namespace Preparation: To keep resources isolated, create a dedicated namespace for this tutorial:
kubectl create ns demo
namespace/demo created
Deploy a Redis Cluster
KubeBlocks uses a declarative approach for managing Redis Replication Clusters. Below is an example configuration for deploying a Redis Replication Cluster with two components, redis and redis sentinel.
Apply the following YAML configuration to deploy the cluster:
apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:
name: redis-replication
namespace: demo
spec:
terminationPolicy: Delete
clusterDef: redis
topology: replication
componentSpecs:
- name: redis
serviceVersion: "7.2.4"
disableExporter: false
replicas: 2
resources:
limits:
cpu: '0.5'
memory: 0.5Gi
requests:
cpu: '0.5'
memory: 0.5Gi
volumeClaimTemplates:
- name: data
spec:
storageClassName: ""
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
- name: redis-sentinel
replicas: 3
resources:
limits:
cpu: '0.5'
memory: 0.5Gi
requests:
cpu: '0.5'
memory: 0.5Gi
volumeClaimTemplates:
- name: data
spec:
storageClassName: ""
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
Verifying the Deployment
Monitor the cluster status until it transitions to the Running state:
kubectl get cluster redis-replication -n demo -w
Expected Output:
NAME CLUSTER-DEFINITION TERMINATION-POLICY STATUS AGE
redis-replication redis Delete Running 3m49s
Check the pod status and roles:
kubectl get pods -l app.kubernetes.io/instance=redis-replication -L kubeblocks.io/role -n demo
Expected Output:
NAME READY STATUS RESTARTS AGE ROLE
redis-replication-redis-0 3/3 Running 0 3m38s primary
redis-replication-redis-1 3/3 Running 0 3m16s secondary
redis-replication-redis-sentinel-0 2/2 Running 0 4m35s
redis-replication-redis-sentinel-1 2/2 Running 0 4m17s
redis-replication-redis-sentinel-2 2/2 Running 0 3m59s
Once the cluster status becomes Running, your Redis cluster is ready for use.
If you are creating the cluster for the very first time, it may take some time to pull images before running.
Check Parameter Values
Retrieve Credentials
KubeBlocks automatically creates a secret containing the Redis root credentials. Retrieve the credentials with the following commands:
NAME=`kubectl get secrets -n demo redis-replication-redis-account-default -o jsonpath='{.data.username}' | base64 -d`
PASSWD=`kubectl get secrets -n demo redis-replication-redis-account-default -o jsonpath='{.data.password}' | base64 -d`
Access Redis Cluster
To connect to the cluster's primary node, use the Redis client:
kubectl exec -it -n demo redis-replication-redis-0 -c redis -- redis-cli -a ${PASSWD}
Query Parameter Values
Once connected, you can query the current value of 'max_connections' and 'shared_buffers':
127.0.0.1:6379> CONFIG GET aof-timestamp-enabled
1) "aof-timestamp-enabled"
2) "no"
Static Parameter Example: Modifying aof-timestamp-enabled
Create a Reconfigure OpsRequest. Apply the following OpsRequest YAML to set the 'aof-timestamp-enabled' to 'yes':
apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: redis-reconfigure-static
namespace: demo
spec:
clusterName: redis-replication
reconfigures:
- componentName: redis
parameters:
- key: aof-timestamp-enabled
value: 'yes'
type: Reconfiguring
Check the status of the OpsRequest until it completes:
kubectl get ops redis-reconfigure-static -n demo -w
Example Output:
redis-reconfigure-static Reconfiguring redis-replication Running -/- 5s
redis-reconfigure-static Reconfiguring redis-replication Succeed -/- 33s
Verify the Configuration Change
Log into the Redis instance and confirm that the aof-timestamp-enabled
parameter has been updated:
127.0.0.1:6379> CONFIG GET aof-timestamp-enabled
1) "aof-timestamp-enabled"
2) "yes"
Cleanup
To remove all created resources, delete the Redis cluster along with its namespace:
kubectl delete cluster redis-replication -n demo
kubectl delete ns demo
Summary
This guide covered modifying Redis parameters through KubeBlocks:
- Static changes require restart but with minimal downtime
- All changes are validated before application
- Configuration follows declarative management principles