背景

近期公司开始做成本治理, 降本增效. 通过观察以往各业务线的资源规格配置, 不难发现存在大量服务资源超配情况. 即服务实际资源开销远小于其声明的资源开销. 而这部分的资源超配直接导致了集群的资源使用率较低. 通常形如下图

背景 最近看一些社区 issue 中正好接触到 containerd 源码, 早年大家基本都使用 docker/podman 这类容器上层包装, 包括我也是, 故对真正容器运行时的结构部分了解得不够深入, 最近 k8s 社区在 1.21 规划上计划从 kubelet 中移除 docker-shim 交互的逻辑, 大势上组件走上 containerd-shim, 故需要着手对容器运行时更深入了解. 带着问题作为引入, 容器底层还是对 Linux LXC 的交互, 那究竟 docker daemon 中是哪个组件来完成这一步的呢？ 1、背景知识 首先我们需要了解 Docker Daemon 生产出容器的过程. 当前整个 Docker 调用链架构可以用下图来简单概括 从 Docker 1.11 之后，Docker Daemon 被分成了多个模块以适应 OCI 标准。拆分之后，结构分成了以下几个部分： 16年12月 Docker公司宣布将 containerd 从Docker Engine中分离，并捐赠到开源社区独立发展和运营。 一个工业标准的容器运行时，注重简单、 健壮性、可移植性 Docker本身其实已经被剥离干净了，只剩下 Docker 自身作为 cli 的一些特色功能了，真正容器的管控都在 containerd 里实现。 在 17 年 docker重命名为moby, 从命名上逐渐脱离和 container 的关系, 而 Moby 更像是一个“乐高积木”，它包含了容器化的组件库 底层的构建、日志处理、卷管理、网络、镜像管理、containerd、SwarmKit等模块, 是个大杂烩.

Scuba: Diving into Data at Facebook 原文链接: https://www.semanticscholar.org/paper/Scuba%3A-Diving-into-Data-at-Facebook-Abraham-Allen/0bce0735ef3ea01e02b73c98338727d519a71be4 概要 Facebook很重视性能监控。一些性能问题可能会影响超过10亿用户，所以我们跟踪了成千上万的服务器，每天上百PB的网络流量，每天上百个代码变更，以及许多其他指标。我们对时延性的要求是，在事件发生后的一分钟内，如一个客户电话请求，一个提交了bug报告，一份新的代码变更, 能及时更新到图表，并在监控系统中展示出来。 Scuba 是Facebook的数据管理系统，用于大部分的实时分析。Scuba 是一个快速的、可扩展的、分布式的、内存式的 Facebook 自研数据库。它目前吞吐率为每秒数百万行(事件)流入，并以同样的速度过期数据进行流出。Scuba 存储后端在数百台服务器上，每台服务器上的数据完全在内存中，每台服务器内存规格为 144 GB RAM。为了处理每个查询，Scuba 会从所有的数据中聚合服务器以处理每天处理近百万次查询。 在 Facebook, Scuba 广泛应用于交互式、临时性的分析查询，这些查询运行在在一秒内完成对实时数据的处理。 1. 介绍 在Facebook，无论是诊断性能回归还是衡量基础设施变化带来的影响，我们都希望用有效数据来衡量。Facebook基础设施团队依靠的是在实时数据监控以确保网站始终运行顺利。我们的需求包括能在非常短的延迟（通常在一分钟以内）从运行Facebook的网络服务器上查询到发生的事件。查询数据的灵活性和速度对于诊断出问题根因带来不少收益。识别问题的根本原因往往是由于各子系统之间复杂的依赖关系，很难在短时间内完成。然而，一旦出现了没有在几分钟或几小时未解决的问题。那 Facebook 的10亿用户就会变得不快乐，从而对 Facebook 整体发展不利。 为了解决上述问题， 起初，我们依靠的是预先汇总的图表和一套精心管理、手工编码的脚本，通过MySQL数据库的形式管理数据。到了2011年，这个解决方案变得过于僵化和缓慢。它无法跟上不断增长的数据吞吐率和查询效率。而 Facebook内部的其他查询系统，比如Hive[20]和Peregrine[13]，在数据被提供给查询之前，查询数据被写入HDFS，有很长的（典型的一天）延迟，而查询本身需要几分钟的时间来运行。 因此，我们建立了 Scuba，一个快速、可扩展、内存数据库。Scuba 是我们收集和分析来自各种系统的数据的方式的一个重大演变，正是这些系统保证了网站每天的正常运行。我们现在使用 Scuba 能对大多数实时的、结构化的人工数据进行分析。我们将在本文后面将 Scuba 与其他数据管理系统进行比较，但据我们了解，没有任何其他系统能像 Scuba 一样快速地吞吐数据并进行复杂的查询。 如今，Scuba 运行在数百台服务器上，每台服务器有144 GB内存，在一个无共享架构的集群中。它在内存中为1000多个表存储了大约70TB的压缩数据，通过在所有服务器上随机分配每个表来分配内存。Scuba 每秒可处理数百万行。由于 Scuba 是内存绑定的，它能以同样的速度过期掉老数据。为了限制数据量，Scuba 允许行指定一个可选的采样率，这表明 Scuba 只包含原始事件的一小部分（通常是100分之一到100万分之一）。这种采样对于像 Facebook 客户端请求这样每秒发生数百万次的事件是十分必要的。采样可以是统一的，也可以是基于一些关键数据，比如用户ID等。Scuba在计算汇总时，会对采样率进行聚合补偿。 除了提供一个 SQL 查询接口（对于一个 SQL 子集，包括分组和聚合，但不包括连接表），Scuba 提供了一个 GUI，可以生成时间序列图、饼图、列值分布，以及除文本选项之外的其他十几种数据的可视化。图1显示了一个时间序列图，在Scuba GUI中对页面流量进行了一周的比较。在后台，一个聚合树将每个查询分发到每个服务器，然后收集结果发回客户端。 虽然 Scuba 是为了支持性能分析而建立的，但它很快就成为了在其他时间敏感数据上执行探索性查询的首选系统。Facebook的许多团队都在使用Scuba。 移动开发团队使用 Scuba 来跟踪哪些用户在运行不同的移动设备、操作系统和Facebook应用的版本。 广告开发团队利用 Scuba 来监控人们对广告的印象、点击和收入的变化。当出现下降时，他们可以迅速将其缩小到特定的国家、广告类型或服务器集群，并确定根本问题。 SRE 团队过使用 Scuba观察服务器错误。当发生峰值时，他们可以精确地指出是否是由于特定端点中的错误、特定数据中心或服务器集群中的服务，或数据中心的部分物理问题。 错误报告监测每小时运行数千次查询，以寻找Facebook用户报告的错误数量高峰，按几十个人口统计维度（位置、年龄、好友数等）进行分组。 总的来说，用户会先提出高级别的汇总查询，以识别数据中的有趣现象，然后再深入挖掘（因此被称为Scuba），以找到感兴趣的基础数据点。在上述所有情况下，能够沿着多个维度对数据进行临时分解是至关重要的。

