深入解读基础软件云原生面临的挑战 | 龙蜥技术

2022 长沙 · 中国 1024 程序员节已于 10 月 23 - 25 日在长沙、北京等多地圆满举行。本次程序员节以“算力新时代，开源创未来”为活动主题，开设十余场专业主题论坛，覆盖多个技术领域。龙蜥社区云原生 SIG Owner 王强在1024程序员节北京峰会分享《基础软件云原生挑战》演讲，以下是本次演讲内容：

云原生的定义比较多，有 CNCF 的，也有各大云厂商的一些定义，广义的云原生是应运而生的系统架构，生在云上，长在云上，能够充分地利用云计算的基础设施。cncf 里面的定义更多是关注在技术和架构层面，通过容器、微服务、 不可变基础设施、声明式 API，基于云，实现现代应用架构的构建。

经过这些年的发展，可以看到准备或者已经在生产环境使用容器技术的用户数已经达到受访者的 93%，这是一个相当高的比例。同时 2021 年 CNCF 也发布年度调查报告，宣布跨越鸿沟，成为容器编排的事实标准。可以看到云原生的趋势已经势不可挡。

那么云原生给我们带来了哪些变化，对于底层开发同学，这些变化里面蕴含着哪些机会？结合下面的图我们来看看。

传统形态里面，用户是需要完整负责软硬件技术栈，不单需要懂你的程序，你的程序执行的软件环境，还需要懂你机器的硬件环境。这种时候真要做一个应用挑战是比较大的，需要找 OS，还需要管运行应用的物理机器部署到哪里，网络怎么办等等。

到了虚拟化或者 IAAS 场景里面，我们只需要负责程序和软件原型环境，硬件相关的就交给 IAAS 提供方负责。这里面之前物理环境、物理网络这些就不需要再关心，只需要关注好自己的应用和基础 OS 环境。但是 OS 相关人才是很稀缺的，真正需要解决底层问题，或者想充分发挥底层硬件的性能，这块对用户来说门槛很高。IAAS 相关技术已经发展了十多年，整体上也还有不少挑战，不过对上层已经相对比较成熟。

到云原生场景，通过标准化应用运行环境和应用编排系统，用户就只需要关注业务逻辑，这样能够大大节省底层相关开销，提升创新速度。但是用户的简单，意味着平台层的挑战就更大，需要将应用或者函数执行的 runtime、OS、kernel都进行覆盖，当然挑战和机遇并存，也正因为这些挑战，同时也给了基础软件同学更多的机会。

用户界面上移，带给我们哪些挑战和机会？我们可以先整体看看云原生系统的架构。最上层是云原生应用，其中容器场景我们有一层是应用运行环境——容器镜像，函数场景也还好包含语言 runtime。第二层左边是云原生管控，负责应用定义、业务编排、服务框架。右边是我们核心关注的云原生节点系统。里面可以分为云原生节点管控、节点安全、节点运维、云原生运行时，云原生存储，云原生网络，以及底层支撑容器运行的容器优化 OS。最下面的是支撑整体云原生的基础设施服务。接下来我们来看下各个子模块里面的一些具体挑战。

首先来看下最底层的云原生容器 OS。传统的 OS，由于需要考虑复杂的应用运行环境，需要内置大量的服务和驱动，整体 OS 存在体积臃肿的问题。同时由于 OS 用户可以直接修改，没有合适的管理，很容易出现节点 OS 版本零散，进而集群的 OS 环境状态不一致，问题定位和升级困难。另外传统操作系统里面包含有大量容器场景不需要的包和系统服务，容易给云原生带来更大的攻击面。另外云原生场景，根据业务流量，动态的对节点进行扩缩容是常态，可以有效降低业务成本。但是动态扩缩容场景，传统 OS 并没有包含云原生相关组件，导致 OS 扩容后需要逐个下载包，并启动服务，高并发情况下载和启动服务都可能带来稳定性风险，同时也因为这些耗时操作，也会导致节点扩容耗时高，进而影响用户使用。

针对这样系列挑战，社区和云厂商纷纷推出了容器优化 OS，比如阿里云的LifseaOS、AWS 的 BottlerocketOS；红帽的 CoreOS，也足见相关挑战在云原生场景下的共识。

接下来我们再来看看云原生运行时的挑战。

传统 Linux 原生容器直接跑在节点上面，不同业务和租户的容器通过节点进行隔离，由于共享内核且无有效安全隔离，存在较多的安全风险挑战。同时这种隔离存在资源碎片问题，也无法有效的利用不同容器的特征实现整体利用率的提升。针对这些问题，云原生里面又涌现出了运行时。安全容器是比较早出现的，通过结合虚拟化技术和容器技术，有效的避免了容器逃逸带来的风险，保障了节点的安全。但是引入的虚拟化层，又同时带来了比较大的开销，这也是很多人不敢使用安全容器的一个担心。不过有问题其实也就意味着机遇，这些年连续出现了gvisor、firecracker、rund 等相关技术，核心是用来解决安全容器的资源开销挑战问题，可以说通过虚拟化技术和容器结合，开辟了一个新的方向，带来了诸多的机会，通过这些年的发展也取得了不错的成果。

针对不同业务和租户混合部署的问题，同时也出现了另一个虚拟机容器，通过 k8s 来管理虚拟机，让用户既能够支持原来 IAAS 层的虚拟机相关资源，同时也能够支持容器。

