得物容器SRE探索与实践

关于什么是SRE，以及在业务上有哪些具体的输出，网上资料众多但都只是对基本概念做描述。那容器SRE究竟要怎么结合业务，得物容器SRE又有哪些最佳实践，本文就得物容器SRE的一些事情向大家做介绍。,稳定性工程师，用软件工程解决复杂的运维问题，50%的时间用于运维琐事,50%的时间用于软件工程保障业务的稳定性和可扩展性，包括开发监控，日志，告警系统，业务性能调优等,,（a）清晰的问题升级路线,（b）清晰定义的应急事件处理步骤,（c) 监控巡检，如下:,查看监控，分析服务可用性下降或者耗时增加等影响服务质量的问题的根部原因。,,Oncall是直接体现SRE价值所在，能够直接影响MTTR时间的主要核心系数，一个好的Oncall甚至可以帮助公司挽回很多资损甚至是公司的形象，所以Oncall是每个SRE最重要的工作。,我们有自己的Oncall机制、适用范围、人员构成、复盘跟进、不同场景会邀请不同队员参与排障。有基本的故障处理原则，事故处理后的闭环。下图为整个Oncall流程的进行方式：,,当然每次都只是处理故障，恢复后不做总结归纳是不会有任何沉淀的，容器SRE会记录每次有意义的故障进行文案撰写并在故障中总结现有系统存在的工具类、平台类、代码类隐患点，分等级高中低进行推进push帮助业务，基架不断完善系统健壮性；,某天下午SRE侧开始陆续接到业务研发反馈redisRT 增长导致超时，其中某服务有多个 pod 存在redis RT 突增导致部分请求超时（截图如下）,,经过了一系列的驱逐与资源规整等止血操作后，该故障在30分钟后恢复。在这种场景下排查根因通常是一个很辣手的问题，因为第一现场很难在短时间内再进行模拟、恢复，第二在生产环境下不易做太多的测试工作。这种背景下就要发挥SRE的价值了。下面是叙述我们整个问题的排查思路与过程，希望能给大家一些借鉴。,排障过程描述只是说了一个思路，部分时间点可能和故障产生的时间重合,先排查是否是网络问题引起的，当问题发现解决后后我们梳理了对应的宿主机的信息，想发现一些规律来确认故障的根因；,,图上可见，这三台并不是一个网段的，唯一相同的也就是同一个区域，这个范围较大，不像是一个局部事件。所以我优先想到了云商故障；,为了进一步确认问题，我将对故障的 ecs ID 给到了阿里并进行了一个授权，随后还拉群做了语音讨论,接下来是整个根因排查分析：,翻阅故障时的监控发现，网络耗时在故障时间点附近比较平稳、经过和阿里内部监控的核对，当时问题宿主机网络延迟在故障时间点延迟仅从 2ms 增加到 4ms 所以可以排除是由于网络问题导致的,node监控有大量的异常包，drop 计数异常，常规情况下应该为0（上图），我们对这些drop 包做了分析（下图）发现Drop 的统计数非常高，同时tcpofo，tcprcvq这两个指标指向了TCP内存限制，需要扩充内存空间。,为了更进一步知道根因所在，我们又去观察了对应的 io夯、调度（任务等待）、 夯住（应用进程锁）、用户态内存等待、网络 (系统 5状态分类左图) （这里第一步已经排除了“网络”故障所以这里做了删除线处理），可以看到排查到io等待时间过长（下图）,IO平均等待时间在秒级以上，远超了正常范围，故开始排查percpu iowait 状况。经过一系列的操作最终我们使用sls 导入tidb 的方法数据做了一个可视化；,我们对那些 CPU iowait 比较高的筛选出来，看看能不能找到对应的业务（当时就怀疑是不是由于混部原因导致的）但是找了一圈没有发现什么问题。,绕了一圈发现线索又断了，还是回到那个TCP 内存限制的问题，为什么会判断tcpofodrop 指标会与tcp_mem 有关呢？可以直接看代码逻辑,内核源码网站推荐https://lxr.missinglinkelectronics.com/linux+v4.19/net/ipv4/tcp_input.c#L4459,（一个展示源代码存储库的软件工具集）,上面的逻辑简单叙述：TCP的核心预分配缓存额度函数为tcp_try_rmem_schedule，如果无法分配缓存额度，将首先调用tcp_prune_queue函数尝试合并sk_receive_queue中的数据包skb以减少空间占用，如果空间仍然不足，最后调用tcp_prune_ofo_queue函数清理乱序数据包队列 （out_of_order_queue）。简单说：如果内存分配失败，对应drop计数就会递增,另外当时我们也发现了dmesg日志里tcp oom的日志，如下图所示,于是就搜了一些实践准备将线上连接数比较高的那几台机器做一个替换处理试试,当时想准备替换的配置（当时这个调整低于线上目前的值）,当时线上内存,在check这些参数的过程中突然就发现了一个问题，我们线上的参数换算成内存值是48G左右，已经算大了，可以想象一下 tcp 链接总的内存已经用了48G！这部分还不光是网络开销只是一个 TCP 链接，我们就有 ss 看了下当时的链接情况：,通常出现这种情况的原因有以下两种：1、应用没有正确close他的socket进程 2、没有处理异常情况下的socket,感兴趣的同学可以看下这个文档（推荐）,​​https://stackoverflow.com/questions/38837724/linux-too-many-closed-connections​​,然后我们怎么找到是谁呢？通常情况下可以这么理解，一个 soket 就是一个 fd （句柄），对应soket 大必然fd 也大！（因为linux 一切皆文件）随后我们用了 for 循环查找对应的/proc 下的文件数量，结果如下：,附上命令参考：,为了确认又去容器中查看，确认无疑！,拉了对应引用的负责人后将结果反馈，业务得到信息后立即响应并将自己的应用做了下线处理，随后观察指标立马恢复了 – 破案~,这次故障我们深刻反省，同事建议将我们的系统参数的监控覆盖完全，所以之后我们立即就成立了一个项目，优化推进监控覆盖,继上文说到的故障后，我们意识到了容器监控上的不足故成立了专项来做内核参数上的监控。但是内核参数上千个我们怎么来做？,所以第一步就是完成内核指标罗列范围。我们对以往的故障和反馈分析来看，网络故障发生较为频繁，所以范围圈定为宿主机网络指标为主；网络指标在系统中主要由/proc/net/netstat提供，所以我们罗列了他所提供的所有指标；（如图是netstat的所有指标）,有了范围我们要制定采集方案有些是node-export需要特殊配置才能采集到的具体方案；比如下面要增加netstat的监控是需要启用node-export对应的扩展包,第二个就是通过开源的采集组件监控不到的数据比如tcp.socket.mem这部分只能靠自己开发完成。如下图通常采用截取字段方式将os的状态指标采集到,有了采集后就是完成指标的展示与统计，我们通过/proc/net/netstat获取到了46个网络指标，同时也借鉴了业内的最佳实践总共55个指标的罗列与代表的意义，并将各内核常见参数 含义及公式形成文档，解决了很多参数不目的不明确的问题，下图是我们展示这些指标的案例截图,完成了展示后，我们就需要对这些核心内核指标参数进行分类（这些指标存在问题可能会影响业务正常运行）,以上55个指标大多为辅助定位的指标，作为业务类型不同，关注的指标与内核参数的调整是有区别的,通用类型default资源池模型；（注重并发，多链接，多请求的场景）监控参考如下：监控统计可以看到资源使用比较平均，需要均衡的参数配置,算法类型高密度计算类型资源池；（主动睡眠，被动睡眠，看调度延时，cpu消耗在用户态还是内核态）监控参考如下：监控统计可以看到 cpu大多使用率较高,大数据类型 专有集群资源池；（关注网络IO，磁盘IO，文件系统cache，网络开销大）监控参考如下：监控统计可以看到网络上开销较大,然后我们就对这三个类型的主机分别做了参数调整和铺平，由于文章长度关系亲，就不做详细描述了。完成了调整后我们怎么去维护和管理这些内核参数呢？这里我们对内核参数管理也做了一个方案，保障这次治理后是长久有效的。具体的流程如下：,,有整理出的内核指标后还会通过日常的监控、巡检对某些需要调整的内核参数做出修改，由于是wget统一拉取的，所以在update的时候只要通过修改oss里面的批量类型init.sh就可以做到了，不需要修改每一个资源池配置,,为了更安全起见，我们还做了内核初始化兜底保障功能，当然我们在以往的经历中发现，有些节点会因为网络变更等原因拉不到oss的初始化文件，且Ali没有这块初始化的提示，所以kube-node会有一个初始化的兜底，如果节点启动初始化失败会检测到对应的错误数据并将其修改为正常值,,整套上线后，我们配置了7个监控告警项，在实际运行中发现5次以上隐患问题提前在故障发生前就预先进行了处理，保障了产线的稳定性运行。至此，整个故障算是画上了圆满的句号,上面正好说到兜底保障，其实我们在整个容器集群里部署有多个保护系统，下面我就举例一个防误删场景的方案。,首先我们来参考下某知名大厂的防控体系,,从架构看来，大致分为三大块：权限、风控、流控,权限管控：,2018年某大厂整体架构开始往社区K8S方向迁移。迁移是个非常漫长的过程，需要考虑很多的细节。最开始自然是K8S权限体系管控问题，不同BU、不同平台、基础组件，都要跟新的ASI对接，第一件事情就是 申请项目专用账号 。当时SRE开了个Git仓库，专门用于各个 基础业务方 提交 账号申请信息，格式是按照 K8S标准权限资源 进行提交。,除了 RBAC，SRE还管控 CRD、WebHook 、Kubeconfig 等核心资源,风险控制Webhook风控：,不同平台方、业务方一般在自己的前端或者后端都有对应的逻辑进行风险控制。但是也搞不好业务方在逻辑上存在Bug或者不够完善的地方，因此在最基础的底层上，需要有个SRE的WebHook对所有请求进行拦截校验兜底。,流量控制K8S-Defender,阿里搞的 K8S防火墙主要针对于API流量风控，早期是Webhook机制实现，但是K8S-Webhook天然存在一些缺陷，比如无法站起全局视角进行精准流控，因此后面是独立出来了。做成了C/S模型，但需要强制让所有接入ASI的基础组件在关键的位置统一使用 Defender 做K8S流量风制，这个目前在得物这个阶段很难推得动，所以可以降级到Webhook机制去实现。,他山之石，可以攻玉。我们可以参考,这里分为硬性和软性两种方式。,对于核心的Namespace，例如 kube-system、monitoring。不应该以任何理由删除，这类Namespace可以 普通账号直接锁死，即便你RBAC里面拥有删除NS的权限，就不允许删除。,对于 Addons 或者 纯业务类型的Namespace，因为可能出现调试场景，比如：调试或者测试某个复杂的Addons组件，因为牵涉到太多的配置和资源，过程中已经混乱不堪，想彻底干净地重装一遍，回到初始状态。这种情况下是需要利用K8S级联删除特性，把该Namespace包括下面所有资源清理一次。如果锁死该Namespace，业务方遇到这种情况，就会很麻烦，所以这个场景走 硬性防删 就不是明智之举。,相对于硬性防删，我们引入了软性防删策略。也就是对于非核心的Namespace，在一定的时间内，我们对删除的请求做计数统计，在没达到阀值之前，会一直拒绝删除。并在返回的结果上给予风险提示，如果N秒内再提交X次，则真的执行删除动作。这种方式对业务方明显会更加友好一些，一方面起到了一定防误删效果，另一方面也不至于在你真正想删除的时候删不掉。,另外我们还开发了一种策略，专门针对批量删除Namespace的场景。对于我们目前Namespace的使用方式是不合理的，说不定哪天可能会对Namespace做治理，以域的方式来确定Namespace。这个时候就会涉及到大量Namespace的清理工作。这种合法的删除，如果不断地被Webhook拦截中断，这不是个合理的设计。所以我们支持以管控标降级策略，也就是给对应的Namespace打一个管控标，则Webhook对这类Namespace就主动做降级处理，不再校验拦截。这样运维就可以正常地做批量删除动作。,K8S WebHook 机制，是可以对任意带Namespace的CRD|CR进行拦截。其拦截逻辑是可以共享的，只是资源类型不一样。所以我们可以动态配置，拦截逻辑对哪些资源生效。,支持 Ingress、WorkLoad、Service、ConfigMap、Secret、Pod … 类型资源，并支持标签筛选能力,对于 Ingress 规则配置比较复杂，很多初学者会犯一些低级错误。比如：rule.host 配置为 ‘*’ ，这意味着该规则匹配所有域名，所有请求都会过这条规则进行转发，显然生产环境这种配置是不合理的。而且一旦配置上可能会覆盖掉大量的rule，导致生产故障。所以这类低级错误配置一定要拦截，不允许配置。,这里就简单画下方案图，大致基本借助于webhook的能力，对一些删除动作的时候加强校验与拦截的机制。,,上述几个案例都是得物容器SRE团队在日常工作中真实发生的事件，覆盖的也只是多项工作中的冰山一角，写这篇文章也是想让大家认知到我们团队，了解我们容器SRE。由于篇幅有限其余细节不再展开了，大家有疑问欢迎找我讨论。同时也欢迎对容器/云原生/SRE 等领域感兴趣的同学加入我们。,我们是得物容器SRE团队。,我们团队的宗旨是为全司提供稳定、高效、安全的支撑和服务。,服务项目：业务稳定性保障，线上业务系统变更，业务性能&状态监控，容量评估；核心业务场景梳理，识别关键链路和关键接口，制定服务保障预案，对关键链路实施故障演练，确保服务的连续性。得物容器化集群维护、系统网络维护以及系统基础组件维护。保障基础环境的稳定、高效，并提供丰富的工具和平台提升系统的自动化、可视化、智能化。