难得出太阳的一天。 北京的天总是阴沉沉的，有时候好像是要开启一场庭审，让我紧张得四肢发麻。 二月的第一天，终于有了一些不同。 敞亮的日光，透过大片鲜绿的树叶凶猛地穿透进来。 一抬头，世界在光明刺眼的色调里猛涨。 浑身暖洋洋。 天上的云彩白的好像一个个凸出来的拳头。 我希望它们沉下来，重重砸在我脸上。 将我击碎打散， 那下午便也不用上班。 我给自己定了个目标，这一年里，要看够 1750 部电影。 没想一个月过去了，只看到了 1518 部。 要是电影可以投射在云层里，那我便天天都可以看电影了。

「I hate people !」 早上摸鱼时从友邻广播里看到这句话. 广播里讲了个故事，一位很健谈的朋友，一边讨厌人类，一边等个红灯都能跟人聊五块钱的，从椰子鸡到加拿大冰球，什么都聊。 如此言行不一致, 遭到了质疑。 朋友解释道，people in general 才是让他厌烦之处。When it gets personal, 那世界就变得有趣起来。 我开始反思。 是啊, people 是个非常 general 的概念, 是无具象的. 但当讨论到 person. 那这个人开始有了名字，有了声调. 这个人从"people"的群体里脱离出来，变得具象起来。 every single person 各有各自值得喜欢的地方。 只要一想到一个人类，无论他或她在哪里，在做什么想什么，都在发出悠长的呼吸; 睡梦时眼皮微微滑动，在做梦 睡醒时眼皮被太阳直登登地打亮 这样鲜活的人，多浪漫呀. 哪儿会有人不喜欢具象的人呢。 反观下来，自己似乎常常追逐一些抽象的事物。 越是虚妄，越着迷。 像是对超级英雄有着的不切实际的幻想, 渴望超能力的降临. 而抽离回生活中，却只能靠具象之物来校正这份抽象，而无法放弃抽象本身。 即使那些肌肤相亲的实景实物让人感到愉悦，但也会怀疑是否是自己赋予了某种抽象的意义. 王小波说，人是轻易不能知道自己的。 因为我们的感官是向外的，能察觉到他人细微的变化。但对于自己却不十分了然。 我不太信。 我爱游离在幻想与现实的边界。 有时，我想我爱自己多过爱他人。 我希望我的自我永远滋滋作响，翻腾不休，就像火炭上的一滴糖。 只是转念一想， 椰子鸡也好吃，加拿大冰球，也挺酷。 还有铲冰激凌，炸得焦脆的牛奶块。 打开冰箱门满满的饮料。 冬天里猫咪柔软的肚子，以及情人温软的胸膛。 美好得令人惭愧。 你说，从今天起, 我也要开始学习爱人，爱他人，爱具象的人。 像王小波一样, 像友邻的朋友一样， I hate people, But I love person.

