redis on k8s 优势很多：
1、可以通过运维平台对接k8s api，可以提高部署效率
2、扩缩容方便
3、迁移成本低，直连代理即可，和之前使用redis单机一样的配置
为什么这里没有采用小米的redis on k8s方案？
考虑到我们这很多微服务依赖的redis的压力并不大（大量1-4g实例），轻量级的redis主从即可满足需求，使用社区现有解决方案，基本不会增加运维成本。
如果引入predixy on k8s类的专业代理组件，需要投入的人力成本过大（predixy 在非k8s环境下之前也用过，偶发bug，目前我们团队也没有对其二开或bugfix的能力）
参考：
https://github.com/dandydeveloper/charts
https://artifacthub.io/packages/helm/dandydev-charts/redis-ha
架构如下图
看上去偏重些，redis的pod中有4个container，自带了prometheus监控和redis状态的治理，好在除了redis本身外其余container占用的资源都很少，整体还是可以接受的。
实战：
git clone 后， cd charts/
cp -a redis-ha redis-1g # ps：我这里是搞了个redis-1g的独立文件夹，专用于启动1g的redis主从例。
然后去修改下value.yaml中的配置：
1、redis的 replicas 从3改为2（节约资源）
2、开启haproxy的配置支持，并修改replicas 从3改为2（节约资源）
3、开启metrics和servicemonitor（用于自动化的指标数据采集）
4、启用sysctlimage，并优化些内核参数 （非必要，可选）
5、设置quorum为1，修改min-replicas-to-write: 0（默认配置不是这样的，我这里精简掉了1个slave，所以必须把配置也改低些）
6、显式设置 maxmemory: "1024mb" （强烈建议开启，写满后触发自动淘汰key，避免因为达到k8s的limits自动杀掉pod）
7、设置 maxmemory-policy: "volatile-lfu" （建议，非必须修改项）
8、设置resources limit和 request的值（生产pod必须显式设置）
9、hardantiaffinity值的设置 （生产必须设置为true，测试的话如果没有很多k8s节点，可以这个参数设置为false）
10、各种exporter都设置为true
我这里改好的yaml如下：
配置文件改好后，我们去部署：
helm install redis-arch redis-1g
注意： 这个redis的yaml中，是开启了持久化的，我们的k8s还需要配置个default storgeclass，我这里用的是本机nfs（生产上可以用其它的解决方案）
等容器都启动好后，最终效果如下：
可以去grafana画板子（这个git仓库里面，也自带了一个grafana的周边，感兴趣的可以自行试用），下面是我随手画的demo：
扩容和缩容：
1、修改redis的configmap，调大maxmemory
2、修改sts配置文件，调大 limits（limits要求比maxmemory大些）
修改sts配置后，会自动触发redis的pod的重建
重建过程中，redis会触发主从切换，但是因为前端有haproxy了，因此不可用时间通常在20s以内
tips：
如果用不惯helm这种方式的，我们也可以部署一套redis出来后，把它全部的yam都扒拉出来，然后把可能需要改动的地方都用变量替换，制做出一套模板。
这样我们就可以通过 自研的服务去调k8s api（甚至用jenkins包装下执行apply一系列的yaml也行） 达到快速拉起一套redis集群的目的。