开发者学堂课程【5分钟玩转阿里云容器服务：进阶课程：在 ACK 中如何使用容器优化的操作系统】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1038/detail/15869
在 ACK 中如何使用容器优化的操作系统
内容介绍
一、在 ACK 中如何使用容器优化的操作系统
一、在 ACK 中如何使用容器优化的操作系统
首先列出了一个 cncf 的调查的报告，报告里面大概列了一些市场调查的一个情况。用户对于在使用容器场景下面最感觉到就比较难的一些点最大的挑战。
第一点就是复杂性，这个复杂性可能是来自于容器本身，也来自于整个的软件生态，也来自于运维等等多种场景。然后第二个来自于一些容器场景下使用带来的一些习惯上的变更，后续还有一些安全存储、监控等等。本期讲的是操作系统，这里面的内容大概提炼成了跟超系统相关的五个点。
第一个点是复杂度，是在使用容器场景的时候，可能面临因为容器它是部署在一个超系统上的超系统，帮助容器能够屏蔽掉底层的硬件上的差异，还有一些驱动等等非常复杂的一些底层的逻辑，来帮助上层的容器提供一个良好的软件基础。
所以超系统的跟容器配合的一个优势，就是能够让容器在超系统上面使用更加的便利，简单。所以第一个相关的点是超系统相关的点是说超系统使用上的一个复杂度。
第二个提到了一些 storage 然后 networking ， service mesh 等等都可能和性能相关。这个超系统的性能也会关系到容器的一个性能的表现。
第三个点是功能，因为容器正在一个整个的云原生场景正在一个高速发展的过程，对于新功能的开发，还有一些各种各样功能的一个集成的情况，也是非常非常有依赖的。
第四个点是服务支持，因为在整个容器的服务的过程当中，对用户提供的服务的过程当中肯定会遇到各种各样的，不管是问题驱动的，还是说一些咨询相关的，一定是对于服务支持有很大的要求的。 最后一点是可靠性。因为在使用容器场景，虽然说容器可以解决非常多场景的一些对用户的一些运维的复杂度，但是实际上因为容器本身对于软件站的叠加也对可靠性带来了一定的影响。所以将整个容器面临的挑战总跟超系统相关的提炼成了这五个点。然后针对这些容器场景下使用超系统的一些挑战，我们推荐在容器场景下推荐阿里巴巴来帮助用户能解决这样子的一些所面临的一些困难。这里面我们的一些阿里巴巴 cloux 所能解决的问题提升成了这四个点。
第一个点是说开箱即用，就是针对这个上面我们刚刚提到的这个复杂度来解答的。因为超系统在使用在跟容器做结合的过程中，需要帮助容器提供底层的一个软件，基础设施的一个屏蔽。那么对于容器的一些软件的天然的集成配置安全的要求，还有底层硬件的屏蔽，甚至像一些现在的很宏大的一些架构，像 GPU 像阿里云推出的一些神龙这样子的一些非常复杂的一些新的新新型的硬件场景。下面操作系统都需要能够帮助容器底层屏蔽掉。底层的这些逻辑能够让用户在使用容器的时候仅仅需要关心自己的一些容器的所需要关心的自己的业务的点，将这些底层的所复杂的依赖能够完全的屏蔽掉。第一个点体验的是开箱即用。
阿里巴克 loness 为 ACK 提供一个开箱即用的超系统的环境，能够与 ACK 天然的集成支持 ACK 在阿里云上的全场景，不管是说 ECS 还是神龙，像 GPU 计算，甚至是 NPU 甚至底层未来我们的整个的硬件的演进，像 7 代的实例，然后 8 代的实力向未来更多。还有阿里云现在当前推出的一天各种各样的场景，全场景都能够支持。
第二个是说与 ACK 可以联动做开发技术的演进，这在功能性上面，阿里云的操作系统和联合容器服务团队，然后有一个非常好的一个联动的开发，能够让整个操作系统和 ACK 的功能的演进做到一个无缝的演进。是说操作系统所能现在比较火热的一些像技术 ebp flu rain 等等这样的新的技术，在 ACK 场景下可以无缝的能够衔接使用。
第二个点的提炼是说阿里巴巴 coonics 为 ACK 容器的用户能够提供一个高稳定的运行环境，因为这个操作系统在阿里的内部是海量规模打磨的，能够支撑阿里云各种各样的云产品，双 11 的超大规模的一些应用场景。并且有阿里云的有海量的一些云产品做实践的一些背书。同时有阿里云的专业的超市的团队，为用户提供整个的超系统的运维的支持。不仅是说有容器团队为容器的全功能场景提供支持，超系统团队也会为整个超系统和容器的衔接，超系统的本身运维的能力，然后提供支持。
第三个点是高性能，因为我们与 ACK 存在非常多的那个容器场景的联动，包括我们现在所做的超系统的内核编译器、运行库的这些全栈的优化的支持，都可以对于容器的各种场景提升一个比较好的一个性能。阿里云上面使用阿里巴巴 cloudons 可以为用户提供个 10 年的超强的生命周期支持。
并且在整个的服务在用户的使用过程中使天然的接入阿里云的整个的服务体系，用户可以提供通过工单，然后有些客户也有一些服务的支持的群可以来提供来做一些专门的服务的支持。这个是一个容器服务的那个一个产品页的一个图，点进链接，用户可以进去看到如何，在选择超系统的时候选择我们。这边有一个超链接，可以看到容器服务。下面我介绍一下我们的阿里巴巴，首先先介绍一下历史，这操系统来的非常早。
可能很多同学都知道 09 年阿里云是 09 年成立的，其实当时的淘宝的内核团队也就成立了。然后淘宝内核团队成立的时候所做的这个淘宝内核当然在服务主要是服务整个阿里集团，包括淘宝、支付宝等等各种各样子的淘宝的那个阿里的业务。而随着那个云上规模的增大，然后很多很多的云上的用户也对这个服气超系统产生了很多的诉求。 所以阿里云在 2015 年就发布了我们第一个云上的槽，云上的一个夫妻系统，阿里巴巴 cloudis 15.1。
但随着整个的产品的眼镜加上那个用户使用的一些生态的眼镜，我们在 18 年的时候基于构建了自己的 upstream 的内核四点一九，我们内部叫做 cloud kernel 四点一九。然后在 19 年 3 月份的时候，我们发布了我们第二代新一代的那个超系统 aliba colonies too 当前也是在云上服务着非常非常多的客户。到 2020 年开始，这边产生了一个新的变化。
就随着我们超系统在行业在用户使用上面的一些越来越深入人心，其实用户对于超系统有提出了一些新的要求，包括对于混合云这样等等这些场景，阿里云也联合我们的生态伙伴建立了龙溪社区。所以从 20 年开始，我们的阿里巴克 lonnix 就已开始与龙熙社区共同的演进，建设。我们也将我们所在云上共建的这些能力也都贡献到了某些社区。同时基于龙气社区的一个基础设施，想硬件能力向软件的那个兼容性演进。
然后包括未来的整个的自主可控的操作系统的演进，都会基于容器社区来做一个演进。这是一个 ali barloness 的演进。就是说总结来说就是从服务集团内部到服务公共云的用户，再到我们以荣熙为 base 来做操作系统的演进，始终是在做操作系统相关的整个的技术，还有服务我们的客户。
这一页主要介绍一下那个超系统的架构。其实超系统架构很多同学可能都还比较清楚，底层就是我们的语音的基础设施。神龙 ECS 计算存储网络，然后上层的话就是各种各样的业务，包括阿里巴巴的业务，包括阿里云的一些外部的应用。中间这一圈就是我们的超系统。超系统我们可以简单分成三块，第一最底下的这一块就是我们超系统所说的核心层。我们的内核包括当前阿里巴巴 Lark onace 提供了两个内核，4.29和五点一零，我们在那个各种各样的在内存调度管理，然后 rust 等等各方面都有一些自己的技术上的一些竞争力。中间这一层就是基础运行环境，比较熟悉的是像编译器，然后 libc 的库，然后各种运行的 runtime 可能都在这一层。
应用软件我在这边分开成了两类，一类是说使，阿里巴巴做了很多的一些开源的应用，其实在业界也反向比较好，像体验景 dragon fly dragon where 等等这样子的一些基础软件。然后再就是第三方的一个开源的生态，像正常使用的一些 epl 库的来源的一些软件，这个是整体的一个操作系统的一个软件架构。
就是当前整个阿里巴克在阿里云上的一个覆盖的情况，就是我们是会覆盖整个阿里云所有的位置，并且当前的部署的规模肯定是超过百万级的。这个主要是在云上的规模预示着说其实在阿里云上用户的规模，还有使用的场景都是非常丰富和非常多的。
下面讲一下我们的那个超系统的各种当前在容器场景，第一个就是我们在那个阿里云上操心的所提供的一个生命周期的情况。
2 的生命周期到2024，生命周期是到 2031 年，这个生命周期对于很多的用户和应用场景来说都是应该是非常够的。因为 2 已经在维护期了，所以如果有新上的用户。或者是有考虑到做超系统眼镜的用户。我也会建议大家选择这个更长的生命周期的 3 的版本。这个版本当前还处在一个主力的开发阶段。
这个开发阶段就是我们将整个这 10 年周期大概分成这两块，一块是说 5 年的开发周期和 5 年的维护周期。开发周期重点是做什么事情呢？主要做几件事情。
第一件事情是说我们的新功能的开发，因为还在非常活跃的用户的一些新功能的诉求，然后社区的演进，然后一些云产品的眼睛都在做，所以有很多新功能的开发。
第二块是我们的一些新硬件的支持，然后包括新解决方案的发布等等都会集中在这个周期内。而后续的 5 年的维护周期，可能重点就是在做一些安全的修复 bug fix 一些关键特性的开发。可能在这个后面针对这 10 年的开发周期的年前五年的开发和后五年的维护，大家也是一般的在整个软件可能都是这样引进的，就是前面开发后面维护，这个是一个十年的就是生命周期的知识的情况。
第二个是说关于服务的就是你在阿里云在使用阿里巴巴的时候，你可以免费的获取使用修改这个超系统，也可以自己做一些定制。同时你在使用的过程中，在这十年的生命周期里面，你可以使得到软件的更新、功能的支持、问题的修复、安全漏洞等等这些情况。同时在 ACK 使用 ibulonix 所有 ACK 的用户也可以从 ACK 的服务的支持渠道然后传递到阿里云。
我们会提供一个在阿里云上，我们会提供一个免费的服务支持，包括像正常情况下一些 7 乘 24 小时的一些比较严重的问题，都会有专人在阿里云的整个的服务知识体系下面，然后来给用户来提供服务的和支持，这个是服务支持。
第三个就是这两个重要点讲的，一个是生命周期，一个是服务。后面我会重点讲一些特性，或者是对容器场景比较用户感知比较明显的点。
第一个是说因为容器大家非常直观的感觉到平时比较动用的就是一个弹性的场景。对于弹性来说，你的启动的能力力启动的能力是比较重要的。
而所以我们针对容器的这个超系统做了很多的启动的优化，包括我们这个大概列了一个启动的优化的一个流程。可能从就是因为我们是在 ECS 场景下面，从 Q 进来这种虚拟机进来到那个超系统的 bus 的启动，到 boot loader 到内核到系统的 service 到 App 整个的流程到后续的像这个可能是到一些应用，像 shd 等等的这个流程。
我们在每个流程当中都做了非常非常多的优化。甚至在有些流程里面，我们和 ECS 和底层的神龙是有联动的，优化的是为了让整个的启动能够保持到一个最佳的时间。从这个左边的蓝色的是用渗透 S 来做测试的。
我们相比于渗透 S 启动时间至少有个 60% 以上的下降。我们当前最快的速度应该是在 10 秒钟左右，可以在虚拟机上将整个超市都拉起来。当然了拉起来之后，在容器场景可能会加上一些堆叠一些容器的应用的启动，像K8S ，像有一些应用的配置等等，这些都会有这样子的一些启动。然后这个是一个启动的场景的优化。然后下面这个是运行时的这个第一个是弹性的能力。
第二个介绍什么运行时我们整个超系统，因为操作系统的软件库那个软件架构，我前面也有一个简单的图说明了其实针对整个操作系统全软件栈上面阿里云的 Linux 会存在了，都做了很多的优化。从底层内核来说，我们在协议栈、调度器、内存、存储的访问、系统调用等等这方面都有很多的优化。
主要是这些优化大的效果，因为各种各样的数据非常多，我没在这里罗列。然后用户可以那个自己找个环境做一下实测，也可以在我一会会打开一个链接，在那个链接官网上面也有一些部分的数据也可以去参考。
然后编器上面的像 GCC lib C 然后这个是 JDK llvm 都有，不同种类的优化放在里面。基础库，像 opencl opensh Python lib a zip lib 这样子的这些库都是有优化的。
最后是应用程序，可能很多的用户对于这块是比较关心，我也重点讲一下，像 NGINX 这个是在 ACK 场景下面，像 ingress NGINX 这个节点，很多的用户是用的非常非常多的在这个场景下面我们也有很多的优化用户也可以看到。
然后像 MySQL 有很多用户可能是自建数据库的 Redis httbd 这样子的这些应用软件用户都是可以从那个在使用阿里云 Linux 的时候可以开箱即用的享受到这个我们所优化的这些效果。稳定性，对于很多的使用操作系统的，就是涉及到超系统替换或选择的用户一定会关心的，我切换到你这个超级系统之后，我粘性怎么样？只是这张图里面我大概罗列了一些。其实这张图里面我大概罗列了一些我们是怎么打磨我们操作的稳定性的，最底下是整个社区的生态。然后我们因为我们在做操作系统，在做创建创造的时候很多的用户都是渗透 S 或者 red 的用户，所以我们有很多的软件的选型会参考 record 然后来做一些选择。然后所以在 record 上面，我们相当于是在支援的肩膀上做了一些依赖的事情。然后第上面再上面一个点就是我们的阿里云集团的档阿里云。
大家都知道阿里云的阿里集团整个的体量，还有我们的双11，还有我们的阿里云的云产品其实是非常非常丰富，也整个的体量规模非常大的。那这么多的产品在使用和应用，在使用阿里巴巴 chlomix 的时候，肯定会各种各样子的场景都会得到锤炼。所以我们在这种大量的实际业务的实锤炼当中，也将整个产品的稳定性打磨得非常好。
同时最后一个点就是我们在云上的各种各样的客户能够给我们反馈的各种各样的问题，我们也能够在阿里云的整个服务的体系下面，能够将这块的解法或者是方案能够尽快的落地到我们的产品里面，重新回馈到社区或者是超市的镜像里面，让用户能够使用到一个更好的稳定性的镜像。
然后右边我列了一个大图，就像我们是在那个云上有一个大盘的统计，大概是说对于渗透 S 有一个宕机率的下降，至少在 50% 以上。可能很多的用户之前我们也遇到非常非常多用户，因为这个稳定性的问题在 cdos 上可能很难得到解决。
然后从切到阿里 Linux 之后有一个很比较好的效果的体现，这个是一个稳定性相关的在每个资源隔离为什么讲资源隔离因为容器场景大家可能用的非常多的，就是各种用 cgroup 或者 Docker 来管理它的整个的 cgroup 的 name space 所以在整个就是因为是一个各种 Docker 容器场景下面的 name space 的一个管理，所以必不可少的会涉及到我的每个容器资源的隔离性怎么样子？
如果隔离性不好，我这个限制了我的内存，这就是会关系到每个用户他自己的容器的容量规划。本来这个容器只能够承载 1g 的流量。现在因为内存就是突然发现 burst 的一个突然的增发，导致我现在多用了几 G 的内存，导致影响到了旁边的一个容器，这样子的话就会到其他自己的业务的一个稳定性。
所以我们在容器场景下提供了非常多的隔离的能力大家可以看到底片层次的部分，为什么这点第一个填一个监控增强。监控增强原因是因为我们很多因为容器场景下用户虽然使用上方便了，但是实际上对于管理来说是变得更加的复杂了。因为我们容器的像资源上面所需要的就是因为本来我一个 ECS 可能只布一个应用或者两个应用，很简单，但我现在一个 ECS 划分成了多个 Docker 每个 Docker 里面布一个这样子的，它的负载其实更加的复杂了。
我们需要有一更好的监控，能够让用户一眼可以看到我的这每个容器的具体的情况是怎么样，CPU情况内存情况是什么样子，会不会有一些突发的流量的到来，会引起我的一个业务的异常。所以我们第一个就做了 cgroup 的 VE 的增强，提供了不管是网络的还是内存的等等这方面的增强第二个是 memory CG QS 这个是说我们针对内存场景下面的一些 QS 保障，能够尽量的让你的内存在使用的过程中，不会因为其他的一些内存不足导致的一些抖动。
还有一些像 permanagity pvd 这个就是用来保障我们当内存不足的时候又要触发回收了。触发内存回收的时候我们怎么样子不会因为我的回收而影响到其他的容器当然也有这个 say group right back 这个是这个是那个写就是 IO 相关的，还有其他的各种各样的右边是一些优先级控制上面权重的。
像那个内存的优先级 memory CG priority 是用来保障我们内存的各种优先级的，因为 Chinese clean 是用来管理我们的那个调 CPU 调度的，还有 CPU CPU share CPU quota 这个就比较明显，大家可能都会用到在做 ACK yum yum 配置的时候，我们要配置我们的那个 CPU share 或者 CPU quota 还有 memory limit 等等这样子的橙色部分可能重点白色的部分可能是一些社区标准的一些方案当中。
然后橙色这部分可能是阿里云对整个容器资源隔离这块的一个增强，因为这样子的一个增强可以让用户在 ACK 场景下使用容器的时候，它的整体的隔离能力体验会更加的好。这个因为这些启动、运行、稳定性、资源隔离等等这样子的优化，然后才能够带来我们对于这一页的开箱启用。就是我们的容器服务 ACK PRO AST R 这样子的 lackee 这样子的 acracree 就是用容器镜像服务，它的各种各样的场景才能够在超系统上面保证非常好。
