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 。