作者｜張云楊
在 Kube.NETes 大行其道的今天，數據庫容器化對于云原生團隊而言是一個極具吸引力，但往往不知道從何下手的挑戰。
開源 MySQL、PostgreSQL 誕生于 PC Server 時代，往往被用于存儲業務的重要數據，放到 Kubernetes 里面也許需要更多的投入和勇氣；但是對于 redis 這種跟容器技術誕生于同一個時代，而且大多只用作緩存用途的數據庫，容器化是否就更加容易呢？很多云原生團隊確實是這樣想的，但是真正實踐后才發現 Redis 這個“軟柿子”并不是那么好捏。
太容易了吧，只是...
Redis 容器化的起步非常容易，通過 Redis 官方提供的 Docker 鏡像幾秒鐘就可以拉起 Redis 服務。將應用與 Redis 部署在同一個 Kubernetes 極大簡化了上手難度，只有兩個小小的問題：
Redis 服務并不是高可用的
只要 Redis 容器發生調度，Redis 容器的 IP 就會變化，應用側的連接池配置也會隨之失效。為了適應容器環境的起伏，Redis 容器的 IP 不能直接暴露給應用，需要增加 VIP 或 DNS 域名來提供固定的連接地址。
Redis 服務并不是高可靠的
只要 Redis 容器所在的宿主機發生宕機，Redis 容器的持久化卷就可能發生損壞，應用數據也會隨之丟失。雖然有大量開發者將 Redis 當作易失的內存數據庫來使用，但是也有不少開發者將 Redis 用作鍵值數據的持久化存儲，所以 Redis 容器化不可避免地涉及到分布式塊存儲或本地盤同步方案，只有這樣才能具備數據持久化能力。
不出意外的話，
就要出意外了
通常，雄心勃勃的云原生團隊當然不能滿足于提供玩具級別的 Redis 服務，對多個 Redis 容器進行編排的進階方案自然而然地被提上議程。在進階方案里面，Redis 服務將具有多個分布于不同宿主機的 Redis 容器（副本），可以應對一到多個 Redis 容器的故障，能夠提供持續可靠的服務。
Redis 內核并不具備分布式能力，需要引入外部組件來完成 Redis 容器的角色判斷和復制關系配置。Sentinel（哨兵）組件在這方面久經考驗，社區也提供了相應的容器編排方案。用 Bitnami 提供的 Redis Helm Chart 就可以很容易部署出含有 Sentinel 組件的 Redis 主備集群。只要正確配置副本數、規格參數并對內核參數做少量調整，Redis 服務的質量立即就能抬升一個檔次。如果應用負載較為穩定，這個方案的效果會很不錯。但是一旦涉及到故障或擴縮容場景，馬上會遇到幾個不那么容易解決的問題：
Redis 服務能力存在永久受損的風險
云原生團隊往往沒有現成的分布式塊存儲，本地盤資源相對比較常見。當 Redis 容器被分配到本地盤宿主機后，容器就會變相被“固定”到該宿主機上。遇到硬件故障時，如果宿主機能迅速恢復，那么上面的 Redis 容器也能隨之快速恢復；反之，Redis 容器將會一直處于 Pending 狀態，無法被調度到其它健康的宿主機上。雖然 Redis 服務依舊是可靠可用的，但是服務能力會受到永久損傷，而 Pending 的容器狀態也能順帶逼死患有強迫癥的工程師。
Redis 服務能力的天花板較低
在本地盤宿主機場景下，Redis 服務能力的天花板也是比較低的。被“固定”到宿主機上后，Redis 容器的內存使用上限也被限制在了該宿主機上。宿主機上面運行的容器越多，Redis 容器能使用的內存就越少。相同的問題也會發生在 Redis 容器能使用的存儲容量上。因為被“固定”在宿主機上，Redis 容器能使用的存儲容量上限就是其它容器用剩的宿主機本地盤余量。CPU 資源的問題倒是沒那么明顯，Redis 用不了多核，云淡風輕。
Redis 服務的擴縮容問題
在遇到業務高峰的時候，難免需要對 Redis 服務進行擴容。根據遇到的容量挑戰，擴容手段又分為垂直擴容和橫向擴容兩個大類。如果業務整體數據量沒變，只是需要緩存的熱點數據變多了，那么垂直擴容一下 Redis 容器的內存就可以了；但是一旦業務的整體數據量變大了，需要垂直擴容存儲容量，云原生團隊就無法通過 helm 修改 StatefulSet 配置實現變配，只能切換到手工模式劫持底層 PVC 才能實現。劫持的代價會在以后需要進行橫向擴容的時候暴露出來，新增的 Redis 容器會采用老的配置，原本同構、自動化的 Redis 服務，變成了異構、手工的縫合怪。
還有隱藏關卡！
高可用、高可靠方面的問題，從架構設計和拓撲圖上一眼就能看出來，一般在 Day 1 就會被云原生團隊關注和解決；而服務能力在特定場景下的挑戰是比較微妙的，取決于真實的業務場景和云原生團隊的經驗，往往在 Day 2 才會被察覺。審慎的云原生團隊不應該在生產環境使用原生的 Kubernetes 工作負載來運行容器化的數據庫，這就像坐著用紙糊的船出海一樣危險。
Kubernetes 提供的自定義資源能夠更好地聚合存儲、計算和網絡資源，通過 API 的方式提供“聲明式”的數據庫服務。目前市面上有幾個知名的 Redis Operator 提供了更進一步的方案，幫助云原生團隊解決 Day 2 的常見問題，比如：
- Redis Enterprise Operator by RedisLabs
- KubeDB by AppsCode
- KubeBlocks by ApeCloud
- Redis Operator by Spotahome
- Redis Operator by OpsTree
RedisLabs、AppsCode 和 ApeCloud 提供的 Operator 功能是企業級的，在能力方面更完整；而 Spotahome 和 OpsTree 提供的 Redis Operator 則是完全開源的，功能雖然少但勝在簡單易懂。通過 Release Notes 和 Changelog 可知，Spotahome 最后一次發布版本的時間是 2022.1.19 而 OpsTree 則是 2022.11.10，對問題的響應速度上面恐怕會差點意思，這一點需要特別注意。
無論選了哪一款 Redis Operator，云原生團隊都要有這樣一個預期：真實業務場景下的網絡環境非常復雜，有可能會對 Redis 服務支持的網絡方案帶來挑戰。這個挑戰往往會發生在跨 Kubernetes 部署的新應用需要讀寫存量 Redis 集群的時候。如果沒有規劃好應對措施，很有可能會阻礙業務的上線效率。考慮到業務側存在多種 SDK 的使用方法，Redis 服務需要支持如下的部署模式才能滿足長遠的要求：
- 單節點（客戶端只訪問主庫）
- Redis Server 通過 Nodeport 暴露主庫的地址
- Redis Server 通過 LoadBalancer 暴露主庫的地址
- 雙節點（客戶端只訪問主庫）
- Redis Server 通過 Nodeport 暴露主庫的地址
- Redis Server 通過 LoadBalancer 暴露主庫的地址
- 雙節點或多節點（客戶端訪問 Sentinel 實現讀寫分離）
- Redis Server 和 Sentinel 組件通過 HostNetwork 暴露 Redis、Sentinel 的副本地址
- Redis Server 和 Sentinel 組件通過 Nodeport 暴露 Redis、Sentinel 的副本地址
- Redis Server 和 Sentinel 組件通過 LoadBalancer 暴露 Redis、Sentinel 的副本地址
- Sharding
- Redis Server 通過 HostNetwork 暴露副本地址
- Sharding + Proxy
- Proxy Server 通過 Nodeport 暴露連接地址
- Proxy Server 通過 LoadBalancer 暴露連接地址
咦，為什么 Redis Sharding 跟其它的形態不一樣，只能使用 HostNetwork？這涉及到 Redis 官方跟云廠商的各種博弈。簡而言之，就是官方想把 Sharding 形態作為收費功能，而代碼的 License 又是 BSD 協議的。為了不讓云廠商薅到羊毛，Redis 官方故意沒有實現 announce-ip 的功能，使得原生的 Redis Sharding 形態無法運行在云廠商的網絡環境。然而，云廠商也不甘示弱，“幫”Redis 官方把 announce-ip 功能的坑給填上了，付出了一點點代價就能繼續大賣特賣。討厭的是，Redis 官方和云廠商的拉鋸，導致 Redis Sharding 形態在容器環境里只能使用 HostNetwork 暴露地址，為云原生團隊帶來了額外的阻力。這些商業利益的糾葛，也是 Redis 容器化過程中需要不斷被關注到的。
^_^ 我還是要捏~
是不是覺得 Redis 容器化并不是那么好上手，公有云全托管服務收些溢價也情有可原？
這個感覺沒錯，但是別急著放棄。公有云廠商最重要的數據庫技術方向之一就是容器化，而容器化的挑戰起點就是保障彈性能力以及支持多種網絡方案。在塊存儲、對象存儲、VPC 網絡以及四層負載均衡等支撐性產品的加持下，公有云廠商實現數據庫容器化會更加容易，技術方案上面也會更加花哨（比如固定容器 IP、升級 Kuberntes 不重啟等等）。而大部分云原生團隊沒有軟件定義存儲（SDS）和軟件定義網絡（SDN）的支持，實現數據庫容器化就會更有挑戰。
幸運的是，大部分云原生團隊需要支持的業務場景也不像公有云廠商所面臨的那么復雜，如果能夠選對方向、收斂需求，循序漸進地積累生產經驗，數據庫容器化的考驗就不會呼嘯而來。業界也不乏 Redis 容器化的實踐分享，有的大幅降低了成本，有的讓業務團隊實現了 self-serving。
沖著提升資源利用率和研發效能的收益，這個柿子就算有點硬，也值得一捏。
作者信息：
張云楊，前阿里云數據庫產品負責人，2016-2019 年任阿里云數據庫產品總監，負責 RDS、PolarDB、Redis、MongoDB 等核心產品。目前作者就職于云猿生數據，是容器化數據庫管控 KubeBlocks 和 Serverless MySQL 的產品負責人。
逃離 windows！德國又宣布遷移到 linux，涉及數萬系統、3 萬余人，官員吐苦水：Windows 對硬件要求太高了
李彥宏：大模型開源意義不大；騰訊云后臺崩了；離開百度7年后，吳恩達官宣加入亞馬遜董事會 | Q資訊
走進 AI 高薪族：小而美團隊成主流，博士生招聘需求飆升 430%！
用 100 年前的架構和淘汰的軟盤技術，美國列車系統升不了級：要花費十年、上百億美元，“風險太大！”