随着机密计算 TEE 相关硬件技术的发展，机密容器也应运而生，通过机密容器，能够让基础设施无法访问到容器内部的数据，进一步保障了用户的隐私安全。在越来越重视隐私的未来，这块也必将得到更多的应用。但是机密容器当前始终面临的大挑战是性能，加密的内存、加密的存储、加密的网络，都给当前的软件栈带来了比较重的负担，需要软硬件结合发展，才能够最终实现机密容器的普惠发展。

云原生存储是一个比较宽泛的概念，这里我们简单看下里面容器镜像和数据加速方面的。

容器带来了应用打包分发的标准化，但同时也让应用需要额外包含一个运行应用的环境，让应用体积成倍增大。在并发场景，由于不同节点的 pod 启动都需要下载镜像，镜像仓库的带宽往往会成为瓶颈。另外容器镜像单独存储，也使得容器启动依赖于镜像下载，对应一些 serverless 场景镜像下载会严重拖慢容器启动速度。此外，对于存放大量镜像的镜像仓库，里面每个容器都包含有一个运行环境的基础镜像，这部分是有大量的重复数据，如何能够有效的提升存储效率也是一个比较有挑战的工作。

随着学术界研究表明一般容器镜像只有 6% 内容会被实际使用，直接牵动了整个容器镜像的大量优化工作，比如容器镜像的按需加载，比如 P2P。各大云厂商为了解决容器镜像加载问题，也是各显神通，有将镜像集成到云盘的，有为镜像构建索引文件的，有构建新的镜像存储格式的。但是目前还没有形成一个统一的方案，也没有形成标准，这块后面还有不少路需要走。

存储里面另外一块是数据加速挑战，大数据和 AI 场景云原生应用依赖的数据量往往比较大，但是这些数据里面真实访问的往往只是里面很小一部分，而且会有比较多的热点。是否能够通过小的缓存，实现大存储数据访问的加速，是一个比较有挑战的。另外 AI 场景，由于 GPU 很多数据依赖于存储，由于存储访问速度慢进而拖慢整个 GPU 资源使用效率问题比较常见，如何有效地提升这些数据访问带宽。

这块这几年开源的比较多，比如 Nydus、Dragonfly、fluid、stargz 等，给大家带来了比较多的选择。

看完存储，再来看下云原生网络。

云原生场景，同时随着微服务化和函数化，实例规格也越来越小，同时便捷的扩缩容也对网络弹性提出了较大的挑战。为了避免故障影响面，通常需要将服务分散到不同的物理节点部署，在规模大的情况，路由更新会是一个比较慢的过程，需要数秒甚至到分钟级，对云原生应用快速弹性带来了比较大的制约。同时随着规格的减小，单节点部署的实例规模也会越来越高，这种情况如何支撑单节点的高密网络，也是存在比较大的挑战。另外，随着内核 eBPF 技术的发展，给云原生网络优化也带来了诸多机会，基于eBPF 的 kube-proxy 优化，基于 eBPF 优化ovs，也是有不少的机会点。

最后再来看看云原生安全。中国开源界这几年在快速的发展，而且是越来越正规的发展，安全在开源里面挑战确实很大，因为开源软件本身供应链上面没有很好的保障，大家都可以往里面贡献代码，所以安全这个地方确实是真的很需要大家下功夫的一个点。云原生作为整体底层架构的创新，也同样面临诸多安全挑战。

在供应链安全上，我们可以看到容器镜像安全是个大的挑战，大量公用的容器镜像，并没有直接为其来源进行有效审核和跟踪。配置文件安全也是云原生一大关注点，用户证书的安全保障，节点被攻击后如何有效避免对整个集群的攻击。再就是云原生软件栈安全，软件栈的 cve 维护和更新，软件栈供应链的安全。同时运行时也面临不少安全挑战，之前已经介绍过，这里不再展开。

另外一个就是安全的检测和风险阻断。基于 eBPF 能够实现轻量的安全检查，同时也构建了越来越完善的安全阻断能力，这给传统的安全检测和风险阻断带来了不少机遇。

基于过去的一些经验给大家分享了一些在云原生技术上的挑战，阿里云过去几年在云原生领域成立了袋鼠云原生底层系统相关的组，我们是整个专注在底层系统核心技术上突破。同时，在这个过程中我们也积极的参与上游开源社区，在内部构建自己系统的时候也希望这些技术开源出来让大家共同使用，整体推动国内基础软件在云原生领域得到蓬勃的发展。

当然，我们也成立了龙蜥云原生 SIG，专注在云原生底层系统上的构架，我们希望秉承着开放协作、共迎挑战、共创云原生未来这样一个方式和社区伙伴携手共进。希望大家能够体验我们容器云原生这块的技术，真正把这些技术应用到生产环境，帮助业务获得更低的成本、更高性能、更可靠的安全性。

2022年云栖大会，龙蜥社区特设云原生专场分享，点击这里一键查看详情，本次专场只对外开放 30 个报名名额，报名且现场参会的同学人人一份龙蜥伴手礼！记得文末点击报名~

（点击图片查看详情）

云原生 SIG 地址链接：

https://openanolis.cn/sig/cloud-native

—— 完 ——