Kubernetes中Redis StatefulSet读写路由及扩缩容适配方案咨询

一、读写分离：无需强制在应用层实现，K8s层面有多种可行方案 #

不用非得在应用层做读写路由，K8s生态里有成熟的集群层面解决方案：

• 哨兵（Sentinel）+ Headless Service 组合
  部署Redis Sentinel集群监控主从状态，同时给Redis StatefulSet的Pod添加角色标签（比如role=master/role=slave），Sentinel触发主从切换时同步更新对应Pod的标签。然后创建两个普通Service：一个标签选择器匹配role=master，专门承接写请求；另一个匹配role=slave，承接所有读请求。应用直接请求这两个Service的域名即可，完全不用感知底层节点变化。
• Redis Operator 托管方案
  用Redis Operator（比如Redis Labs官方的Operator）管理整个Redis集群，它会自动完成主从角色标记、Service创建与更新、故障切换等操作。Operator会自动生成两个Service：一个指向主节点，一个指向所有从节点，应用直接调用这两个Service就能实现读写分离，零应用层改造。
• 自定义Sidecar代理（小众方案）
  给每个Redis Pod附加一个Sidecar代理容器，让代理识别读写请求类型，自动转发到主节点或本地从节点。这种方案需要自行开发或配置代理规则，适合有特殊定制需求的场景，一般不推荐。

二、StatefulSet扩缩容时的流量路由保障 #

扩缩容过程中，做好以下几点就能确保流量正确路由：

• 自动标签同步
  扩缩容时，新加入的从节点会被Sentinel或Operator自动识别，打上role=slave标签，对应的读Service会自动把新Pod加入后端端点列表，流量会自然路由到新节点；缩容时，K8s会先从Service端点中移除待删除的Pod，再终止Pod，不会把流量发往已标记删除的节点。
• Headless Service 固定网络标识
  StatefulSet的Pod拥有固定域名（格式为<statefulset-name>-<序号>.<headless-service-domain>），扩缩容时新Pod的域名按序号递增，旧Pod域名保持不变。如果应用通过Sentinel获取节点地址，Sentinel会自动发现新节点并更新缓存，应用重新拉取地址即可路由到新节点；如果用Service路由，kube-proxy会自动同步端点变化，无需手动干预。
• 缩容时的平滑流量迁移
  缩容从节点前，可通过Sentinel将该节点的复制流量转移至其他从节点，或者让应用先停止向该节点发送请求（如果有会话绑定需求）。不过K8s的Service默认会在Pod终止前先移除端点，所以即使不做额外操作，也不会出现流量发往终止中Pod的情况。

内容的提问来源于stack exchange，提问作者Marvin