摘要 原文链接：https://dl.acm.org/doi/pdf/10.1145/3342195.3387524 在许多公共和私有云系统中，用户需要指定资源量（CPU内核和RAM）的限制以为其工作负荷提供资源。 超出其限制的作业可能会受到限制或终止，从而导致最终用户请求的延迟或丢弃，因此人工操作人员针对这种问题出于谨慎考虑，会申请高于任务自身需要的配置。 从规模上讲，这将导致大量的资源浪费。 为了解决这个问题，Google使用Autopilot自动配置资源，同时调整作业中的并发任务数（水平缩放）和单个任务的CPU /内存限制（垂直缩放）。 Autopilot与人工操作员遵循相同的原则：Autopilot的主要目标是减少松弛（slack）（申请资源和实际资源使用之间的差异），同时最大程度地降低因内存不足（OOM）错误或 由于CPU节流，其性能下降。 Autopilot将机器学习算法应用到有关作业先前执行情况的历史数据上，再加上一组经过微调的启发式方法来实现这一目标。 在实践中，Autopilot工作只有23％的松弛（slack），而手动管理工作只有46％的松弛（slack）。 此外，Autopilot将受OOM严重影响的工作数量减少了10倍。 尽管有其优点，要确保Autopilot被广泛采用仍需付出巨大的努力，包括使尚未加入的客户容易看到潜在的建议，自动迁移某些类别的任务以及增加对自定义推荐器的支持。 在撰写本文时，Autopilot任务占Google资源使用的48％以上。 ACM参考格式： Krzysztof Rzadca，Pawel Findeisen，Jacek Swiderski，Przemyslaw Zych，Przemyslaw Broniek，Jarek Kusmierek，Pawel Nowak，Beata Strack，Piotr Witusowski，Steven Hand和John Wilkes。 2020年。 Autopilot：Google的工作负载自动缩放。 在第十五欧洲2020年4月27日至30日，计算机系统会议（EuroSys'20），希腊伊拉克利翁。 ACM，美国纽约，纽约，共16页。 https://doi. org/10.1145/3342195.3387524 1 介绍 许多类型的公共云和私有云系统要求其用户声明在执行期间其工作负载将需要多少个实例以及每个实例所需的资源：在公共云平台中，用户需要选择他们需要租用虚拟机（VM）的类型和数量； 在Kubernetes集群中，用户可以设置Pod副本的数量和单个Pod的资源限制; 在Google中，我们要求用户指定所需的容器数量以及每个容器的资源限制。 这些限制使云基础架构能够提供足够的性能隔离，从而使云计算成为可能。 但是限制（主要是）对用户造成了麻烦。 很难估计一个作业需要多少资源才能最佳运行：CPU功率，内存和同时运行的副本数的正确组合。 负载测试可以帮助找到初始估计值，但是随着资源需求随时间变化，这些建议将过时，因为许多最终用户服务工作具有每日或每周的负载模式，并且随着服务变得越来越流行，流量在更长的时间内发生变化 。 最后，处理给定负载所需的资源会随着基础软件或硬件堆栈的新功能，优化和更新而变化。如果CPU容量不足，超出请求的资源可能会导致性能下降，或者导致任务被杀死 内存不足（OOM）。 都不是好事。 从调研结果看，理性的用户将故意高估其工作所需的资源，从而导致对物理资源的不良利用。 一项分析[26]对在一个Google集群[27]上执行的为期一个月的作业跟踪显示，平均内存利用率为50％； 对阿里巴巴YARN集群的另一项分析[23]显示任务的峰值内存利用率从未超过80％。 针对配置资源的困难，一种常见的模式是采用水平自动缩放器，该缩放器通过监控终端用户流量或平均CPU利用率的变化添加或删除副本来缩放任务。 所有主要的云提供商（AWS，Azure和GCP）都提供水平自动扩展功能； 它在某些云中间件（如Kubernetes）中也可用。 较不常见的模式是使用垂直自动缩放来调整每个副本可用的资源量。 两种技术也可以组合。 Autopilot是Google在其内部云上使用的主要自动缩放器。 它提供水平和垂直自动缩放。 本文重点介绍Autopilot的内存垂直扩展，因为这种情况鲜为人知。 论文： 描述下Autopilot，以及它用于垂直自动缩放的两个主要算法：第一个算法依赖于历史用量的指数平滑滑动窗口； 另一个是基于从强化学习中借用的思想的元学习，该算法运行滑动窗口算法的许多变体，并为每个任务选择历史数据表现最佳的算法。（译注：强化学习：依赖海量的训练，并且需要精准的奖励。成本较高且比较复杂。元学习：具备自学能力，能够充分利用过去的经验来指导未来的任务。被认为是实现通用人工智能的关键。） 通过Google的工作负载采样评估Autopilot算法的有效性； 讨论为使我们的集群广泛采用Autopilot而采取的步骤。 2 通过Borg管理云资源 Autopilot的目标和制约因素来自Google的Borg基础架构，并且针对Google的工作负载进行了调整。 我们在此处提供了两者的简要概述：有关Borg的更多详细信息，请参见[34]，有关工作负载的更多详细信息，请参见[26、27、31、35]。