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

2次阅读

共计 3919 个字符,预计需要花费 10 分钟才能阅读完成。

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/clo…

—— 完 ——

正文完
 0