阿里巴巴正式开源其自研容器技术Pouch 已认证的机构

Melvin60O 6年前
   <p>在中国开源年会现场,阿里巴巴正式开源了基于 Apache 2.0 协议的容器技术 Pouch。Pouch 是一款轻量级的容器技术,拥有快速高效、可移植性高、资源占用少等特性,主要帮助阿里更快的做到内部业务的交付,同时提高超大规模下数据中心的物理资源利用率。开源之后,Pouch 成为一项普惠技术,人人都可以在 GitHub 上获取,GitHub 项目地址:</p>    <p><a href="/misc/goto?guid=4959755647565808004" rel="nofollow,noindex">https:// github.com/alibaba/pouc h </a></p>    <p><img alt="阿里巴巴正式开源其自研容器技术Pouch 已认证的机构" src="https://simg.open-open.com/show/1e7bf491906a0662da6c72ac799d6452.jpg"></p>    <p>Pouch 的开源,是阿里看好容器技术的一个信号。时至今日,全球范围内,容器技术在大多数企业中落地,已然成为一种共识。如何做好容器的技术选型,如何让容器技术可控,相信是每一个企业必须考虑的问题。Pouch 无疑使得容器生态再添利器,在全球巨头垄断的容器开源生态中,为中国技术赢得了一块阵地。</p>    <p> </p>    <h2><strong>Pouch 技术现状</strong></h2>    <p>此次开源 Pouch,相信行业中很多专家都会对阿里目前的容器技术感兴趣。到底阿里玩容器是一个侠之大者,还是后起之秀呢?以过去看未来,技术领域尤其如此,技术的沉淀与积累,大致可以看清一家公司的技术实力。</p>    <p> </p>    <p><strong>Pouch 演进</strong></p>    <p>追溯 Pouch 的历史,我们会发现 Pouch 起源于 2011 年。当时,Linux 内核之上的 namespace、cgroup 等技术开始成熟,LXC 等工具也在同时期诞生不久。阿里巴巴作为一家技术公司,即基于 LXC 研发了容器技术 t4,并在当时以产品形态给集团内部提供服务。此举被视为阿里对容器技术的第一次探索,也为阿里的容器技术积淀了最初的经验。随着时间的推移,两年后,Docker 横空出世,其镜像技术层面,极大程度上解决了困扰行业多年的“软件封装”问题。镜像技术流行开来后,阿里没有理由不去融合这个给行业带来巨大价值的技术。于是,在 2015 年,t4 在自身容器技术的基础上,逐渐吸收社区中的 Docker 镜像技术,慢慢演变,打磨为 Pouch。</p>    <p>带有镜像创新的容器技术,似一阵飓风,所到之处,国内外无不叫好,阿里巴巴不外如是。2015 年末始,阿里巴巴集团内部在基础设施层面也在悄然发生变化。原因很多,其中最简单的一条,相信大家也不难理解,阿里巴巴体量的互联网公司,背后必定有巨大的数据中心在支撑,业务的爆炸式增长,必定导致基础设施需求的增长,也就造成基础设施成本的大幅提高。容器的轻量级与资源消耗低,加上镜像的快速分发,迅速让阿里巴巴下定决心,在容器技术领域加大投入,帮助数据中心全面升级。</p>    <p> </p>    <p><strong>阿里容器规模</strong></p>    <p>经过两年多的投入,阿里容器技术 Pouch 已经在集团基础技术中,扮演着极其重要的角色。2017 年双 11,巨额交易 1682 亿背后,Pouch 在“超级工程”中做到了:</p>    <ul>     <li>100% 的在线业务 Pouch 化</li>     <li>容器规模达到百万级</li>    </ul>    <p>回到阿里集团内部,Pouch 的日常服务已经覆盖绝大部分的事业部,覆盖的业务场景包括:电商、广告、搜索等;覆盖技术栈包括:电商应用、数据库、大数据、流计算等;覆盖编程语言:Java、C++、NodeJS 等。</p>    <p> </p>    <p><strong>Pouch 技术优势</strong></p>    <p>阿里巴巴容器技术如此之广的应用范围,对行业来说实属一大幸事,因为阿里已经用事实说明:容器技术已经在大规模生产环境下得到验证。然而,由于 Pouch 源自阿里,而非社区,因此在容器效果、技术实现等方面,两套体系存在差异。换言之,Pouch 存在不少独有的技术优势。</p>    <p> </p>    <p><strong>隔离性强</strong></p>    <p>隔离性是企业走云化之路过程中,无法回避的一个技术难题。隔离性强,意味着技术具备了商用的初步条件;反之则几乎没有可能在业务线上铺开。哪怕是阿里巴巴这样的技术公司,实践容器技术伊始,安全问题都无法幸免。众所周知,行业中的容器方案大多基于 Linux 内核提供的 cgroup 和 namespace 来实现隔离,然后这样的轻量级方案存在弊端:</p>    <ul>     <li>容器间,容器与宿主间,共享同一个内核;</li>     <li>内核实现的隔离资源,维度不足。</li>    </ul>    <p>面对如此的内核现状,阿里巴巴采取了三个方面的工作,来解决容器的安全问题:</p>    <ul>     <li>用户态增强容器的隔离维度,比如网络带宽、磁盘使用量等;</li>     <li>给内核提交 patch,修复容器的资源可见性问题,cgroup 方面的 bug;</li>     <li>实现基于 Hypervisor 的容器,通过创建新内核来实现容器隔离。</li>    </ul>    <p>容器安全的研究,在行业中将会持续相当长时间。而阿里在开源 Pouch 中,将在原有的安全基础上,继续融合 lxcfs 等特性与社区共享。同时阿里巴巴也在计划开源“阿里内核”,将多年来阿里对 Linux 内核的增强回馈行业。</p>    <p> </p>    <p><strong>P2P 镜像分发</strong></p>    <p>随着阿里业务爆炸式增长,以及 2015 年之后容器技术的迅速普及,阿里容器镜像的分发也同时成为亟待解决的问题。虽然,容器镜像已经帮助企业在应用文件复用等方面,相较传统方法做了很多优化,但是在数以万计的集群规模下,分发效率依然令人抓狂。举一个简单例子:如果数据中心中有 10000 台物理节点,每个节点同时向镜像仓库发起镜像下载,镜像仓库所在机器的网络压力,CPU 压力可想而知。</p>    <p>基于以上场景,阿里巴巴镜像分发工具“蜻蜓”应运而生。蜻蜓是基于智能 P2P 技术的通用文件分发系统。解决了大规模文件分发场景下分发耗时、成功率低、带宽浪费等难题。大幅提升发布部署、数据预热、大规模容器镜像分发等业务能力。目前,“蜻蜓”和 Pouch 同时开源,项目地址为:</p>    <p><a href="/misc/goto?guid=4959755647656069615" rel="nofollow,noindex">https://github.com/alibaba/dragonfly</a></p>    <p>Pouch 与蜻蜓的使用架构图如下:</p>    <p><img alt="阿里巴巴正式开源其自研容器技术Pouch 已认证的机构" src="https://simg.open-open.com/show/4b95573134fd8d8aa396096ea320b707.jpg"></p>    <p><strong>富容器技术</strong></p>    <p>阿里巴巴集团内部囊括了各式各样的业务场景,几乎每种场景都对 Pouch 有着自己的要求。如果使用外界“单容器单进程”的方案,在业务部门推行容器化存在令人难以置信的阻力。阿里巴巴内部,基础技术起着巨大的支撑作用,需要每时每刻都更好的支撑业务的运行。当业务运行时,技术几乎很难做到让业务去做改变,反过来适配自己。因此,一种对应用开发、应用运维都没有侵入性的容器技术,才有可能大规模的迅速铺开。否则的话,容器化过程中,一方面得不到业务方的支持,另一方面也需要投入大量人力帮助业务方,非标准化的实现业务运维。</p>    <p>阿里深谙此道,内部的 Pouch 技术可以说对业务没有任何的侵入性,也正是因为这一点在集团内部做到 100% 容器化。这样的容器技术,被无数阿里人称为“富容器”。</p>    <p>“富容器”技术的实现,主要是为了在 Linux 内核上创建一个与虚拟机体验完全一致的容器。如此一来,比一般容器要功能强大,内部有完整的 init 进程,以及业务应用需要的任何服务,当然这也印证了 Pouch 为什么可以做到对应用没有“侵入性”。技术的实现过程中,Pouch 需要将容器的执行入口定义为 systemd,而在内核态,Pouch 引入了 cgroup namespace 这一最新的内核 patch,满足 systemd 在富容器模式的隔离性。从企业运维流程来看,富容器同样优势明显。它可以在应用的 Entrypoint 启动之前做一些事情,比如统一要做一些安全相关的事情,运维相关的 agent 拉起。这些需要统一做的事情,倘若放到用户的启动脚本,或镜像中就对用户的应用诞生了侵入性,而富容器可以透明的处理掉这些事情。</p>    <p> </p>    <p><strong>内核兼容性</strong></p>    <p>容器技术的井喷式发展,使得不少走在技术前沿的企业享受到技术红利。然后,“长尾效应”也注定技术演进存在漫长周期。Pouch 的发展也在规模化进程中遇到相同问题。</p>    <p>但凡规模达到一定量,“摩尔定律”决定了数据中心会存有遗留资源,如何利用与处理这些物理资源,是一个大问题。阿里集团内部也是如此,不管是不同型号的机器,还是从 2.6.32 到 3.10+ 的 Linux 内核,异构现象依然存在。倘若要使所有应用运行 Pouch 之中,Pouch 就必须支持所有内核版本,而现有的容器技术支持的 Linux 内核都在 3.10 以上。不过技术层面万幸的是,对 2.6.32 等老版本内核而言,namespace 的支持仅仅缺失 user namespace;其他 namespace 以及常用的 cgroup 子系统均存在;但是 /proc/self/ns 等用来记录 namespace 的辅助文件当时还不存在,setns 等系统调用也需要在高版本内核中才能支持。而阿里的技术策略是,通过一些其他的方法,来绕过某些系统调用,实现老版本内核的容器支持。</p>    <p>当然,从另一个角度而言,富容器技术也很大程度上,对老版本内核上的其他运维系统、监控系统、用户使用习惯等实现了适配,保障 Pouch 在内核兼容性方面的高可用性。</p>    <p>因此综合来看,在 Pouch 的技术优势之上,我们不难发现适用 Pouch 的应用场景:传统 IT 架构的的迅速容器化,企业大规模业务的部署,安全隔离要求高稳定性要求高的金融场景等。</p>    <p> </p>    <h2><strong>Pouch 架构</strong></h2>    <p>凭借差异化的技术优势,Pouch 在阿里巴巴大规模的应用场景下已经得到很好的验证。然而,不得不说的是:目前阿里巴巴内部的 Pouch 与当前开源版本依然存在一定的差异。</p>    <p>虽然优势明显,但是如果把内部的 Pouch 直接开源,这几乎是一件不可能的事。多年的发展,内部 Pouch 在服务业务的同时,存在与阿里内部基础设施、业务场景耦合的情况。耦合的内容,对于行业来说通用性并不强,同时涉及一些其他问题。因此,Pouch 开源过程中,第一要务即解耦内部依赖,把最核心的、对社区同样有巨大价值的部分开源出来。同时,阿里希望在开源的最开始,即与社区站在一起,共建 Pouch 的开源社区。随后,以开源版本的 Pouch 逐渐替换阿里巴巴集团内部的 Pouch,最终达成 Pouch 内外一致的目标。当然,在这过程中,内部 Pouch 的解耦工作,以及插件化演进工作同样重要。而在 Pouch 的开源计划中,明年 3 月底会是一个重要的时间点,彼时 Pouch 的 1.0 版本将发布。</p>    <p>从计划开源的第一刻开始,Pouch 在生态中的架构图就设计如下:</p>    <p><img alt="阿里巴巴正式开源其自研容器技术Pouch 已认证的机构" src="https://simg.open-open.com/show/1dc2c574c5c180e1f22d9c51fd0a6f76.jpg"></p>    <p>Pouch 的生态架构可以从两个方面来看:第一,如何对接容器编排系统;第二,如何加强容器运行时。</p>    <p>容器编排系统的支持,是 Pouch 开源计划的重要板块。因此,设计之初,Pouch 就希望自身可以原生支持 Kubernetes 等编排系统。为实现这点,Pouch 在行业中率先支持 container 1.0.0。目前行业中的容器方案 containerd 主要停留在 0.2.3 版本,新版本的安全等功能还无法使用,而 Pouch 已经是第一个吃螃蟹的人。当前 Docker 依然是 Kubernetes 体系中较火的容器引擎方案,而 Kubernetes 在 runtime 层面的战略计划为使用 cri-containerd 降低自身与商业产品的耦合度,而走兼容社区方案的道路,比如 cri-containerd 以及 containerd 社区版。另外,需要额外提及的是,内部的 Pouch 是阿里巴巴调度系统 Sigma 的重要组成部分,同时支撑着“混部”工程的实现。Pouch 开源路线中,同样会以支持“混部”为目标。未来,Sigma 的调度(scheduling)以及混部(co-location)能力有望服务行业。</p>    <p>生态方面,Pouch 立足开放;容器运行时方面,Pouch 主张“丰富”与“安全”。runC 的支持,可谓顺其自然。runV 的支持,则表现出了和生态的差异性。虽然 docker 默认支持 runV,然而在 docker 的 API 中并非做到对“容器”与“虚拟机”的兼容,从而 Docker 并非是一个统一的管理入口。而据我们所知,现有企业中仍有众多存量虚拟机的场景,因此,在迎接容器时代时,如何通过统一的运维入口,同时管理容器和虚拟机,势必会是“虚拟机迈向容器”这个变迁过渡期中,企业最为关心的方案之一。Pouch 的开源形态,很好的覆盖了这一场景。runlxc 是阿里巴巴自研的 lxc 容器运行时,Pouch 对其的支持同时也意味着 runlxc 会在不久后开源,覆盖企业内部拥有大量低版本 Linux 内核的场景。</p>    <p>Pouch 对接生态的架构如下,而 Pouch 内部自身的架构可参考下图:</p>    <p><img alt="阿里巴巴正式开源其自研容器技术Pouch 已认证的机构" src="https://simg.open-open.com/show/fd3e7a0ea53cf5cd59d5ac27bca6c5db.jpg"></p>    <p>和传统的容器引擎方案相似,Pouch 也呈现出 C/S 的软件架构。命令行 CLI 层面,可以同时支持 Pouch CLI 以及 Docker CLI。对接容器 runtime,Pouch 内部通过 container client 通过 gRPC 调用 containerd。Pouch Daemon 的内部采取组件化的设计理念,抽离出相应的 System Manager、Container Manager、Image Manager、Network Manager、Volume Manager 提供统一化的对象管理方案。</p>    <h2><strong>写在最后</strong></h2>    <p>如今 Pouch 的开源,意味着阿里积累的容器技术将走出阿里,面向行业。而 Pouch 的技术优势,决定了其自身会以一个差异化的容器解决方案,供用户选择。企业在走云化之路,拥抱云原生(Cloud Native)时,Pouch 致力于成为一款强有力的软件,帮助企业的数字化转型做到最稳定的支持。</p>    <p>来自:<a href="https://zhuanlan.zhihu.com/p/31445882?utm_source=tuicool&utm_medium=referral">https://zhuanlan.zhihu.com/p/31445882</a></p>    <p> </p>