您好，登录后才能下订单哦！
密码登录
登录注册
点击 登录注册 即表示同意《亿速云用户服务条款》
作者 | 张晓宇（衷源） 阿里云容器平台技术专家
导读：资源利用率一直是很多平台管理和研发人员关心的话题。本文作者通过阿里巴巴容器平台团队在这一领域的工作实践，整理出了一套资源利用提升的方案，希望能够带给大家带来一些讨论和思考。
不知道大家有没有过这样的经历：当我们拥有了一套 Kubernetes 集群，然后开始部署应用的时候，我们应该给容器分配多少资源呢？
这很难说。由于 Kubernetes 自己的机制，我们可以理解容器的资源实质上是一个静态的配置。
试问，我们能做到容器资源的按需分配吗？接下来，我们将在本次分享中和大家一起进行探讨这个问题的答案。
首先请允许我们根据我们的实际情况抛出我们实际生产环境的挑战。或许大家还记得 2018 年的天猫双 11，这一天的总成交额达到了 2135 亿。由此一斑可窥全豹，能够支撑如此庞大规模的交易量背后的系统，其应用种类和数量应该是怎样的一种规模。
在这种规模下，我们常常听到的容器调度，如：容器编排，负载均衡，集群扩缩容，集群升级，应用发布，应用灰度等等这些词，在被“超大规模集群”这个词修饰后，都不再是件容易处理的事情。规模本身也就是我们最大的挑战。如何运营和管理好这么一个庞大的系统，并遵循业界 dev-ops 宣传的那样效果，犹如让大象去跳舞。但是马老师曾说过，大象就该干大象该干的事情，为什么要去跳舞呢。
cdn.com/a20c0dfb35bf47b45d1f7791daa53c7531222775.png">
大象是否可以跳舞，带着这个问题，我们需要从淘宝、天猫等 APP 背后系统说起。
这套互联网系统应用部署大致可分为三个阶段，传统部署，虚拟机部署和容器部署。相比于传统部署，虚拟机部署有了更好的隔离性和安全性，但是在性能上不可避免的产生了大量损耗。而容器部署又在虚拟机部署实现隔离和安全的背景下，提出了更轻量化的解决方案。我们的系统也是沿着这么一条主航道上运行的。假设底层系统好比一艘巨轮，面对巨量的集装箱---容器，我们需要一个优秀的船长，对它们进行调度编排，让系统这艘大船可以避开层层险阻，操作难度降低，且具备更多灵活性，最终达成航行的目的。
在开始之初，想到容器化和 Kubernetes 的各种美好场景，我们理想中的容器编排效果应该是这样的：
然而理想很丰满，现实很骨感。迎接我们的却是杂乱和形态各异的窘迫。
杂乱，是因为作为一个异军突起的新型技术栈，很多配套工具和工作流的建设处于初级阶段。Demo 版本中运行良好的工具，在真实场景下大规模铺开，各种隐藏的问题就会暴露无遗，层出不穷。从开发到运维，所有的工作人员都在各种被动地疲于奔命。另外，“大规模铺开”还意味着，要直接面对形态各异的生产环境：异构配置的机器、复杂的需求，甚至是适配用户的既往的使用习惯等等。
除了让人心力交瘁的混乱，系统还面临着应用容器的各种崩溃问题：内存不足导致的 OOM，CPU quota 分配太少，导致进程被 throttle，还有带宽不足，响应时延大幅上升...甚至是交易量在面对访问高峰时候由于系统不给力导致的断崖式下跌等等。这些都使我们在大规模商用 Kubernetes 场景中积累非常多的经验。
问题总要进行面对的。正如某位高人说过：如果感觉哪里不太对，那么肯定有些地方出问题了。于是我们就要剖析，问题究竟出在哪里。针对于内存的 OOM，CPU 资源被 throttle，我们可以推断我们给与容器分配的初始资源不足。
资源不足就势必造成整个应用服务稳定性下降。例如上图的场景：虽然是同一种应用的副本，或许是由于负载均衡不够强大，或者是由于应用自身的原因，甚至是由于机器本身是异构的，相同数值的资源，可能对于同一种应用的不同副本并具有相等的价值和意义。在数值上他们看似分配了相同的资源，然而在实际负载工作时，极有可能出现的现象是肥瘦不均的。
而在资源 overcommit 的场景下，应用在整个节点资源不足，或是在所在的 CPU share pool 资源不足时，也会出现严重的资源竞争关系。资源竞争是对应用稳定性最大的威胁之一。所以我们要尽力在生产环境中清除所有的威胁。
我们都知道稳定性是件很重要的事情，尤其对于掌控上百万容器生杀大权的一线研发人员。或许不经心的一个操作就有可能造成影响面巨大的生产事故。
因此，我们也按照一般流程做了系统预防和兜底工作。
但是对于陡然增加几分钟的突增流量，这么多组合拳的花费不菲，似乎有些不划算。或许我们可以提出一些解决方案，达到我们的预期。
回顾一下我们的应用部署情况：节点上的容器一般分属多种应用，这些应用本身不一定，也一般不会同时处于访问的高峰。对于混合部署应用的宿主机，如果能都错峰分配上面运行容器的资源或许更科学。
应用的资源需求可能就像月亮一样有阴晴圆缺，有周期变化。例如在线业务，尤其是交易业务，它们在资源使用上呈现一定的周期性，例如：在凌晨、上午时，它的使用量并不是很高，而在午间、下午时会比较高。
打个比方：对于 A 应用的重要时刻，对于 B 应用可能不那么重要，适当打压 B 应用，腾挪出资源给 A 应用，这是个不错的选择。这听起来有点像是分时复用的感觉。但是如果我们按照流量峰值时的需求配置资源就会产生大量的浪费。
除了对于实时性要求很高的在线应用外，我们还有离线应用和实时计算应用等：离线计算对于 CPU 、Memory 或网络资源的使用以及时间不那么敏感，所以在任何时间段它都可以运行；实时计算，可能对于时间敏感性就会很高。
早期，我们业务是在不同的节点按照应用的类型独立进行部署。从上面这张图来看，如果它们进行分时复用资源，针对实时性这个需求层面，我们会发现它实际的最大使用量不是 2+2+1=5，而是某一时刻重要紧急应用需求量的最大值，也就是 3 。如果我们能够数据监测到每个应用的真实使用量，给它分配合理值，那么就能产生资源利用率提升的实际效果。
对于电商应用，对于采用了重量级 Java 框架和相关技术栈的 Web 应用，短时间内 HPA 或者 VPA 都不是件容易的事情。
先说 HPA，我们或许可以秒级拉起了 Pod，创建新的容器，然而拉起的容器是否真的可用呢。从创建到可用，可能需要比较久的时间，对于大促和抢购秒杀-这种访问量“洪峰”可能仅维持几分钟或者十几分钟的实际场景，如果我们等到 HPA 的副本全部可用，可能市场活动早已经结束了。
至于社区目前的 VPA 场景，删掉旧 Pod，创建新 Pod，这样的逻辑更难接受。所以综合考虑，我们需要一个更实际的解决方案弥补 HPA 和 VPA 的在这一单机资源调度的空缺。
我们首先要对解决方案设定一个可以交付的标准那就是—— “既要稳定性，也要利用率，还要自动化实施，当然如果能够智能化那就更好”，然后再交付标准进行细化：
上图是我们最初的工具流程设计：当一个应用面临很高的业务访问需求时，体现在 CPU、Memory 或其他资源类型需求量变大，我们根据 Data Collector 采集的实时基础数据，利用 Data Aggregator 生成某个容器或整个应用的画像，再将画像反馈给 Policy engine。 Policy engine 会瞬时快速修改容器 Cgroup 文件目录下的的参数。
我们最早的架构和我们的想法一样朴实，在 kubelet 进行了侵入式的修改。虽然我们只是加了几个接口，但是这种方式确实不够优雅。每次 kubenrnetes 升级，对于 Policy engine 相关组件升级也有一定的挑战。
为了做到快速迭代并和 Kubelet 解耦，我们对于实现方式进行了新的演进。那就是将关键应用容器化。这样可以达到以下功效：
当然在后续演进中，我们也在尝试和 HPA，VPA 进行打通，毕竟这些和 Policy engine 存在着互补的关系。因此我们架构进一步演进成如下情形。当 Policy engine 在处理一些更多复杂场景搞到无力时，上报事件让中心端做出更全局的决策。水平扩容或是垂直增加资源。
下面我们具体讨论一下 Policy engine 的设计。Policy engine 是单机节点上进行智能调度并执行 Pod 资源调整的核心组件。它主要包括 api server，指挥中心 command center 和执行层 executor。
指挥中心定期从 data aggregator 获取容器的实时画像，包括聚合的统计数据和预测数据，首先判断节点状态，例如节点磁盘异常，或者网络不通，表示该节点已经发生异常，需要保护现场，不再对Pod进行资源调整，以免造成系统震荡，影响运维和调试。如果节点状态正常，指挥中心会策略规则，对容器数据进行再次过滤。比如容器 CPU 率飙高，或者容器的响应时间超过安全阈值。如果条件满足，则对满足条件的容器集合给出资源调整建议，传递给executor。
在架构设计上，我们遵循了以下原则：
插件化：所有的规则和策略被设计为可以通过配置文件来修改，尽量与核心控制流程的代码解耦，与 data collector 和 data aggregator 等其他组件的更新和发布解耦，提升可扩展性；
稳定，这包括以下几个方面：
自愈：资源调整等动作的执行可能会产生一些异常，我们在每个控制器内都加入了自愈回滚机制，保证整个系统的稳定性；
在资源调整方面，Cgroup 支持我们对各个容器的 CPU、内存、网络和磁盘 IO 带宽资源进行隔离和限制，目前我们主要对容器的 CPU 资源进行调整，同时在测试中探索在时分复用的场景下动态调整 memory limit 和 swap usage 而避免 OOM 的可行性；在未来我们将支持对容器的网络和磁盘 IO 的动态调整。
上图展示了我们在测试集群得到的一些实验结果。我们把高优先级的在线应用和低优先级的离线应用混合部署在测试集群里。SLO 是 250ms，我们希望在线应用的 latency 的 95 百分位值低于阈值 250ms。
在实验结果中可以看到：
这说明了我们的控制策略的有效性。
下面我们总结一下在整个项目的进行过程中，我们收获的一些经验和教训，希望这些经验教训能够对遇到类似问题和场景的人有所帮助。
总结起来，我们的工作主要实现了以下几方面的收益：
展望未来，我们希望在以下几个方面加强和扩展我们的工作：
Q1：直接修改 cgroup 容器一定会获得资源吗？
A1：容器技术隔离的技术基础就是 cgroup 层面。在宿主机腾出足够资源的情况下，给 cgroup 设置更大的值可以获取更多的资源。同理，对于一般优先级不高的应用，设置较低的 cgroup 资源值就会达到抑制容器运行的效果。
Q2：底层是如何区分在线和离线优先级的？
A2：底层是无法自动获取谁是在线，谁是离线，或者谁的优先级高，谁的优先级低的。这个我们可以通过各种 Kubernetes 提供的扩展实现。最简单的是通过 label，Annotation 标识。当然通过扩展 QoS class 也是一种思路。社区版本的 QoS class设置太过于保守，给予用户发挥的空间不大。我们通过这些方面也进行了增强。在合适的时候或许会推向社区。自动感知是个方向，感知谁是干扰源，感知谁是某种资源型应用，这块我们还在研发中。做到真正的动态，肯定是具备自动感知的智能系统。
Q3：“与社区版 Vertical-Pod-Autoscaler 不同，Policy engine 不主动驱逐腾挪容器，而是直接修改容器的 cgroup 文件”，想问一下，不主动驱逐的话，如果 Node 的资源达到上线了会怎么处理？
A3：这是一个好问题。首先这里要先区分是哪种资源，如果是 CPU 型的，我们可以调整低优先级容器的 cgroup 下 cpu quota 的值，首先抑制低优先级的容器对于 CPU 的争抢。然后再适当上调高优先级容器的相关资源值。如果是内存型资源，这个不能直接去缩小低优先级容器的 cgroup 值，否则会造成 OOM，对于学习内存型资源的调整，我们会在其他分享中继续讨论。这个技术比较特殊。
Q4：只修改 cgroup，怎么保证 K8s 对单个物理机能够分配更多的容器？
A4：文字直播有了一定说明，容器的资源消耗并非是一成不变的，很多时候它们的资源消耗呈现潮汐现象，相同的资源条件下部署更多应用，完成更多作业就是达到资源利用的最大化的效果。资源出现超卖才是我们这个主题讨论的最大价值。
Q5：也就是说，低优先级的容器，request 设置的比 limit 小很多，然后你们再动态的调整 cgroup？
A5：在现有 QoS 场景下，你可以理解被调整的 Pod 都是 burstable 的。但是我们并不是直接调整 Pod 元数据的 limit 的值，而是调整 limit 在 cgroup 反映的值，这个值在资源竞争缓和的时候还会被调整回去的。我们并不建议单机的 cgroup 数据和 etcd 的中心数据割裂太久。如果长期偏离，我们会像 VPA 发出警报，联动 VPA 做调整。当然在容器运行的高峰期，任何重建容器的操作都是不明智的。
Q6：整体的理解就是你们开始就让物理机超配了一定比例的 pod，然后通过策略动态调整容器的 cgroup 值？
A6：如果资源完全是富足冗余的，这个动态调整也有一定意义。就是并非资源用满场景下，高优先级应用会被干扰，实际上，当主机的 CPU 达到一定比例，打个比方例如 50%，应用的时延就变大。为了完全确保高优先级应用的 SLO，牺牲低优先级的 CPU 正常运行也是有价值的。
Q7:Policy engine 有没有考虑开源？
A7：有计划进行开源，Policy engine 更多的是和自身的应用属性相关，电商应用或者大数据处理应用的策略都是不相同的，我们开源会首先开源框架和附带一些简单的策略，更多的策略可以用户自定义。
Q8：我之前遇到的大部分应用都无法正确感知 cgroup 的配置，因此很多情况都需要在启动参数里面根据 cpu 或者 mem 设置参数，那么也就是说即使改变了 cgroup 对于他们来说都无效，那么使用场景也就有限了
A8：限制容器的资源使用这个还是有价值的。限制低优先级应用本身也可以提升高优先级应用的 SLO，虽然效果没有那么明显。稳定性的考量同样也很重要。
Q9:Policy engine 目前在阿里的使用如何？在生产上有多上的规模使用这种方式进行动态调整？是否和社区的 HPA VPA 配合使用？
A9: Policy engine 在阿里某些集群已经使用。至于规模暂时无法透漏。涉及到很多组件之间的联动，社区的 HPA 和 VPA 目前都不太能满足我们的需求。因此阿里的 HPA 和 VPA 都是我们自行开发的，但是和社区的原理是一致的。阿里 HPA 的开源可以关注 Openkruise 社区。VPA 开源计划我这里还没有确切消息。
Q10：当单机节点资源不足以提供容器扩容时，目前是否可以进行 HPA 或 VPA 扩容呢？
A10：单机节点不足的时候，应用可以通过 HPA 进行增加副本应对。但是 VPA 如果选择原节点进行更新的话，是失败的。只能调度到其他资源丰富的节点。在流量陡升的场景下，重建容器未必能满足需求，很可能导致雪崩，即重建过程中，整个应用其他未升级的副本接受更多流量，OOM 掉，新启动的容器再瞬间被 OOM，所以重启容器需要慎重。快速扩容（HPA）或者快速提升高优先级资源，抑制低优先级容器资源的方式效果更明显。
关注『阿里巴巴云原生』公众号，回复关键词“1010”，可获取本文 PPT。
“ 阿里巴巴云原生微信公众号（ID：Alicloudnative）关注微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术公众号。”
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。