共计 8807 个字符，预计需要花费 23 分钟才能阅读完成。
本文系作者 GOPS 寰球运维大会演讲内容，由高效运维社区整顿。
本次主题次要会包含两个方面，首先面对云原生技术的疾速倒退和落地，传统运维体系应该怎么去构建及过程中遇到的冲击和挑战，会有一个简略的剖析。
其次，在面对不同的挑战时咱们做了哪些事件，我会依据外部实际来做一些分享，心愿能给大家一些参考。
对于运维来说，其实就是效率、稳定性、老本。其实，不论是稳定性，还是晋升运维效率都是为了钱：效率晋升了能缩小人力老本，稳定性保障 / 监控报警做得好，能够少故障少赔钱。对于运维来说，当然还有一个十分重要的是平安，不过明天咱们不会怎么讲平安。
在正式开始之前，我先简略介绍一下网易这边的技术状况。网易外部的各个 BU 之间的技术栈往往是有很大差别的，比方游戏、音乐、严选等，基本上能够认为是齐全不同行业的，都有本人的特色以及行业背景，这导致在网易建设大一统的平台不太事实，所以咱们更关注一些更轻微的点。
1. 运维的新挑战
新技术栈
网易数帆部门大略从 Kubernetes 1.0 公布时就开始接触容器了，大规模应用容器是在 18 年前后。业务应用容器后面临的首个挑战是全新的技术栈，这个时候运维体系该如何布局？相干的技术选型，包含网络 / 存储计划的抉择，集群规模容量布局，往往因为后面的短视造成前面的很多窘破。
容器化的场景下，对于 Kubernetes 的应用上，咱们没有对业务部门做任何限度，业务部门能够任意调用 Kubernetes API。因为应用模式多样，导致运维保障面临更多挑战。很多因为业务的误用导致的问题，一样须要运维保障来兜底。
晚期基础设施（包含 Docker/ 内核 /Kubernetes）始终 Bug 一直，比方，Docker 18 年前很多的经典 Bug，咱们都遇到过。不过这两年比拟新的版本问题曾经少了很多了。
咱们部门应用的支流操作系统发行版是 debian，可能跟在座各位同仁绝大部分应用 centos 的不太一样。Debian 发行版的益处是内核以及软件版本都绝对较新。所有遇到的内核问题，也是须要咱们本人去解决修复。
另外，容器化刚开始的时候，毕竟是新的技术栈，想招到匹配岗位的人才较艰难，人力老本比拟高。
技术惯性
技术惯性大家比拟能了解，很多公司都有本人的传统的运维平台。从传统的运维平台到转变应用 Kubernetes 来做公布治理，从思维上，操作形式上，实现形式上多个方面，咱们发现两头有很多鸿沟，弥合鸿沟也是很苦楚的事件。
这样就导致开发人员的一个认知，原本虚拟机用得好好的，你们搞什么容器，当初出问题了吧，反正赖容器就对了。
一句话，传统的运维开发方式对云原生没有做好筹备。
知识库
知识库的问题，首先云原生落地过程中，以后状态很多知识库还不够欠缺，有时候遇到问题去搜寻的话，还是会抓瞎的。
咱们团队的人员因为解决了大量的实际问题，经验丰富，咱们也输入了不少文档。
然而咱们发现业务方真正遇到问题的时候，压根不翻文档，而是间接甩给咱们。当然这外面的起因，可能是因为不足云原生相干技术背景有余而看不懂，或者就是一个意识问题。总的来说，知识库的传承老本比拟高，一些问题的预案和效率是极低的。
咱们认为推动云原生容器化落地过程中运维在这一块目前面临比拟大的挑战。
组织与人员架构
在传统开发场景下最上层是开发、测试，两头会有业务的架构团队、利用运维、零碎运维、平台开发，上面是整个 IDC 的基础设施保障，整个架构层次分明。
但如果某个公司正在做云原生容器化落地，你会发现中间层成为了一团浆糊，多多少少大家工作都有一些穿插。如果一个平台开发不晓得业务方应用容器的姿态，可能会呈现业务方会用各种奇怪的玩法而导致出问题，最初还是运维运维来兜底。
问题的起因在于每个工程师的定位产生了扭转，比方 SA 以前只治理机器，当初会波及到容器的网络和存储，须要去理解 Kubernetes 的工作原理，这样一来很多人都必须去学习 Kubernetes。
容量治理
对于容量，有几个方面。一个是业务方不合理申请资源，另一个是业务方也无奈预知状况，比方忽然来了一个促销之类的流动，容量需要增长。
运维 Kubernetes 还一个比拟要害的容量问题是，管制组件的资源耗费的容量评估经常被疏忽。客户往往部署了 Kubernetes 集群并配置了报警，而后后续就不停地加节点。忽然某一天产生了事变崩掉了，找运维问怎么回事，后果可能发现就是管控面容量有余了。
这里展现一个截图，因为 Kubernetes APIserver 重启了一下，内存在极短时间减少了百分之二十多，重启的那一刹那会有大量的申请进来，导致内存耗费得比拟厉害。这种状况下，个别都会配置有阈值报警。当然如果你不解决这种问题，一旦触发了，接下来可能会呈现雪崩效应，再也拉不起来了，直到你增大资源容量为止。
接下来简略从方才我说的运维提效、稳定性保障、老本上咱们做的实际。
2. 运维提效
首先咱们集群应用了中心化的托管，当然并不是所有部门都是咱们管的，咱们只管跟咱们关系比拟亲密的集群。整个权限认证体系，间接走我外部的员工认证零碎，做到了对立认证，权限还是走 RBAC，受权到集体。其次是因为咱们大量的人力在帮客户做排障，不同人和不同部门一遍遍找过去，不违心看文档和你做的事件，你兜底就能够了，咱们团队始终是超载的状态。因而，咱们要把一些常见的排障诊断过程做成自动化。最初，针对监控数据这一块，监控数据的存储没有间接应用开源零碎，而是应用外部实现的 TSDB，来把监控数据对立存下来，这样能够更好对数据进行生产。
上面说下自动化诊断运维，方才后面的两位老师也都分享过相似的内容。相似的，咱们也是有知识库和流水线执行。很多公司做流水线的时候是做了本人外部一个平台，和其余的外部零碎进行对接，这样一来可能解决了本人的问题，然而通用性并不高。咱们在网易外部面临什么问题呢？咱们还按那种形式去做他人不会用你的货色，因为你是一个平台。别的部门要和它的做适配用起来比拟苦楚。咱们更多想通用一些计划，Kubernetes 场景下有 CRD 的反对，把运维诊断、性能排查等各种货色形象成 CRD 的形式去做。
咱们把一个运维操作形象成一个原子运维操作 Operation，把一个机器设置为不可调度，判断是不是合乎某个已知 Bug 场景等。多个 Operation 的编排会形成一个运维流水线 OperationSet。针对诊断上下文，咱们做了个 Diagnosis 的形象。
诊断流水线的触发形式能够有更多种。首先用户能够本人手动创立一个 Diagnosis 执行。
咱们外部也应用泡泡（网易外部的 IM）聊天机器人，来实现 Chatops，通过与机器人聊天来触发相干的流程。对于聊天机器人，咱们不想去做比较复杂的常识了解，咱们更多的是很间接的。给聊天机器人发绝对结构化的语句，通知他你帮忙我看一下什么问题就能够了。因为咱们公司整个认证体系是一块的，泡泡机器人也会通过对立的认证体系，能够很轻易找到你的权限，防止你做一些超过权限的事件。通过这种 ChatOps 你能够触发流水线的执行。
还有一个更大的流水线触发源，就是监控报警的触发。比如说业务的某个利用，容器应用的 CPU/ 内存占用达到了阈值之后，能够主动触发一次拿堆栈的信息，做内存的 dump，而后把对应的对战信息，以及 dump 的内存文件上传到对象存储外面去。接下来的流程中，是能够把这些 dump 进去的数据拿进去进行剖析的。
当然有一些像中间件也会有这样一些状况，他们往往要做稳定性保障，如果我的中间件实例呈现了某种状况，应该执行什么操作？相似于这样的逻辑咱们也能够把它编排起来，这样咱们能够让其余的 operater 来去创立这种咱们新的 Diagnosis 的 Oparater，通过这种形式把这个货色实现起来。
简略来说咱们整个场景就是 Kubernetes 下的一套利用，就是用 apiserver 承受相干的 CRD，而后用 Operator 做执行，大略就是这么一个货色。
这块咱们心愿这个货色后续在外部把它做成一个平台，咱们心愿这个货色更泛化来看，就是通过一个事件触发一个流程，做一些运维操作、运维诊断，传统遗留下来的脚本都能够残缺继承下来。详见：KubeDiag 框架技术解析
因为 Kubernetes 是规范的 API，如果说你是基于 Kubernetes 的场景，那咱们的一些教训可能是对你们有用的，很多货色景是共通的。比方，大家可能都遇到过内核版本在 4.19 之前的，memcg 的回收解决是有问题的，会导致大量的泄露，包含像 Docker 的晚期版本也会有大量的容器删除不掉的问题。
咱们都有一系列的 workaround 的伎俩，这样的伎俩咱们能够把它做得十分的智能化，比如说咱们报警监测到一个 Pod 退出超过 15 分钟，还没有被干死，那咱们可能就触发一次诊断，来看是不是已知的 Bug，如果是的话，咱们就通过一些伎俩把它主动复原掉。这种类型的诊断是通用的。
在传统的场景下，可能不同的公司，运维人员登陆机器的形式都不一样，因而传统的场景下咱们没有方法做到通用。然而 Kubernetes 的场景下咱们能够做到通用，因为 Kubernetes RBAC 能够做权限管制，咱们整体的有 daemonset 的形式去对你的过程做一操作，去帮你收集很多货色是能够做到的。
还有比拟头疼的，像很多做 AI、大数据相干的，次要是 AI 训练，他们有 C /CPP 代码，会呈现 coredump，coredump 会带来几个问题，会导致本地的磁盘过后使用率会很高，会影响同节点上其余的业务。这个时候咱们能够通过一些办法，做到全局对立的本地不落盘的 coredump 采集。还有像发数据包、打火焰图等等相似这种，很多时候像性能诊断，还有一些惯例的软件 Bug workaround 是十分通用，这个都是底层的能力了。
咱们再往上思考业务层面也会有一些很通用的能力，比如说一个 Node 呈现半死不活的状态能够把 Node 隔离掉等等。咱们心愿前面可能把这个货色做得更欠缺一点，心愿有更多的场景，有更多人参加进来。
咱们整个我的项目是一个框架加很多的规定，这块目前也曾经把这个货色放出去了，咱们短期内的一个想法是把界面做好一点，而后咱们把之前传承下来的很多教训输入成代码，放到流程外面去，达到开箱即用的流程体验。
对于提效这一块通过这种形式可能做到什么成果呢？不再让咱们团队 Overload 了，不必看文档看怎么回事主动解决掉了，解决本人人力消耗的问题。同时这个货色是绝对代码化的，不存在某个兄弟比拟猛技术比拟好，他走了搞不定了，因为代码留下来了。
3. 监控与报警
稳定性大家晓得 Tracing、logging 和 Metric，然而像 Tracing 和 logging 几年前提得比拟少，当初分布式场景下的很多问题，导致分布式 Tracing 也做起来了。然而 Metric 这方面始终是一个金字标，明天也次要关注的是 Metric 这一块。
在采集零碎指标时，传统的形式可能是 *stat 数据，各种从 procfs 中的数据进行采集，当初咱们心愿通过 eBPF 拿到更细粒度的数据。采集这些个细粒度的数据的次要起因是分清责任。比方业务方要查一下业务抖动，可能是基础设施和机房的问题，这个时候很难自证清白。能够通过这样的伎俩，像咱们采集 TCP 的 RTT 数据能够证实是不是零碎的问题。
内存更多是内存回收相干的，像 Memory Cgroup 相干的回收、PageCache reclaim 这类报警的指标采集了不少。CPU 调度这块，基本上就是关注调度延时，过程从它变成 Running 到开始运行到底提早了多长时间。
还有像文件 IO，有时候磁盘会抖一下，抖一下有的业务方异步写日志不受影响，如果是全同步会导致受到影响。这个时候咱们须要定位到到底是什么起因导致的。咱们还须要监督，像 VFS 的提早等等，这些指标都须要从底层去获取到。
像 eBPF 当初反对 uprobe 技术，因而还能够做另外一块。比方传统监控利用拜访数据库，会在客户端，像 Java 程序通过 agent 注入一些字节码加强来发现拜访 MySQL 快了还是慢了。如果有了 uprobe 机制，在 MySQL 或 Kafka，代码固定状况下能够用 uprobe 勾服务端的函数，不再从客户端的形式抓问题了。
这时候也是自证清白的，比如说用户本人代码有 Bug，他认为是你后端 Redis 出问题了，你能够说数据没有到我这里来，我函数执行勾进去了，成果是好的。这一块以后咱们还是在尝试和落地中。
而后在 Tracing 畛域的话，像一些伎俩是通过日志剖析，通过 SDK 代码外面打日志的。事实上如果在一些传统的利用，一些十分老的遗留的利用外面，你不太好让他做这样的集成的时候能够用 uprobe 的伎俩拿到外面动静的信息。也能够在在网络层面，做一些 Redis 协定的解析，能够通过网络输入流量层面拿到错误信息、提早信息，谬误。这个相干的实现绝对简单一点，这个阶段咱们是尝试落地阶段。
当然咱们当初做这个事件十分细粒度指标对于内核版本要求比拟高，咱们外部有一个部门的内核版本曾经到 5.13 了，比拟激进。
这样以来造成咱们采集到指标比拟多，指标是用来做报警的，报警其实不好做，后面两个老师也始终在提这个问题，报警解决什么问题？第一不该报警不能报进去，第二该报的报警都要报进去，这两个都不好解决。
报警的治理
首先传统的阈值报警有什么问题呢？它会变的，你明天的申请和今天的申请因为什么起因就变了。要么就是没有疾速配、改阈值呈现了问题，或者是呈现了误报警你本人吓一跳，会导致这种状况。无阈值报警相干的想法，大略咱们从 2017 年、2018 年开始摸索的货色，只不过咱们当初往云原生去做移植。
还有一块是关联报警克制的问题，比如说你磁盘慢了，磁盘慢了会导致什么问题呢？会导致用户打日志会卡，日志一卡像 Java 程序会导致解决线程增多，线程池会爆掉，导致响应提早变低等一系列的影响。事实上你想一下这些报警之间还是有关联的，咱们报警的时候可能只须要报进去磁盘慢就能够了，其余没有必要报，其实须要一个报警关联作为克制的策略。
这块怎么做的呢？大家明天看到了 AIOps 的专场外面人十分多，大家都会对这样一些话题感兴趣。目前来看不论是实际还是个人感觉来看，齐全依赖 AI 不是那么事实的，至多当初这个阶段如同没有看到很好的实际。
咱们当初更多是做了数理统计，有大量的机器学习算法帮忙咱们建模，这个建模更多是剖析繁多指标或者是相关联的指标，相关联的指标还是靠教训输出，不是真正主动剖析。因为到当初为止，还是不置信 AI 真的能达到那么好的智能。
咱们目前依赖数理统计算法，正态分布等等，应用十分根本的机器学习算法通过离线计算，来生成模型，而后实时计算模块做异样检测，达到无阈值报警的状态。还有关联报警克制，关联报警克制是输出进去的，不是机器学习学习进去的。
还有报警的反馈问题，报警之后检测异样发给你一个报警，这个报警是不适合或者是有问题的你能够做一个调参。比如说咱们算某一个指标的周期函数做拟合，拟合某个参数，它的周期就是有问题，咱们假设就是不对的能够手动调一下、改一下都能够。或者是有些报警瞎报有问题的，咱们克制掉就好了。
咱们心愿能做好一整套，从监控到问题触发，到整体离线计算、实时计算，人工反馈回去这样做的闭环，使得这个货色做上来。
这是咱们对于监控和报警这块的内容。
4. 老本的节约
老本节约伎俩
上面就是老本方面。老本治理在网易这边，包含之前面临最大的问题，一个事业部当初忽然间来了一批工作，咱们网易有做内容平安的，在某些时候，会忽然有大量的业务过去。他们机器不够用，就会到处借机器、协调机器，节约了大量的人力精力。
当初咱们做这样的伎俩，心愿把外部资源池做得更好一点。老本节约主体就是资源配置的举荐问题，刚刚嘉宾也说到这样的问题，包含升配、降配这样的问题，就是 VPA。VPA 其实还是蛮有意义的货色。
另外混合部署，在业界也是比拟热的。这个货色落地下来可能真的很艰难，可能真不的适宜很多中小企业。
还有刚刚说到交融外部的资源池，心愿构建大的池子，供每个业务部门来应用。
还有业务推动的问题，从老板到干活的，你做新的货色不可避免会有不稳固因素。咱们的理论教训，你在做容器化的时候遇到问题从业务方看来都是容器的问题，你在做混合部署的时候遇到所有问题，业务方都认为是混合部署导致的问题，业务方认为他本人一点问题都没有，然而最初查下来都是业务方的问题，你要通知他有问题。
上面简略说一下咱们的两块内容，一块是混合部署，一块是资源交融的。
混部零碎
网易在前年开始尝试落地混合部署，当初曾经领有肯定的规模。
首先是两块，一块是调度，一块是隔离，调度咱们做得比较简单，尽管业界有机器学习、资源画像、资源调度等论文和实际，但咱们目前只是基于实时数据采集来做根据。
从理论来看，基于实时监控数据来去看资源的使用量，目前来看还算好。也就是说不太会有某个在线业务真的不停在稳定，至多能够让离线业务绝对安稳运行一段时间。
隔离伎俩
隔离伎俩次要有几块，计算次要就是 CPU 的调度和内存治理。CPU 的调度传统的 CFS 的 Share 隔离有一点问题，因为它的一个要求，偏心调度不论你的业务优先级多低都是偏心的。还有最小调度延时的问题，跑肯定的工夫才会切换 CPU。像离线的业务跑起来，比方大数据的业务，CPU 肯定是满的，会造成在线业务肯定的提早是失常的。业界有比拟好的落地案例，腾讯开了本人的调度类，阿里云有本人的技术，叫 Group Identity。相似的货色业界有些实际，咱们外部会参考他人的思考联合到本人的版本外面去。
还有超线程相干的，不晓得大家分明不分明，超线程如果在物理核上理论是单核。不同场景下会有不一样，然而个别咱们认为大略 120%-130%，并不是两个核的算力，这样一来如果说你的离线业务和在线业务在一个物理核的两个超线程上，在线业务会受到十分大的烦扰，在这块在调度器上能够做一些躲避。
还有像 L3 隔离，咱们基本上限度离线工作的量。
Page Cache 回收对在线业务根本可控，然而对于中间件服务来说，根本是不可控的。如果你的 Page Cache 回收没有解决好的话，非预期被回收掉会造成性能极大降落，或者是始终不回收导致业务 OOM 掉。因为咱们内核版本比拟新，外面也加了一些主动回收和被动回收的伎俩。
最初，混部最大的落地挑战就是离线业务往往须要做到存算拆散，这个跟 IDC 的基建相干。在自建 IDC 会发现 IDC 可能是 N 年前建的，老旧的设施能不能撑持全链路 QoS，都是打问号的。之前遇到过交换机的坑，当把流量打满，离线业务拜访远端存储的网络是满的，这个时候触碰交换机的 Bug，会导致一些随机性的提早，排查起来是很苦楚的。
在 IO 隔离这一块，尽管 CgroupV2 外面有很多 Buffer IO 隔离策略，但可能最简略粗犷的还是用不同的块设施，这是最简略的。
目前网易外部的隔离伎俩还是抉择简略和普适性，并没有谋求极致的混合部署成果。
资源池交融
网易外部的各个部门绝对独立，意味着每个部门都有多套 Kubernetes 集群。如果一个业务的集群资源大量残余，另一个业务的资源齐全不够用怎么办？咱们做了一个超大的资源池叫 Kubeminer，咱们把业务的 Kubernetes 集群分为 Consumer 和 Provider，一个资源的生产方，一个资源的提供方，都应用 KubeMiner 的形式模仿虚构节点。
对于资源生产方来说看到了虚构节点，对于资源提供方来说齐全无感知，因为帮别人把业务跑到他的集群外面去，两头进行了转化。
通过这种形式把之前单集群的资源扩大到所有其余 Kubernetes 的集群里去。这样如果某个业务方容量没有布局好，或者是某个时间段内资源残余比拟多，他能够把资源卖给他人。如果某个业务资源方长期有些需要，能够看看他人谁有资源。
为什么做成这种架构？首先这个比拟普适，对于 Consumer 来说无非改一下业务调度条件，把业务调度到虚构节点就能够了，Provider 来说齐全无感知，他们无非看到跑了一堆我不意识的 Pod 上来。
还有一个益处对业务零感知，业务不必做特地多的适配，对于 Consumer 还是在本人的集群，对于 Provider 没有感知，因为不关怀这个货色。咱们两头要做结算体系，咱们要给他把钱算清楚，这是咱们的工作。
难点
难点列了三个，组织状态导致咱们呈现了十分决裂的场景，每一方的 Kubernetes 集群网络计划不一样，有各种各样的网络计划，咱们做对立资源池的时候要做到互通，这是咱们做的过程当中认为挑战比拟大的。
还有对跨集群对象同步，尽管你把 Pod 调度过去了，然而像 PV，像 Service 拜访、ConfigMap 之类的 token 等等都要在这个集群中同步，因为咱们要做到让他体验到在本人集群一样。
还有咱们怎么做最佳撮合？什么意思呢？业务方须要 10 个 Pod，Provider 没有一个集群可能承当 10 个 Pod 的容量，怎么办？咱们要往好多个集群去分。那咱们怎么把它做得更好一点？因为底下 Provider 集群还在动静变，人家原本也在用，这个时候咱们怎么做到达到绝对好的成果？这一块咱们当初伎俩比较简单，基本上依据教训简略配了一些参数，因为当初的参数去撮合。
大略就是这样子，目前没有做特地简单的算法，后续可能会在调度机制上做一些伎俩。
落地成果
明天的整体分享大略就这些，最初有一个成果，整体老本节约产生的一些价值，咱们外部并没有做到很极致，均匀 CPU 利用率到 55% 而已；某事业部的视频转码业务实现了没有耗费任何的实在资源，都以低优先级的工作在混部着跑；通过弹性的资源池形式聚合了各种各样 Kubernetes 集群的算力资源，给其余业务方向提供了弹性资源能力。
明天就到这里，谢谢大家。
作者简介
王新勇，网易数帆容器编排团队负责人，曾参加网易团体负载平衡，SDN 等我的项目建设，目前次要在推动网易互联网业务云原生技术落地，致力于云原生环境下的稳定性保障和老本优化相干工作。
理解更多
KubeDiag 框架技术解析
