背景知识
Kubernetes Operator 基于 Kubernetes 的资源和控制器概念构建。它使用自定义资源（Custom Resource, CR）来表示和管理应用程序，同时通过自定义控制器（Custom Controller）来监控资源状态并执行管理操作。
在容器环境使用有状态的中间件，包括mysql、redis、rabbitmq、kafka等等，你就会用到Operator，每种中间件的不同架构会有不同的量身定制的Operator。
变更原因
1.低版本的redis-operator存在bug，我们有套k8s集群建的比较早，使用了低版本operator，为保证运行安全，需要升级redis-operator到新版本；
2.为了满足某系统新增功能投产的资源需求，需要将redis集群进行扩容，增加计算资源大小。
处理经过
投产时我们先执行了第一步，成功完成了Operator升级，然后进行了扩容。
问题出现了。
问题1 Pod无法正常启动
扩容后，Pod无法正常启动。
原因分析：
由于升级了redis-operator，当修改了CR（Custom Resource）时，会重新触发operator，Redis集群的用户权限会发生变化，进而导致没有权限进行读写操作。
解决方案：
在cr实例添加了如下图所示的权限，10min以内故障解决完毕。
问题2 集群实例无法组建集群
现象：在解决了权限问题后，发现集群的6个实例无法正常组建集群。
尝试的解决方法：重启operator以重新识别集群，但未能解决问题。
最终解决方法：
1.关闭operator调度
通过命令kubectl annotate关闭operator的调度，改为人工组建集群。
kubectl annotate redisclusters.redis.redis.opstreelabs.in redis-cluster rediscluster.opstreelabs.in/skip-reconcile=true
2.手动组建集群
观察所有实例的nodes.conf文件，确保角色正确（避免数据丢失）。
在master节点之间执行cluster meet命令来组建集群。
在slave节点上执行cluster meet命令，并使用CLUSTER REPLICATE命令指定其复制的master节点。
检查集群关系和槽位分配是否正确。
将每个实例的nodes.conf文件复制到/data/nodes.conf下。
修改Redis的ConfigMap，添加cluster-config-file data/nodes.conf配置。
后续改进与优化
测试环境充分验证后择机将生产环境这套k8s集群中的redis集群切换成静态ip。
其它集群建得晚一些，已经采用了静态ip方案，不会有这个风险。
总结
容器环境下的redis集群，一定要使用静态ip。
