开发者学堂课程【5分钟玩转阿里云容器服务：进阶课程：在 ACK 中如何使用容器优化的操作系统】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1038/detail/15869
在 ACK 中如何使用容器优化的操作系统
内容介绍
一、在 ACK 中如何使用容器优化的操作系统
一、在 ACK 中如何使用容器优化的操作系统
我们提供了资源隔离能力，可以让每个 ACK 对各种各样的 CPU 的调度，资源的控制能够达到更好的精确性。我们提供了 eppf 的优化能力，然后让 E 让 ACK 能够就是有一个车位 IPV line 的一个网络优化的方案，更好地让给用户提供一个网络的能力。然后我们提开箱即用的安全的配置。
让 ACK 可以 ACK 的用户能够开箱即用的享受到等。也可以享受到我们的整个的那个等保的加固的安全要求。然后因各种各样子的这些网络资源，就 CPU 内各种各样子的优化后，让用户可以在全场景下面各种各样子的优化的能力，能够达到很好的各种各样的性能。当然了这部分的能力肯定也是跟需要 ACK 来做很多的改造，或者是 ACK 的管控侧有很大的就是配置配套才能做到这些事情。所以这个地方涉及到我们和 ACK 的一个联动，底层提供一些基础的机制和功能。然后 ACK 提供它业务场景、容器场景下面的各种调度的能力，然后资源的划分的能力，然后用户的入驻场的能力等等，可以享受到最新的这种操作创新功能的一些知识。
我们在 C group V1 的时代，我们将很多现在当前我们主流场景可能还都在使用的是超级广告c5v1。但是实际上 c5 和 V2 已经在已经很多了。然后这部分 V2 上面有些高级的能力，我们也已经把它包到 E1 上面，可以让 V1 的用户场景使用更好的一个这个 VR 的能力。然后现在 VR 可能正在慢慢地成为一个主流，所以我们现在又会将 V1 里面开发的很多资源都已经慢慢地挪到 V2 上，让 V2 的用户也能够享受到 V1 里面所提供的一些能力。
其实这个就是需要操作系统和 ACK 一起来配合完成这样子的一个功能的支持，然后高效的运维。因为我们将整个的这些工具监控，然后为运维的增强都已经集成到了操作系统，然后 ACK 也能感知到这部分的能力。然后所以在 ACK 的脱稿或者履约维的场景，特别是像 service 这样场景，可以直接在 ACK 里面能够产出非常好的一些稳定性年月尾的能力。
当然了，在就是像有一些 worker 节点没有做到托管的，我们也提供了一个像 ACK 里面有一个运控制台，里面有很多的运维的能力，包括媒介诊断、档期检测这样子的也可以在 ACK 的控制台里面可以看到最后一个就是整个的联动是用来做超系统和 ACK 的一个质量保障的。
操作我们发布的时候会经过和 ACK 共同的 CICD 的流程，然后来共同报占这块的质量的发布。能够在整个的发布的过程当中，可以及时地发现整个业务就操作变动或者说 ACK 变动带来的一些联动的问题，这样子的话就是可以保证操作系统在云上在 ACK 画布的时候保障一个最好的。这块这一页可能是对一个前面的这些能力增强的一个总结。当然了一些生命周期的情况在这个里面看不到，我们会在整个的容器场景里会有一个联合的有一些生命周期和服务的一些规划。还有这个可能对用户来说都已经屏蔽掉了。用户只需要说我在操作创建 ACK 的时候使用的 ECS 和超系统是就是和超系统搭配是 I want to mix 那么就可以还想集中地享受到这一块所有的阿里云 Linux 和 ACK 所共同建设的这块的能力。
说了这些就是不管是优化还是增强的能力，我也具体介绍一些具体实践。就是第一个弹性扩容的案例，就是我们前面提到的我们的启动启动优化。启动优化的实践就是对应的是这个我们在国内最大的一个关系型社交的平台，他们在其实每次遇到一些头热点事件，头条事件的时候，整个的因为对于对他们来说，可能如果资源平时就是假设只能应对 1 万的 QPS 的流量，突然来了 10 万的，那必然这个时候你再进行一个弹性伸缩，可能就会非常非常的就是要求很高，你要快速地能够弹性很多的机器过来，这样子的话才能够保障我能够应对这个峰值的流量，否则的话可能就会影响到他的业务的档案或者用户的各种各样的体现体验所以用户就选择了 ACK 加艾拉克 sq 度的那个极速启动竞价的这样的方案，或者帮用户提供一个单实例 10 秒钟左右的一个启动时启动场景。 500 实例可能是只需要 20 秒钟极速启动。
在整个的用户在时间的场景下面，对于它的排泄速度接近提升到了三倍，提升了三倍。然后并且在切换到我们的阿里云操作系统之后，也可以为用户提供一个官方的操作系统的服务的支持。那用户对于在使用的过程当中遇到了任何的问题都可以。就之前以前可能这个还是更多的是来源于服务的支持，是使用社区或者谷歌搜索，或者是看华为大盘这样子的话。现在就能走工单或者直接联系到我们这边来做，是一个弹性的案例这个是一个全场景的，这个用户的使用场景非常复杂，它不仅在 ECS 在一些 worker 节点的 CPU 审核，在 worker 节点的 gq 审核，甚至还有像 ingress 还有它的 Redis 的一些 OPT 的本地盘，还有各种各样的 SOP 等等。。基本上是全场景都在使用，都使用了一些 ACK 或者我们的阿里巴巴 comics 它是一个它的场景，它的背景是这样子的，就是国内最大的在线教育的平台。然后在上云的过中，他使用了就是对于因为都是涉及到一些在线教育的直播。那用户对于要求是非常高的，你不要给我有延迟，不要宕机，否则不要让我卡顿。否则的话我可能老师讲述的一个关键点课题点我就没听到了。所以对于提出了他对我们在阿里内部可能提出了一些非常高的要求。
那如我们在规划如何来满足用户的这样的诉求的时候，就向用户推荐了我们的操作，因为对于按理来说，我们是一定可以保障我自己的操作做得最好的。因为如果我们的做方法可能重大节可能无法满足。所以在使用在用户在切换的整个过程当中，我们给用户做了系统调优，问题就是问题的一些闭环的知识超级的差异化的能力。用户也提到了就是资源隔离这块的一些诉求我们把这块能力给他推荐之后，用户也是非常的满意的。在整个的过程当中，现在用户也已经上线了上万的节点处，整个规模还是非常非常的大的。这个是一个全场景知识，下面是一个神龙，其实在这个用户也用到了他的 work 节点，他有 GPU 什么有 CPU 的神规模式很大。这个是一个专门的，我主要是介绍这个特卫的一个 ppland 这个场景，这个是特卫 IP land 这个场景是阿里巴巴 policy 和容器团队一起共建的一个新的网络优化的一个方案。基于 ETF 技术来提升我们的整个的网络的性能，用户在这个场景下面也是能够在一个这是一个快递的4，每年在双 11 的时候也会遇到非常高的一些峰值，并且对于下单的速度，一些延迟反馈的要求是非常高。然后基于以上的性能和成本的要求，他是选择了 ACK 加神龙的这样子的一个方案，能够来尽可能因为神龙可能单独的一台神龙，还是蛮贵的。但是如果说将整个神龙的资源切割开来做容器的节点的话，那用户可能会节省。
所以用户在这个承诺场景下选择 ACK 加阿里巴克 is 来解决它的一个容器的提升性能，然后并且服务支持的问题。因为它对于网络的延迟的要求师的诊断，然后对监控覆盖的要求是非常高的。下个案例是一个等保的案例，就是我刚刚提到的一个安全合规在云上用户。有些用户对于等保的一个就是国家网络安全的一个要求，2.0的一个要求。因为整个的配置等保的配置还是非常复杂的，几十个大项，每个大项里面还有很多的小项，对于那个超系统的这些配置的要求很高，技术门槛也很高，基本上很多的客户可能没有培养这样子的一些底层的技术的人员的投入。
所以在用户这样的诉求的时候，帮助用户构建了这个能保加固的这个开箱即用的镜像，让用户能够在 ACK 场景下面可能直接进行一个简单的选择，就能够构建出这样子的一个镜像，然后让用户来能够在这个场景下面能够最简单的使用我们的这个操作系统。然后这也是我们的一个产品页和一个钉钉的交流的东西材料。
演示一下那个 ACK 看到的阿里云超市是长什么样子。进一下那个 ACK 的控制台。就是用户在各个同学在使用操作系统的时候，在容器服务的这个上面，我们如果在创建一个集群的时候，我现在随便先建一个集群。
在选择完实例之后，大家可以在这个地方去看到一个操作系统的情况，可以有一些选择 2 和 3 两个主体版本。然后如果用户要配置等保，可以简单的只用等。
这是在游戏的一个文档里面做了一个相对来说还是比较详细的一个操作系统跟容器一起共建的一个方案的一个文档，里面比较多的罗列了的一些优势。在我刚刚提到的一些性能的点在这个地方启动的优势。这个因为超系统本身单独来说对于 CS 有个不止百分之这么多，但是因为在超系统的启动仅占整个容器服务启动的一部分，所以可能这里涉及到的是大数据，然后有一些大规格场景的一些性能的提升。 16% 系统调用性能的提升11%，网络上面的优化 7% 到10%，然后还有一些默认的 BBR 算法加解密，然后一些 IO 的调度器就是这样子的。
然后另外还有一个就是跟针对容器场景的一个具体的优化的一些场景，像容器用得非常多的 ipbs 针对 ipbs 大规格场景用户经常遇到的一个问题，就是大规格场景下面的这个因为定时器触发导致的一个毛刺抖动的一个问题，这个是很多用户那甚至还是用户是必然会碰到的。当然这个可能是要 GPU 核数比较大的情况下，然后还有容器滚动升级的情况，在容器滚动升级的时候，五元组没有发生变化，而导致整个那个丢包丢肾包的问题会影响到一秒左右的延时。
那对于一些延时比较敏感的用户也会遇到这样的问题，还有靠 DNS 的优化。然后容器网络的性能优化包括现在有一个比较火的技术，那个安全沙箱的技术就是 Kata Kata 的技术在容器场景下也可以支持 auto scanler 的一个启动延时的一个降低。对它们的整个的容器集群弹性扩容带来的一个友好，资源上的资源的节省和资源的控制等 AI 和大数据场，然后容器显示增强。
还有些其他的我们当前这个是文档还是写的四点幺九，我们现在已经五点1零了，将五点幺零最新的技术，然后也已经融入进去了，还有一些 overlafs 的性能的一个优化，然后还一些 system to name states 上面的一些优化用户，这些像这个里面提到的这些解决的问题或者优化的天然就带着优化项，用户只需要在容器场景下面选择操作系统，然后开箱即能使用，就不需要做任何的配置。
有一个同学提了一个阿里巴克聚合资推荐基于生命周期的考虑，3的生命周期到 2031 年，而 2 的生命周期到 2024 年。2到 3 的在容器场景下，2到 3 的迁移是非常简单的。你可能只需要新建一个节点池，然后把那个老的节点池的流量打到新的节点池上面来，然后再把老的节点池给释放掉。
我们这边在容器节点这个地方有一个文档容器在这个托管节点池里面有个节点，与节点池里面有一个节点管理的 FAQ 里面有一个这样子的一个文档。这个文档可以介绍用户怎么样从同操更换相同的操作。 就是利用可能选 2 也是合适的。因为我们虽然 2 的生命周期只到 2024 年，但是因为容器场景下的迁移非常简单，可能你只需要到例如到 2024 年 430 eh 之前画个一个月或者两个月的时间，就可能将你的应用完全可以迁移到山上来。
操作系统本身是一个相对来说比较底层的技术的，可能很多的用户对于它的体感很弱。
所以我们才将很多的能力在 ACK 下面做到开箱即用，用户其实也不是非常需要感知到超系统具体要做什么，然后要我怎我要怎么改造它。所以更多的点在于用户在使用 ACK 的时候能够直接选择阿里巴巴 chronix 就这些东西全部默带。
