携程Redis容器化实践
背景
携程大部分应用是基于CRedis客户端通过集群来访问到实际的Redis的实例，集群是访问Redis的基本单位，多个集群对应一个Pool，一个Pool对应一个Group，每个Group对应一个或多个实例，Key是通过一致性hash散列到每个Group上，集群拓扑图如截图所示。
这个图里面我们可以看到集群，Pool，Group还有里面的实例，这是携程Redis一个比较常见的拓扑图，如下图：
为什么要容器化
标准化和自动化
Redis之前是直接部署在物理机上，而DBA是根据物理机上设定的Redis的版本来选择需要部署的物理机，携程各个版本的Redis非常分散而且不容易维护，如下图所示，容器天然支持标准化，另外容器基于Kubernetes自动化部署的效率，根据我们估算，相比人工部署提高了59倍。
规模化
有别于社区的方案比如官方Redis Cluster或代理方案而言，携程的技术演进方案需要对大的实例进行分拆（内部称为CRedis水平扩容），实例分拆后，单个实例的内存小了，QPS降低，单个实例挂掉的影响小很多，可以说是利国利民的项目，但会带来一个问题，实例数急剧膨胀。容器化后我们能对分拆后的实例更好地管理和运维。
另外，分拆过程中需要大量中间状态的实例Buffer作为过渡，比如一对60G的实例分拆为5G，中间状态的Buffer需要24个60G的实例，纯人工分拆异常艰难，而且容易出错，依靠容器自动调度生成实例会极大降低DBA分拆时的心智负担，极大提升了分拆的效率并减少出错的概率。
提高资源利用率
借助于容器化和上层的Kubernetes的编排系统，我们很轻易的就可以做到资源利用率的提升，至于怎么做到的，后面细节部分会涉及。
能不能容器化
既然Redis容器化后好处这么多，那么Redis能不能容器化呢？对比测试最能说明问题。
实际上我们在容器化前做了很多测试，甚至因为测试模式的细微差别在各个部门之间还有过长时间的争论，但最终下面这几张图的数据获得了大家的一致认可，容器化才得以继续推广下去。
我们A/B对比测试都是基于相同硬件的容器和物理机，不挂slave，图上我们可以看到，Redis的响应相比物理机要慢一点，QPS也能看到差距很小，这些差异主要是容器化后经过多个虚拟网卡带来的性能损失。
这第三张图就更明显了，这是我们测试对比生产实际物理机的流量对比，我们测试的流量远高于生产实际运行的单台物理机的流量。
因此总结下来就是，容器与物理机的性能有细微的差别，大概5-10%，并且携程的使用场景Redis完全可以容器化。
以上介绍无非是容器化前的一些调研和可行性分析工作。
具体的架构如下图所示，首先最上层的是运维和治理工具CRedis和Rat，这个在携程内部是属于框架和DBA两个部门，CRedis不但提供应用访问Redis的客户端，本身也做CMS的工作，存储Redis实例最基本的元数据。
PaaS层为Credis/Rat提供统一的Redis Group/实例的创建删除接口，下面的Redis微服务提供实例申请具体的调度策略，基础设施有很多，这里其实只列举了一部分比较重要的，如网络相关的OVS和Neutron，与磁盘配额相关的Quota，以及监控相关的Telegraf等。X-Pipe是携程内部的跨IDC的DR方案，Sentinel就是官方的哨兵。
容器化遇到的一些问题
在我们容器化方案落地前遇到过一些具体的问题，例如：
Redis实际上是被应用直连的，我们需要IP和宿主机固定，并且Master/Slave不能在一台宿主机上。
部署之前是在物理机上，通过端口来区分不同的实例，所有的监控通过端口来区分。
重启实例Redis.conf文件配置不能丢失，这个在容器之前甚至不算需求，但放在容器上就有点麻烦。
Master挂了不希望Kubernetes立刻把它拉起来，希望哨兵来感知到它，因为Kubernetes如果在哨兵感知前拉起了它，导致哨兵还没切换Master/Slave，Master就活过来并且数据都丢失，这时候一同步到Slave上数据也全没有了，等于执行了一个清空操作，这对于业务和DBA来说是不能接受的。
实例几乎没有任何的内存控制，就是说实例不管写多大，都是得让Maxmemory一直加上去，一直加到必须迁移走开始，再把实例迁移走，而不能控制Maxmemory，让应用那边直接写报错。这个是最大的问题，决定了容器化是否能进行下去。如果不控制内存，Kubernetes的某些功能形同虚设，但如果控制内存，与携程之前的运维习惯和流程不太相符，业务也无法接受。
以上都是我们遇到的一些主要问题，有些Kubernetes的原生策略就可以很好地支持，有些则不行，需自研策略来解决。
Kubernetes原生策略
首先，我们的容器基于Kubernetes的Statefulset，这个几乎没有任何疑问，毕竟Redis是有状态的。
其次，nodeAffinity保证了调度到指定标签的宿主机，podAntiAffinity保证同一个Statefulset的Pod不调度到同一台宿主机上，toleations保证可以调度到taint的宿主机上，而该宿主机不会被其他资源类型调度到，如MySQL，App等，也就是说宿主机被Redis独占，只能调度Redis的实例。
上面提到的分拆其实也是基于nodeAffinity，podAntiAffinity等特性，我们内部划分出一块虚拟区域叫slaughterhouse，专门用于分拆，分拆完成再迁到常规区域。
自研策略
宿主机固定，这个是自研的调度sticky-scheduler来提供支持，如下图所示，在创建实例的时候会看annontation有没有对应host，有的话直接会跳过调度固化到该宿主机上，如果没有则进入默认的调度宿主机的流程。
虽然Redis对磁盘需求不多，但我们还是得防止log或rdb文件过大将磁盘撑爆，自研的chostpath和cemptydir都是基于XFS的Quotas很好的支持磁盘配额，并且我们将Redis.conf和data目录挂载出来，保证重启容器后配置文件不丢失，还可保证容器重启后可以读rdb数据。
比如我们在做风险操作升级kubelet时候可能会引起相关的Pod重启，但我们先对相关的Redis bgsave下，哪怕重启Pod也会读取对应的rdb数据，不会导致完全没有数据的尴尬场面。
监控方面，之前Redis部署在物理机上，通过端口来区分不同的实例，所有的监控通过端口来区分，但容器化后每个Pod都有一个IP，自然监控策略要变。
我们的方案是每个Pod两个容器，一个是Redis本身的实例，一个是监控程序Telegraf，每60秒采集一次数据发送到公司的统一监控平台Hickwall，所有的Telegraf脚本固化在物理机上，一旦修改方便统一的推送，并且对于Redis实例没有任何影响。
实践证明这种监控方案最为理想，比如有一次我们生产迁移集群后，DBA需要集群的聚合页面，也就是把所有的实例聚合在一起的按集群维度查看的页面，我们修改Telegraf的脚本将集群的信息随着实例推送过去立刻就能显示在监控页面上，非常方便。
下面两张图清晰地展示出容器的监控页面和物理机完全没有区别。
为了解决上文提到的Master挂了不希望Kubernetes立刻把它拉起来，希望哨兵来感知到它，我们用Supervisord作为容器的1号进程。当Redis挂了，Supervisord默认不会拉起它，但容器还是活的，Redis进程却不存在了，想让Redis活过来很简单，删除掉Pod即可。Kubernetes会自动重新拉起它。
最后再来看看最困难的，实例几乎没有任何的内存限制。实际上在容器上我们对CPU和内存也几乎没有限制。
CPU不限制主要是几个方面原因，首先，12核的机器上CPU Quota/Period =12， 按理是占满了整个机器，但压测时CPU居然有throttle，这明显不符合我们的客观直觉，我们怀疑Linux的CFS是有问题的，而且很神奇的是我们设置一个很大的Quota值后，也就是将CPU限额设置到50核，throttle消失了。
其次Redis是单线程，最多能用一个CPU，如果一个CPU跑一个Redis实例，肯定没问题，实际上我们设置两个实例分配到一个核也是完全可行的。
最后一个原因也是最主要的，Redis在物理机上运行是没有任何CPU隔离的。基于上面三个原因，我们让CPU超分。
关于内存超分，下面这张图清晰地说明了问题所在，对于只有一个100G的宿主机，只要放上2个实例，每个实例50G，它的内存就超了。内存超分好处很多，比如物理机迁移过来很平滑，用户也很能接受，运维工具几乎不需要修改就能套上去，但是，超分大法好，但OOM了怎么办？
方案是不让OOM发生，只要策略合适，这显然是可以做到的，在说到杜绝OOM的策略之前，先看下普通的调度策略。
我们在调度时对集群重要性进行了划分，主要分为以下几种：
基础集群，比如账号相关的，登陆相关的，虽然订单无关但比订单相关都重要。
接入XPIPE，订单相关的。
没有接入XPIPE，订单相关的。
订单无关但相对重要的。
既订单无关的又不重要的。
这样划分后，我们就可以很方便地让集群根据重要性按机器的高中低配来调度，并且让集群是否在多Region上打散。为了方便理解，这里一个Region可以简单等同于一个Kubernetes集群。
单个Region如下图，一个StatefulSet两个Pod分别是Master/Slave，每个Pod里面有两个容器，一个是Redis本身，一个是监控程序Telegraf，部署在两个Host上。
多个Region如下图，这时候，其实是有2个StatefulSet，这种方案可以扩散到更多Region，这样哪怕是某个Kubernetes集群挂了，重要的集群仍然有对外提供服务的能力。
介绍完一般的调度策略后，接着说上文提到的杜绝OOM的策略。首先，调度之前，对于不同配置的宿主机限定不通的Pod数量，此外设定10%的占位策略，如下图所示，并且设定Pod的request == maxmemory。
调度中，我们会基于宿主机实际的可用内存进行打分，在Kubernetes默认调度后，优选时我们会将实际剩余内存的打分赋值一个非常高的权重，当然基于其他策略的调度比如说CPU，网络流量之类我们也在研究，但目前最优先考虑的是实际剩余的物理内存。
以上这些策略可以杜绝大部分OOM，但还不够，因为Redis后续还是会自然增长的，所以在运维过程中，我们会有Job定时轮询宿主机，看可用内存和上面的Pod分配是否合理，对于不合理的Pod，Job会自动触发迁移任务，将一些Pod迁移到内存更空的机器上去，以达到宿主机整体可用内存方差最小。
还有一些其他的调度后的策略，比如动态调整Redis实例的HZ，我们曾遇到一个情况就是，在物理机上跑着一个实例大小都是10多个G，但跑到容器上后2天增加了20多个G。
我们排查后发现Redis的HZ值设置的过小，导致大量过期的Key没时间来得及清理，清理完成后发现，usedmemory是下来了，但rss还保持稳定，也就是碎片率很高，所以我们会动态打开自动碎片整理，整理一次完成后再关闭它，因为同时打开，消耗的CPU过高，目前情况下还不是很适合。
最后还有个保底的，基于宿主机内存告警，一般设置为80%即可，这种保底策略到目前为止也就触发过一次。
小结下，Redis跑在容器上，尤其在生产上大规模部署，需要多个组件共同协作才能达成。其次，携程的现状决定了我们必须超分，那么超分后如何不OOM是关键，我们从调度过程前中后容器层面和Redis层面分别都有相应的策略，调度上的闭环不但保证了Redis在容器上的平稳运行，而且资源利用率（如下图所示）也做到了非常大的提升。
最后再分享一下实践过程中的一些坑，这些坑其实本身不是Redis的问题，但都是在Redis容器化过程中发现的。
System Load有规模毛刺
首先是System Load有规模毛刺，每7小时一次，我们可以看到监控上，增加Pod后毛刺上升，但看上去跟CPU利用率没什么关系。
降低Pod数量，毛刺减小，但还存在，所以跟Pod数量正相关。
后来我们发现是telegraf监控脚本的问题。所有瞬间会产生很多进程的Job都会导致System Load升高。
对于Redis宿主机load异常情况，主要是因为监控程序每1min生成很多进程采集一次数据， System Load采集则是每5.001s采集一次，当Telegraf的第一次采集点命中System Load采集点后，第二次则需要5s*(5/0.001)=25000s，导致Load有规律每7小时飙高。
我们修改Telegraf中的collection_jitter值，用来设置一个随机的抖动来控制Telegraf采集前的休眠时间，确保瞬间不会爆发上百个进程，修改后，毛刺消失了，如下图所示：
Slowlog的异常
其次是Slowlog的异常，该问题根因在于4.9-4.13的内核的一个bug，会导致skylake服务器的时钟变慢，而该时钟不断地被NTP修正，所以导致Slowlog的两次打点时间过长，升级内核到4.14即解决该问题。
详细的分析可见这篇文章：《 携程一次Redis迁移容器后Slowlog“异常”分析》。
XFS bugs
还有一个是XFS的bugs，XFS我们发现的有两个比较严重的问题，第一个是字节对齐的问题，这个比较隐蔽，简答地说就是内核态的XFS header跟用户态的XFS header里面定义不同，导致内核在写XFS的时候会越界。下图中就是很明显的症状，我们升级4.14的内核对内存对齐打了patch解决了该问题。
XFS第二个问题是xfsaild进入D状态缓慢导致宿主机大量D状态进程和僵尸进程，最终导致宿主机僵死，典型的现象如下图。
这个现象在4.10内核发现很多次，并且猜测与khugepaged有关系，我们升级到4.14并Backport 4.15-4.19的XFS bugfix，压测问题还是存在，但比4.10要难以复现，在free内存超过3G后不会再复现。目前升级到4.14.67 Backport的新内核实际运行中还没出现这个问题。
本文转载自公众号：携程技术中心， 点击查看原文。
