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叢集的目的。