网易有道 | REDIS 云原生实战

REDIS 云原生实战

摘要
本次以Redis为范例，阐述了有道基础架构团队在基础设施容器化道路上的实践，主要将从声明式管理，Operator工作原理，容器编排，主从模式，集群模式，高可用策略，集群扩缩容等方面展开。

目录

• 背景
• 面临的挑战
• 声明式管理
• Operator工作原理
• 容器编排
• 主从模式
  • 主从拓扑图
  • 调和原理
• 集群模式
  • 集群拓扑图
  • 调和原理
• 高可用策略
  • Kubernetes保证的高可用
  • Redis集群的高可用
• 监控观测
• 集群扩缩容
• 总结与展望

背景

Redis 是业务系统中较为常用的缓存服务，常用于流量高峰、数据分析、积分排序等场景，并且通过中间件可以实现系统之间的解耦，提升系统的可扩展性。

传统物理机部署中间件，需要运维人员手动搭建，启动时间较长，也不利于后期维护，无法满足业务快速发展的需求。

云原生相较于传统IT，可以助力业务平滑迁移、快速开发、稳定运维，大幅降低技术成本，节约硬件资源。

云原生中间件是指依托容器化、服务网格、微服务、Serverless等技术，构建可扩展的基础设施，持续交付用于生产系统的基础软件，在功能不变的前提下，提高了应用的可用性与稳定性。

在这种大趋势下，有道基础架构团队开始了云原生中间件的实践，除了本文介绍的 Redis，还包括 Elasticsearch、ZooKeeper 等。

面临的挑战

利用云原生技术可以解决当前Redis部署缓慢，资源利用率低等问题，同时容器化 Redis 集群也面临着一些挑战：

• Kubernetes 如何部署 Redis 有状态服务
• 容器 Crash 后如何不影响服务可用性；
• 容器重启后如何保证Redis 内存中的数据不丢；
• 节点水平扩容时如何做到 slots 迁移时不影响业务；
• pod ip变化后集群的状态如何处理。

声明式管理

对于一个 Redis 集群，我们的期望是能够 7x24 小时无间断提供服务，遇故障可自行修复。这与Kubernetes API的声明式特点如出一辙。

所谓“声明式”, 指的就是我们只需要提交一个定义好的 API 对象来“声明”我所期望的状态是什么样子，Kubernetes中的资源对象可在无外界干扰的情况下，完成当前状态到期望状态的转换，这个过程就是Reconcile过程。例如，我们通过yaml创建了一个Deployment ,Kubernetes将“自动的”根据yaml中的配置，为其创建好Pod，并拉取指定存储卷进行挂载，以及其他一系列复杂要求。

因此，我们的Redis集群是否可以使用一个类似的服务去完成这个过程呢？即我们需要定义这样的对象，定义服务Reconcile的过程。Kubernetes的Operator刚好可以满足这个需求，可以简单的理解Operator由资源定义和资源控制器构成，在充分解读集群和Operator的关系后，我们将整体架构图设计如下

Operator集群本身采用Deployment部署，由ETCD 完成选主，上层与Kubernetes的Api Server 、Controller Manager等组件进行通信，下层持续调和Redis集群状态。

哨兵模式中Redis服务用一套哨兵集群，使用StatefulSet部署，持久化配置文件。Redis server也采用 StatefulSet部署, 哨兵模式的实例为一主多从。

集群模式中的每个分片使用StatefulSet部署，代理采用Deployment部署。原生Pod、StatefulSet、Service、调度策略等由Kubernetes本身负责。

Redis的资源定义在ETCD中存储一份即可，我们只需要预先提交自定义资源的 yaml配置。如下所示为创建三个副本的Redis主从集群：

apiVersion: Redis.io/v1beta1
kind: RedisCluster
metadata:
  name: my-release
spec:
  size: 3
  imagePullPolicy: IfNotPresent
  resources:
    limits:
      cpu: 1000m
      memory: 1Gi
    requests:
      cpu: 1000m
      memory: 1Gi
  config:
    maxclients: "10000"