阿里巴巴原生实践15讲

2020-03-01 369浏览

1.
2.微信扫一扫关注阿里巴巴云原生公众号微信扫一扫关注阿里技术公众号阿里云开发者社区开发者一站式平台钉钉扫描二维码，立即加入 K8s 社区大群
3.目录开篇 iv 容器十年—— 一部软件交付编年史 iv 阿里云原生实践 1 坚持探索与落地并重，阿里巴巴云原生之路全景揭秘 1 1-5-10：如何快速恢复大规模容器故障 6 阿里巴巴利用 K8S、Kata 容器和裸金属服务器构建无服务器平台 23 CafeDeployment：为互联网金融关键任务场景扩展的 Kubernetes 资源 35 Serverless 市场观察和落地挑战 45 有效可靠地管理大规模 Kubernetes 集群 51 阿里新技术方案 59 云原生应用 Kubernetes 监控与弹性实践 59 了解 Kubernetes Master 的可扩展性和性能 66 云原生时代加速镜像分发的三种方法 81 在 Web 级集群中动态调整 Pod 资源限制 93 大规模 k8s 集群下的巡检 108 使用 Istio 管理跨地域多集群的服务 122 阿里云开源贡献 135 首个普惠社区的平民化方案：GPU 共享调度 135 容器运行时管理引擎 Containerd 148 基于 P2P 原理的高可用高性能大规模镜像分发系统：Dragonfly 155
4.开篇开篇容器十年—— 一部软件交付编年史阿里云容器平台高级技术专家张磊 2019 年，全世界的开发人员都开始习惯用容器测试自己的软件，用容器做线上发布，开始对容器化的软件构建和交付流程习以为常。全世界的架构师们都在对“云原生”侃侃而谈，描绘多云时代的应用治理方式，不经意间就把“sidecar”这种容器组织方式当做了默认选项。在“云”已经成为了大众基础设施的今天，我们已经习惯了把“容器”当做现代软件基础设施的基本依赖。这就像我们每天打开 Eclipse 编写 Java 代码一样自然。但往回倒数两年，整个容器生态都还在围着 Docker 公司争得不可开交，看起来完全没有定数。当时的国内很多公有云厂商，甚至都没有正式的 Kubernetes 服务。在那个时候，要依托容器技术在云上托管完整的软件生命周期，可以说是相当前沿的探索。谁能想到短短两年之后，容器这个站在巨人肩膀上的设计，就真的成为技术人员日常工作的一部分呢？伴随着容器技术普及到“千家万户”，我们在这两年期间所经历的，是现代软件交付形式的一次重要变革。源起：属于 Jails 们的时代虚拟化容器技术（virtualized container）的历史，其实可以一直追溯上世纪 70 年代末。时间回到 1979 年，贝尔实验室（Bell Laboratories）正在为 Unix V7 （Version 7 Unix）操作系统的发布进行最后的开发和测试工作。
5.开篇 < v Ken Thompson(sitting) and Dennis Ritchie at PDP-11 ©wikipedia 在那个时候，Unix 操作系统还是贝尔实验室的内部项目，而运行 Unix 的机器则是长得像音响一样的、名叫 PDP 系列的巨型盒子。在那个“软件危机（The Software Crisis）”横行的末期，开发和维护 Unix 这样一套操作系统项目，即使对贝尔实验室来说也绝非易事。更何况，那里的程序员们还得一边开发 Unix，一边开发 C 语言本身呢。而在 Unix V7 的开发过程中，系统级别软件构建（Build）和测试（Test）的效率其实是其中一个最为棘手的难题。这里的原因也容易理解：当一个系统软件编译和安装完成后，整个测试环境其实就被“污染”了。如果要进行下一次构建、安装和测试，就必须重新搭建和配置整改测试环境。在有云计算能力的今天，我们或许可以通过虚拟机等方法来完整的复现一个集群。但在那个一块 64K 的内存条要卖 419 美元的年代，“快速销毁和重建基础设施”的想法还是有点“科幻”了。
6.vi > 阿里巴巴云原生实践 15 讲所以，贝尔实验室的聪明脑袋们开始构思一种在现有操作系统环境下“隔离”出一个可供软件进行构建和测试的环境。更确切的说，就是我能否简单的执行一些指令，就改变一个程序的“视图”，让它把当前目录当做自己的根目录呢？这样，我每次只要在当前目录里放置一个完整操作系统文件系统部分，该软件运行所需的所有依赖就完备了。更为重要的是，有了这个能力，开发者实际上就间接拥有了应用基础设施“快速销毁和重现”的能力，而不需要在环境搭好之后进入到环境里去进行应用所需的依赖安装和配置。这当然是因为，现在我的整个软件运行的依赖，是以一个操作系统文件目录的形式事先准备好的，而开发者只需要构建和测试应用的时候，切换应用“眼中”的根目录到这个文件目录即可。于是，一个叫做 chroot（Change Root）的系统调用就此诞生了。顾名思义，chroot 的作用是“重定向进程及其子进程的根目录到一个文件系统上的新位置”，使得该进程再也看不到也没法接触到这个位置上层的“世界”。所以这个被隔离出来的新环境就有一个非常形象的名字，叫做 Chroot Jail。值得一提的是，这款孕育了 chroot 的 Unix V7 操作系统，成为了贝尔实验室 Unix 内部发行版的绝唱。在这一年末尾，Unix 操作系统正式被 AT&T 公司商业化，并被允许授权给外部使用，自此开启了一代经典操作系统的传奇之旅。而 Chroot 的诞生，也第一次为世人打开了“进程隔离”的大门。伴随着这种机制被更广泛的用户接触到，chroot 也逐渐成为了开发测试环境配置和应用依赖管理的一个重要工具。而“Jail”这个用来描述进程被隔离环境的概念，也开始激发出这个技术领域更多的灵感。在 2000 年，同属 Unix 家族的 FreeBSD 操作系统发布了“jail”命令，宣布了 FreeBSD Jails 隔离环境的正式发布。相比于 Chroot Jail，FreeBSD Jails 把” 隔离“这个概念扩展到了进程的完整视图，隔离出了独立进程环境和用户体系，并为 Jails 环境分配了独立的 IP 地址。所以确切的说，尽管 chroot 开创了进程环境隔离的思想，但 FreeBSD Jails，其实才真正实现了进程的沙箱化。而这里的关键在于，这种沙箱的实现，依靠的是操作系统级别的隔离与限制能力而非硬件虚拟化技术。
7.开篇 < vii 不过，无论是 FreeBSD Jails（Unix 平台），还是紧接着出现的 Oracle Solaris Containers（Solaris 平台），都没有能在更广泛的软件开发和交付场景中扮演到更重要的角色。在这段属于 Jails 们的时代，进程沙箱技术因为“云”的概念尚未普及，始终被局限在了小众而有限的世界里。发展：云，与应用容器事实上，在 Jails 大行其道的这几年间，同样在迅速发展的 Linux 阵营上也陆续出现多个类似的沙箱技术比如 Linux VServer 和 Open VZ（未进入内核主干）。但跟 Jails 的发展路径比较类似，这些沙箱技术最后也都沦为了小众功能。我们再次看到了，进程沙箱技术的发展过程中“云”的角色缺失所带来的影响，其实还是非常巨大的。而既然说到“云”，我们就不得不提到基础设施领域的翘楚：Google。 Google 在云计算背后最核心的基础设施领域的强大影响力，是被业界公认的一个事实，无论是当初震惊世界的三大论文，还是像 Borg/Omega 等领先业界多年的内部基础设施项目，都在这个领域扮演者重要的启迪者角色。然而，放眼当今的云计算市场，仅仅比 Google 云计算发布早一年多的 AWS 却是“云”这个产业毫无争议
8.viii > 阿里巴巴云原生实践 15 讲的领导者。而每每谈到这里的原因，大家都会提到一个充满了争议的项目：GAE。 GAE 对于中国的某几代技术人员来说，可以说是一个挥之不去的记忆。然而，即使是这批 GAE 的忠实用户，恐怕也很难理解这个服务竟然就是 Google 当年决定用来对抗 AWS 的核心云产品了。事实上，GAE 本身与其说是 PaaS，倒不如说是简化版的 Serverless。在 2008 年，在绝大多数人还完全不知道云计算为何物的情况下，这样的产品要想取得成功拿下企业用户，确实有些困难。不过，在这里我们想要讨论的并不是 Google 的云战略，而是为什么从技术的角度上，Google 也认为 GAE 这样的应用托管服务就是云计算呢？这里的一个重要原因可能很多人都了解过，那就是 Google 的基础设施技术栈其实是一个标准容器技术栈，而不是一个虚拟机技术栈。更为重要的是，在 Google 的这套体系下，得益于 Borg 项目提供的独有的应用编排与管理能力，容器不再是一个简单的隔离进程的沙箱，而成为了对应用本身的一种封装方式。依托于这种轻量级的应用封装，Google 的基础设施可以说是一个天然以应用为中心的托管架构和编程框架，这也是很多前 Googler 调侃“离开了 Borg 都不知道怎么写代码”的真实含义。这样一种架构和形态，映射到外部的云服务成为 GAE 这样的一个 PaaS/Serverless 产品，也就容易理解了。而 Google 这套容器化基础设施的规模化应用与成熟，可以追溯到 2004~2007 年之间，而这其中一个最为关键的节点，正是一种名叫 Process Container 技术的发布。 Process Container 的目的非常直白，它希望能够像虚拟化技术那样给进程提
9.开篇 < ix 供操作系统级别的资源限制、优先级控制、资源审计能力和进程控制能力，这与前面提到的沙箱技术的目标其实是一致的。这种能力，是前面提到的 Google 内部基础设施得以实现的基本诉求和基础依赖，同时也成为了 Google 眼中“容器”技术的雏形。带着这样的设思路，Process Container 在 2006 年由 Google 的工程师正式推出后，第二年就进入了 Linux 内核主干。不过，由于 Container 这个术语在 Linux 内核中另有它用，Process Container 在 Linux 中被正式改名叫作：Cgroups。Cgroups 技术的出现和成熟，标志在 Linux 阵营中“容器”的概念开始被重新审视和实现。更重要的是，这一次 “容器”这个概念的倡导者变成了 Google：一个正在大规模使用容器技术定义世界级基础设施的开拓者。在 2008 年，通过将 Cgroups 的资源管理能力和 Linux Namespace 的视图隔离能力组合在一起，LXC（Linux Container）这样的完整的容器技术出现在了 Linux 内核当中。尽管 LXC 提供给用户的能力跟前面提到的各种 Jails 以及 OpenVZ 等早期 Linux 沙箱技术是非常相似的，但伴随着 Linux 操作系统开始迅速占领商用服务器市场的契机，LXC 的境遇比前面的这些前辈要好上不少。而更为重要的是，2008 年之后 AWS，Microsoft 等巨头们持续不断的开始在公有云市场上进行发力，很快就催生出了一个全新的、名叫 PaaS 的新兴产业。老牌云计算厂商在 IaaS 层的先发优势以及这一部分的技术壁垒，使得越来越多受到公有云影响的技术厂商以及云计算的后来者，开始思考如何在 IaaS 之上构建新的技术与商业价值，同时避免走入 GAE 当年的歧途。在这样的背景之下，一批以开源和开放为主要特点的平台级项目应运而生，将“PaaS”这个原本虚无缥缈的概念第一次实现和落地。这些 PaaS 项目的定位是应用托管服务，而不同于 GAE 等公有云托管服务，这些开放 PaaS 项目希望构建的则是完全独立于 IaaS 层的一套应用管理生态，目标是借助 PaaS 离开发者足够近的优势锁定云乃至所有数据中心的更上层入口。这样的定位，实际上就意味着 PaaS 项目必须能够不依赖 IaaS 层虚拟机技术，就能够将用户提交的应用进行封装，然后快速的部署到下层基础设施上。而这其中，开源、中立，同时又轻量、敏捷的 Linux 容器技术，自然就成为了 PaaS 进行托
10.x > 阿里巴巴云原生实践 15 讲管和部署应用的最佳选择。在 2009 年，VMware 公司在收购了 SpringSource 公司（Spring 框架的创始公司）之后，将 SpringSource 内部的一个 Java PaaS 项目的名字，套在了自己的一个内部 PaaS 头上，然后于 2011 年宣布了这个项目的开源。这个项目的名字，就叫做：Cloud Foundry。2009 年，Cloud Foundry 项目的诞生，第一次对 PaaS 的概念完成了清晰而完整的定义。这其中， “PaaS 项目通过对应用的直接管理、编排和调度让开发者专注于业务逻辑而非基础设施”，以及“PaaS 项目通过容器技术来封装和启动应用”等理念，也第一次出现在云计算产业当中并得到认可。值得一提的是，Cloud Foundry 用来操作和启动容器的项目叫做：Warden，它最开始是一个 LXC 的封装，后来重构成了直接对 Cgroups 以及 Linux Namespace 操作的架构。 Cloud Foundry 等 PaaS 项目的逐渐流行，与当初 Google 发布 GAE 的初衷是完全一样的。说到底，这些服务都认为应用的开发者不应该关注于虚拟机等底层基础设施，而应该专注在编写业务逻辑这件最有价值的事情上。这个理念，在越来越多的人得以通过云的普及开始感受到管理基础设施的复杂性和高成本之后，才变得越来越有说服力。在这幅蓝图中，Linux 容器已经跳出了进程沙箱的局限性，开始扮演着 “应用容器”的角色。在这个新的舞台上，容器和应用终于画上了等号，这才最终使得平台层系统能够实现应用的全生命周期托管。按照这个剧本，容器技术以及云计算的发展，理应向着 PaaS 和以应用为中心的方向继续演进下去。如果不是有一家叫做 Docker 的公司出现的话。容器：改写的软件交付的历程如果不是亲历者的话，你很难想象 PaaS 乃至云计算产业的发展，会如何因为
11.开篇 < xi 2013 年一个创业公司开源项目的发布而被彻底改变。但这件事情本身，确实是过去 5 年间整个云计算产业变革的真实缩影。 Docker 项目的发布，以及它与 PaaS 的关系，想必我们已经无需再做赘述。一个“降维打击”，就足以给当初业界的争论不休画上一个干净利落的句号。我们都知道，Docker 项目发布时，无非也是 LXC 的一个使用者，它创建和使用应用容器的逻辑跟 Warden 等没有本质不同。不过，我们现在也知道，真正让 PaaS 项目无所适从的，是 Docker 项目最厉害的杀手锏：容器镜像。关于如何封装应用，这本身不是开发者所关心的事情，所以 PaaS 项目有着无数的发挥空间。但到这如何定义应用这个问题，就是跟每一位技术人员息息相关了。在那个时候，Cloud Foundry 给出的方法是 Buildpack，它是一个应用可运行文件（比如 WAR 包）的封装，然后在里面内置了 Cloud Foundry 可以识别的启动和停止脚本，以及配置信息。然而，Docker 项目通过容器镜像，直接将一个应用运行所需的完整环境，即：整个操作系统的文件系统也打包了进去。这种思路，可算是解决了困扰 PaaS 用户已久的一致性问题，制作一个“一次发布、随处运行”的 Docker 镜像的意义，一下子就比制作一个连开发和测试环境都无法统一的 Buildpack 高明了太多。更为重要的是，Docker 项目还在容器镜像的制作上引入了“层”的概念，这种基于“层”（也就是“commit”) 进行 build，push，update 的思路，显然是借鉴了 Git 的思想。所以这个做法的好处也跟 Github 如出一辙：制作 Docker 镜像不再是一个枯燥而乏味的事情，因为通过 DockerHub 这样的镜像托管仓库，你和你的软件立刻就可以参与到全世界软件分发的流程当中。
12.xii > 阿里巴巴云原生实践 15 讲至此，你就应该明白，Docker 项目实际上解决的确实是一个更高维度的问题：软件究竟应该通过什么样的方式进行交付？更重要的是，一旦当软件的交付方式定义的如此清晰并且完备的时候，利用这个定义在去做一个托管软件的平台比如 PaaS，就变得非常简单而明了了。这也是为什么 Docker 项目会多次表示自己只是“站在巨人肩膀上”的根本原因：没有最近十年 Linux 容器等技术的提出与完善，要通过一个开源项目来定义并且统一软件的交付历程，恐怕如痴人说梦。云，应用，与云原生时至今日，容器镜像已经成为了现代软件交付与分发的事实标准。然而， Docker 公司却并没有在这个领域取得同样的领导地位。这里的原因相比大家已经了然于心：在容器技术取得巨大的成功之后，Docker 公司在接下来的“编排之争”中犯下了错误。事实上，Docker 公司凭借“容器镜像”这个巧妙的创新已经成功解决了“应用交付”所面临的最关键的技术问题。但在如何定义和管理应用这个更为上层的问题上，容器技术并不是“银弹”。在“应用”这个与开发者息息相关的领域里，从来就少不了复杂性和灵活性的诉求，而容器技术又天然要求应用的“微服务化”和 “单一职责化”，这对于绝大多数真实企业用户来说都是非常困难的。而这部分用户，又偏偏是云计算产业的关键所在。而相比于 Docker 体系以“单一容器”为核心的应用定义方式，Kubernetes 项目则提出了一整套容器化设计模式和对应的控制模型，从而明确了如何真正以容器为核心构建能够真正跟开发者对接起来的应用交付和开发范式。而 Docker 公司、 Mesosphere 公司以及 Kubernetes 项目在“应用”这一层上的不同理解和顶层设计，其实就是所谓“编排之争”的核心所在。 2017 年末，Google 在过去十年编织全世界最先进的容器化基础设施的经验，最终帮助 Kubernetes 项目取得到了关键的领导地位，并将 CNCF 这个以“云原生” 为关键词的组织和生态推向了巅峰。而最为有意思的是，Google 公司在 Kubernetes 项目倾其全力注入的“灵魂”，既不是 Borg/Omega 多年来积累下来的大规模调度与资源管理能力，也不是“三大
13.开篇 < xiii 论文”这样让当年业界望尘莫及的领先科技。Kubernetes 项目里最能体现 Google 容器理念的设计，是“源自 Borg/Omega 体系的应用编排与管理能力”。我们知道，Kubernetes 是一个“重 API 层”的项目，但我们还应该理解的是， Kubernetes 是一个“以 API 为中心”的项目。围绕着这套声明式 API，Kubernetes 的容器设计模式，控制器模型，以及异常复杂的 apiserver 实现与扩展机制才有了意义。而这些看似繁杂的设计与实现背后，实际上只服务于一个目的，那就是：如何让用户在管理应用的时候能最大程度的发挥容器和云的价值。本着这个目的，Kubernetes 才会把容器进行组合，用 Pod 的概念来模拟进程组的行为。才会坚持用声明式 API 加控制器模型来进行应用编排，用 API 资源对象的创建与更新（PATCH）来驱动整个系统的持续运转。更确切的说，有了 Pod 和容器设计模式，我们的应用基础设施才能够与应用（而不是容器）进行交互和响应的能力，实现了“云”与“应用”的直接对接。而有了声明式 API，我们的应用基础而设施才能真正同下层资源、调度、编排、网络、存储等云的细节与逻辑解耦。我们现在，可以把这些设计称为“云原生的应用管理思想”，这是我们“让开发者专注于业务逻辑”、“最大程度发挥云的价值”的关键路径。所以说，Kubernetes 项目一直在做的，其实是在进一步清晰和明确“应用交付”这个亘古不变的话题。只不过，相比于交付一个容器和容器镜像，Kubernetes 项目正在尝试明确的定义云时代“应用”的概念。在这里，应用是一组容器的有机组合，同时也包括了应用运行所需的网络、存储的需求的描述。而像这样一个“描述” 应用的 YAML 文件，放在 etcd 里存起来，然后通过控制器模型驱动整个基础设施的状态不断地向用户声明的状态逼近，就是 Kubernetes 的核心工作原理了。未来：应用交付的革命不会停止说到这里，我们已经回到了 2019 年这个软件交付已经被 Kubernetes 和容器重新定义的时间点。在这个时间点上，Kubernetes 项目正在继续尝试将应用的定义、管理和交付推向一个全新的高度。我们其实已经看到了现有模型的一些问题与不足之处，尤其是声
14.xiv > 阿里巴巴云原生实践 15 讲明式 API 如何更好的与用户的体验达成一致。在这个事情上，Kubernetes 项目还有不少路要走，但也在快速前行。我们也能够看到，整个云计算生态正在尝试重新思考 PaaS 的故事。Google Cloud Next 2019 上发布的 Cloud Run，其实已经间接宣告了 GAE 正凭借 Kubernetes 和 Knative 的标准 API“浴火重生”。而另一个典型的例子，则是越来越多很多应用被更“极端”的抽象成了 Function，以便完全托管于与基础设施无关的环境（FaaS）中。如果说容器是完整的应用环境封装从而将应用交付的自由交还给开发者，那么 Function 则是剥离了应用与环境的关系，将应用交付的权利交给了 FaaS 平台。我们不难看到，云计算在向 PaaS 的发展过程中被 Docker“搅局”之后，又开始带着“容器”这个全新的思路向“ PaaS ”不断收敛。只不过这一次，PaaS 可能会换一个新的名字叫做：Serverless。我们还能够看到，云的边界正在被技术和开源迅速的抹平。越来越多的软件和框架从设计上就不再会跟某云产生直接绑定。毕竟，你没办法抚平用户对商业竞争担忧和焦虑，也不可能阻止越来越多的用户把 Kubernetes 部署在全世界的所有云上和数据中心里。我们常常把云比作“水、电、煤” ，并劝诫开发者不应该关心“发电”和 “烧煤”的事情。但实际上，开发者不仅不关心这些事情，他们恐怕连“水、电、煤” 是哪来的都不想知道。在未来的云的世界里，开发者完全无差别的交付自己的应用到世界任何一个地方，很有可能会像现在我们会把电脑插头插在房间里任何一个插孔里那样自然。这也是为什么，我们看到越来越多的开发者在讨论“云原生”。我们无法预见未来，但代码与技术演进的正在告诉我们这样一个事实：未来的软件一定是生长于云上的。这将会是“软件交付”这个本质问题的不断自我革命的终极走向，也是“云原生”理念的最核心假设。而所谓“云原生”，实际上就是在定义一条能够让应用最大程度利用云的能力、发挥云的价值的最佳路径。在这条路径上，脱离了“应用”这个载体，“云原生”就无从谈起；容器技术，则是将这个理念落地、将软件交付的革命持续进行下去的重要手段之一。而至于 Kubernetes 项目，它的确是整个“云原生”理念落地的核心与关键所在。但更为重要的是，在这次关于“软件”的技术革命中，Kubernetes 并不需要尝
15.开篇 < xv 试在 PaaS 领域里分到一杯羹：它会成为连通“云”与“应用”的高速公路，以标准、高效的方式将“应用”快速交付到世界上任何一个位置。而这里的交付目的地，既可以是最终用户，也可以是 PaaS/Serverless 从而催生出更加多样化的应用托管生态。“云”的价值，一定会回归到应用本身。一起进入云原生架构时代在云的趋势下，越来越多的企业开始将业务与技术向“云原生”演进。这个过程中最为艰难的挑战其实来自于如何将应用和软件向 Kubernetes 体系进行迁移、交付和持续发布。而在这次技术变革的浪潮中，“云原生应用交付”，已经成为了 2019 年云计算市场上最热门的技术关键词之一。阿里巴巴从 2011 年开始通过容器实践云原生技术体系，在整个业界都还没有任何范例可供参考的大背境下，逐渐摸索出了一套比肩全球一线技术公司并且服务于整个阿里集团的容器化基础设施架构。在这些数以万计的集群管理经验当中，阿里容器平台团队探索并总结了四个让交付更加智能与标准化的方法：Everything on Kubernetes，利用 K8s 来管理一切，包括 K8s 自身；应用发布回滚策略，按规则进行灰度发布，当然也包括发布 kubelet 本身；将环境进行镜像切分，分为模拟环境和生产环境；并且在监控侧下足功夫，将 Kubernetes 变得更白盒化和透明化，及早发现问题、预防问题、解决问题。而近期，阿里云容器平台团队也官宣了两个社区项目：Cloud Native App Hub—— 面向所有开发者的 Kubernetes 应用管理中心，OpenKruise —— 源自全球顶级互联网场景的 Kubernetes 自动化开源项目集。 OpenKruise 开源地址https://github.com/openkruise/kruiseCloud Native App Hubhttps://developer.aliyun.com/hub云原生应用中心（Cloud Native App Hub），它首先为国内开发者提供了一个
16.xvi > 阿里巴巴云原生实践 15 讲 Helm 应用中国镜像站，方便用户获得云原生应用资源，同时推进标准化应用打包格式，并可以一键将应用交付到 K8s 集群当中，大大简化了面向多集群交付云原生应用的步骤；而 OpenKruise/Kruise 项目致力于成为“云原生应用自动化引擎”，解决大规模应用场景下的诸多运维痛点。OpenKruise 项目源自于阿里巴巴经济体过去多年的大规模应用部署、发布与管理的最佳实践，从不同维度解决了 Kubernetes 之上应用的自动化问题，包括部署、升级、弹性扩缩容、QoS 调节、健康检查，迁移修复等等。在接下来的时间，阿里云容器平台团队还会以此为基础，继续同整个生态一起推进云原生应用定义、K8s CRD 与 Operator 编程范式、增强型 K8s 自动化插件等一系列能够让云原生应用在规模化多集群场景下实现快速交付、更新和部署等技术的标准化与社区化。我们期待与您一起共建，共同体迎接云原生时代的来临！
17.阿里云原生实践坚持探索与落地并重，阿里巴巴云原生之路全景揭秘阿里云容器平台资深技术专家李响为什么要做云原生？云原生究竟能带来什么价值？从最初的独自摸索到如今拥抱开源回馈社区，阿里巴巴走过了怎样的云原生旅程？又有哪些技术心得？今天，将全部分享出来。多年沉淀，坚持探索与落地并重阿里巴巴从 2011 年开始通过容器实践云原生技术体系，在整个业界都还没有任何范例可供参考的大背境下，逐渐摸索出了一套比肩全球一线技术公司并且服务于整个阿里集团的容器化基础设施架构。这个探索历程虽然孤独，但却被始终如一的坚持至今。这正是在这个孤注一掷的技术探索与奋进的过程中，阿里巴巴的技术团队完整的经历了云原生技术浪潮里的所有关键节点，不仅成为了这次技术革命的重要见证者，也逐渐成为中国云原生技术体系当之无愧的推动者与引领者之一。阿里的体量大、业务复杂，推动云原生要找到合适的切入点。在双十一成本压力的推动下，资源成本与效率优化成了阿里云原生的起点。阿里从容器入手，研究低成本虚拟化与调度技术：提供灵活、标准的部署单元；将静态资源分配更换为动态按需调度，进一步提升部署效率，解决资源碎片化问题，提高部署密度；通过存储网络虚拟化和存储计算分离等技术，增强任务的可迁移性，进一步提高了资源的可靠性，降低了资源成本。在资源成本的推动下，阿里完成了全面容器化，资源分配也被高效调度平台接管。阿里的云原生并未止步于此。提高研发效率与加快迭代周期是推动阿里业务增强
18.2 > 阿里巴巴云原生实践 15 讲的秘密武器。阿里希望通过云原生让开发者效率更高。为了降低应用部署难度，提高部署自动化程度，阿里开始采用 Kubernetes 作为容器编排平台，并且持续推动 Kubernetes 的性能与可扩展性。具体 Kubernetes，阿里持续对研发、部署流程进行改进。为了构建更云原生化的 CI/CD，进一步做到标准化和自动化，从研发到上线流程，阿里引入了诸如 Helm 的应用标准化管理，也尝试了 GitOps 这样的部署流程，还推动了 PaaS 层的面向终态自动化改造。于此同时，阿里也开始探索服务网格，致力于进一步提高服务治理的普适性与标准性，降低开发者采用门槛，进一步推动微服务在多语言和多环境下的普及。今年，阿里也展开了全站上云。经过云原生的探索与改造，阿里基础架构体系是现代化和标准化的。利用容器技术，应用与宿主机运行时完成了解耦；利用 Kubernetes 对 Pod 与 Volume 等的抽象，完成了对多种资源实现的统一化；通过智能调度与 PaaS 平台，让自动迁移应用，修复不稳定因素成为了可能，阿里通过云原生技术大大降低了上云的难度。在这个提高资源和人员效率的过程中，阿里巴巴的整个基础设施也变得更加开放，连通开源生态，在交流互动中不断吸收和贡献好的理念、技术、思想。如今，阿里云不仅支撑着中国最大的云原生应用双 11，而且拥有国内最大的公共云集群和镜像仓库。作为唯一入选 Gartner 的公有云容器服务竞争格局的厂商，阿里云也积累了最为丰富和宝贵的客户实践。
19.阿里云原生实践 < 3 追求极致，优化扩展性和规模性弹性和规模性，这是支撑阿里巴巴各种类型的复杂场景以及流量高峰的关键因素。经过不断打磨，阿里巴巴在 Kubernetes 规模与性能上取得了显著的成果：将存储 object 的数量提升 25 倍，支持的节点数从 5000 提升到上万，在端到端调度延迟从 5s 变为 100ms 等等。其中有不少工作在阿里巴巴和社区中共同开展，而这些研发成果都已经贡献给社区，我们期望其他企业及开发者也可以享受阿里巴巴规模所带来的技术红利。阿里巴巴持续优化性能，可以分为以下四个维度：工作负载追踪、性能分析、定制化调度、大规模镜像分发。首先对工作负载调度有完整的追踪、重放机制，其次将所有性能问题的进行细致分析，逐一攻克技术瓶颈。Kubernetes 本身的可定制性很强，阿里巴巴针对自身业务场景沉淀了定制化的调度能力和镜像分发系统。开源 Dragonfly 项目脱胎于双十一，具备极强的镜像分发能力。数十个超级集群，每个超级集群具有数万节点，数百万的容器。阿里巴巴落地 Kubernetes 可以分为三个阶段：首先通过 Kubernetes 提供资源供给，但是不过多干扰运维流程，这系统容器是富容器，将镜像标准化与轻量级虚拟化能力带给了上面的 PaaS 平台。第二步，通过 Kubernetes controller 的形式改造
20.4 > 阿里巴巴云原生实践 15 讲 PaaS 平台的运维流程，给 PaaS 带来更强的面向终态的自动化能力。最后把运行环境等传统重模式改成原生容器与 pod 的轻量模式，同时将 PaaS 能力完全移交给 Kubernetes controller，从而形成一个完全云原生的架构体系。如何解决云原生的关键难点阿里巴巴云原生的探索，起步于自研容器和调度系统，到如今拥抱开源的标准化技术。对于当下开发者的建议是：如果想构建云原生架构，建议直接从 Kubernetes 入手即可。一方面，Kubernetes 为平台建设者而生，已经成为云原生生态的中流砥柱，它不仅向下屏蔽了底层细节，而且向上支撑各种周边业务生态；另一方面，更重要的是社区中有着越来越多围绕 Kubernetes 构建的开源项目，比如 Service Mesh、Kubeflow。那么作为过来人，阿里有哪些“避坑指南”呢？云原生技术架构演进中最为艰难的挑战，其实来自于 Kubernetes 本身的管理。因为 Kubernetes 相对年轻，其自身的运维管理系统生态尚不完善。对于阿里而言，数以万计的集群管理至关重要，我们探索并总结了四个方法：Kubernetes on Kubernetes，利用 K8s 来管理 K8s 自身；节点发布回滚策略，按规则要求灰度发
21.阿里云原生实践 < 5 布；将环境进行镜像切分，分为模拟环境和生产环境；并且在监控侧下足功夫，将 Kubernetes 变得更白盒化和透明化，及早发现问题、预防问题、解决问题。另外一个关键技术问题是 Kubernetes 的多租户管理。相比于 namespace 扩展性差和命名冲突等限制，可以在 Kubernetes 之上建立虚拟集群。在提高扩展性的同时，能够做到 API 层面的强隔离，通过 syncer 链接虚拟集群和真实集群，在 node 添加 agent，达到更好的多租管理和更好的利用。此次 KubeCon 大会上，阿里云重磅公布了两个项目：Cloud Native App Hub——面向所有开发者的 Kubernetes 应用管理中心，OpenKruise——源自全球顶级互联网场景的 Kubernetes 自动化开源项目集。 OpenKruise 开源地址：https://github.com/openkruise/kruiseCloud Native App Hub：https://developer.aliyun.com/hub云原生应用中心（Cloud Native App Hub），可以简单理解为 Helm 应用中国镜像站，方便用户获得应用资源，并大大简化了 Kubernetes 部署安装一个应用的步骤；OpenKruise/Kruise 项目致力于成为“云原生应用自动化引擎”，解决大规模应用场景下的诸多运维痛点。这次沙龙首秀，开发者们体验了从云原生应用中心快速下载应用，并通过带状态 pod 原地升级、sidecar 容器注入、节点镜像预热等三个场景，实际体验了 Kruise 强大的自动化运维能力。值得一提的是，OpenKruise 项目源自于阿里巴巴经济体过去多年的大规模应用部署、发布与管理的最佳实践；源于容器平台团队对集团应用规模化运维，规模化建站的能力；源于阿里云 Kubernetes 服务数千客户的需求沉淀。从不同维度解决了 Kubernetes 之上应用的自动化问题，包括部署、升级、弹性扩缩容、QoS 调节、健康检查，迁移修复等等。
22.6 > 阿里巴巴云原生实践 15 讲 1-5-10：如何快速恢复大规模容器故障阿里云容器平台技术专家宁拙 Agenda 在云计算时代，基于容器的应用规模越来越大，随之而来的容器故障也越来越多，故障原因有许多，比如人工误操作，硬件故障等等。如何在不提升成本的前提下提高稳定性，成为大家都要面临的挑战。在阿里巴巴，运行着数百万的容器，积累了大量素材，经过分析提炼之后，提出 1-5-10 的目标。今天的话题就是 1-5-10，将分为 4 个阶段来讲述：第一是介绍一下 1-5-10 的定义；第二是我们来复盘 review 一次故障；第三和第四就是如何达成 1-5-10: 分别是通过线下和线上两个维度的改进来达成 1-5-10 ；
23.阿里云原生实践 < 7 1-5-10 1. 1 分钟发现问题 2. 5 分钟定位问题 3. 10 分钟恢复为什么是 1-5-10 呢？基于我们的一些历史数据分析，部分故障是能做到 1-5-10，但依然还有不少故障是超出了 1-5-10。所以呢，我们制定了 1-5-10 的目标，牵引大家一起提升故障发现，定位以及恢复的能力，实现缩短故障时长、减少故障影响，从而达到让集团没有重大故障的目的。现在定义和目标明确了，接下来我们就看一次故障的时间线，看看是否做到了 1-5-10。
24.8 > 阿里巴巴云原生实践 15 讲某模拟故障的时间线在分析这次故障时间线之前，我想先分享一个很好的理念，这个理念来自谷歌 SRE，说的就是事后分析，通过事后分析，我们可以从失败中吸取教训，并且提炼出一系列的方法，可以指导我们在未来避免犯类似的错误。我们现在就用事后分析的方法，来看一下这个故障的时间线： 15 点 17 开始发布，17 点 30 才收到报警，18 点 15 还未能止血，直到 19 点
25.阿里云原生实践 < 9 才通过切流 + 回滚的方式恢复。这里顺便提一句，作为底层基础设施，一个很小的问题，到上层可能就被放大成一个很大的问题，所以我们做底层基础设施的团队，稳定性更是重中之重。稳定性是 1，特性，功能，性能，都是后面的 0，如果 1 不存在了，后面的 0 将一直都是 0。我们继续讲这个故障，这是一个很典型的因变更发布导致的问题，更明显的是，没有达成 1-5-10 的目标。故障是 15 点发生，到 19 点才完成止血，花了将近 4 小时，离 1-5-10 的目标相去甚远。接下来我们看看在哪些地方可以改进，可以做的更好，可以帮助我们达成 1-5-10。暴露的问题通过对这次故障的分析，我们学到了什么呢？暴露了哪些问题？我们该如何去改进呢？ 1. 对故障不敏感，收到报警后，本应该立即停止，但是还继续进行第三批的操作。如果及时停止，问题的影响就不会这么大。 2. 风险意识不足，对新特性的评估不谨慎，没有做全场景的验证就发布。如果在开发、发布的过程中，有足够的风险意识，可能问题就提早暴露了，而不是流入到线上。
26.10 > 阿里巴巴云原生实践 15 讲 3. 灰度没做好，没有严格遵守灰度流程，没有留够观察时间。理论上来说，我们如果留了足够的观察时间，应该是可以发现问题的，问题的规模就不会这么大。 4. 可观测性差，15:17 开始操作，17:30 才收到报警。如果观测性足够好，异常的指标尽早暴露出来，那么应该可以更早的发现问题。 5. 缺乏快速止血的手段，17:30 收到报警，到 18:19 都未能止血，直到 19 点才恢复，这样的恢复速度，实在是难以接受。针对这些问题，我们将从线下和线上这两个方向来改进。其实用线下和线上这两个词并不准确，暂时没有想到合适的词来描述，我们先看下这两者都包含哪些内容。如何改进线下： 1. 故障复盘，也就是事后分析，从失败中学习，避免再犯。 2. 故障预防，在问题发生之前，就将稳定性作为第一要素考虑进去。 3. 故障演练，通过故障演练，一方面可以发现平时注意不到的问题；另一方面，可以形成正确的应急流程，总结出一套应急预案。这样大家在遇到真正的问题的时候，就不会手忙脚乱。
27.阿里云原生实践 < 11 线上：主要是通过技术手段来解决稳定性的问题，有四个方面： 1. 可灰度。有正确的流程，正确的工具，来进行变更操作，如果有问题，可以及时发现，避免范围扩大，引发更大的故障。 2. 可止血。光是避免范围扩大还是不够，我们还需要能及时止血，避免问题继续持续下去，尽早恢复。 3. 可观测。可以及时观测到问题，如果问题发生，就能及时发现并通知到相关人员。 4. 自动修复。当集群规模足够大，有一些问题是不可避免的，并且是每时每刻都在发生，对于这样的问题，如果不及时处理，也可能会积少成多形成故障，所以我们还需要一种自动修复的机制，尽快地解决掉这类问题。目录接下来我们进入第三节，详细看一下，如何通过线下手段，帮助我们做到 1-5-10。
28.12 > 阿里巴巴云原生实践 15 讲故障复盘既然我们的目标是 1-5-10，那么我们可以针对几个关键的时间点来进行复盘，找出问题所在，制定相应的措施。我们将故障分为 4 个阶段来分析。第一个阶段，故障发生，有两个关键的时间点，故障注入和故障发生的时间， review 的时候要重点关注，故障的根因是什么？以及以后能不能避免同类的问题？这也是我们做复盘的重要目的之一。第二个阶段，故障发现。这个阶段的关键就是故障发现的时间点，review 的时候要关注： 1. 故障发现的途径是什么？是人工发现还是自动发现？能不能做到自动发现？ 2. 故障是由谁发现的？是业务方，还是责任方？如果是业务方发现的，之后能不能责任方自己发现？而不是等业务反馈才知道出了问题。等到业务方反馈，那么就远远超出 1 分钟了。 3. 故障能不能快速发现？能不到做到 1 分钟之内发现？ 4. 故障能不能提前发现？在故障真正爆发之前，就发现，对于整个业务的稳定性的收益，是巨大的。
29.阿里云原生实践 < 13 第三个阶段，故障定位。相对来说，这个阶段，耗时是最多的，我们需要特别重视。需要关注 3 个时间点，故障相关人接手的时间点，定位出根因的时间点，找出止血方法的时间点。review 的要点： 1. 相关人是否及时接手？没有接手的原因是什么？节假日？通知不及时？责任不明确？ 2. 定位根因的方法是什么？是通过监控数据发现，还是通过查日志等需要耗费大量时间的操作发现的？以后可不可以做到自动发现？只有做到自动发现， 5 分钟这个目标才有可能达成。 3. 是否通过人工排查才找出止血方法？有没有不需要人工排查分析，就能更快速的止血方法？第四个阶段，故障恢复。需要关注两个时间点，系统恢复的时间，业务恢复的时间。这里需要关注 1. 恢复的方法是什么？回滚，切流，重启，隔离，新发布？ 2. 执行恢复的操作花了多久时间？有没有更快的方式？ 3. 未来可不可以快速的回复？其实就是要求我们，要提前准备好低成本，可快速完成的应急预案。故障预防
30.14 > 阿里巴巴云原生实践 15 讲先说结论：稳定性要贯穿产品设计，产品研发，产品验证和产品准入各个环节。具体表现在： 1. 软件工程，从代码质量入手，做好测试，验证。 2. 稳定性是什么？不是完全不发生问题，而是能够将问题影响降到最小。所以，这就要求我们，所有的线上异常，都要能自动化发现，自动化处理，才能对客户影响减少到最小。在产品研发阶段我们不仅需要适配性能，功能，我们也需要做到可监控，充分考虑发布的场景，在研发阶段就需要考虑清楚每一个异常应该怎样隔离。对于做不到的产品，SRE 有权拒绝上线。故障演练不演练，永远不知道哪里会出问题。质量不是测出来的，故障演练本身并不能够直接提高系统的健壮性，但是可以有效衡量和推动系统健壮性提高。合理地、科学地逐步进行故障注入和混沌工程建设，有助于了解当前系统的弱点做到知己知彼，有助于帮助大家认识到系统的薄弱点反推设计，也有助于团队工程素质、设计能力和应急能力的整体提高，是一个很好的练兵场。
31.阿里云原生实践 < 15 目录接下来我们将一起看下，如何通过线上的技术手段来解决稳定性问题。可灰度每一次规模化的操作，都必须经过灰度。在灰度的过程中，做好观测，如果发现问题，要快速解决。那么，什么样的灰度方案比较好呢？当然并没有完美的灰度方案，只有最适合的。我们是这样做的：将机房分为两大类——日常机房和线上机房。从机器重要性来看，我们分为核心业务和非核心业务。比如说一些线下新零售的业务，直接与客户在
32.16 > 阿里巴巴云原生实践 15 讲线下打交道，这个就是非常重要的业务，容不得半点差池，所以我们在灰度的时候，一般都是先避开这些核心业务。具体的灰度节奏是：从日常机房开始，先对非核心机器进行变更，按照 1-1050-100 的节奏，留够观测时间；然后是线上机房，同样的节奏。在灰度的过程中，发布系统会从监控系统取数据，判断发布是否成功，如果出现了异常，则会通知到操作人来决策，是要继续灰度，或是回滚。可止血有个原则：在变更之前，就要确定止血策略，未虑胜先虑败。没有止血方案，没有应急预案的变更，一律不许上线。其实在故障发生的时候，快速止血的方案会有很多。一般我们想到的都是回滚，在除了回滚以外，还有哪些方案？如果故障处理经验丰富的人一定知道，除了回滚，其实还有隔离，降级等多种方案。所以呢，我们在制定止血方案的时候，要充分考虑止血的可操作性以及耗时，尽量选择一个成本低的止血方案，这样一方面可以加快止血速度，尽快恢复业务，另一方面也容易操作，避免二次故障，线上的操作，一定要最简化。
33.阿里云原生实践 < 17 可观测先简单介绍一下我们当前的监控系统，我们的监控系统是叫 Infra Store，是基于 Prometheus 和 Thanos 来做的。监控数据分为两大类： 1. 控制面，主要是 api-server，scheduler，etcd 等控制组件的指标和事件。 2. 节点，包括节点，pod，容器，pouch daemon，containerd 等节点上组件的资源类指标（比如 CPU 内存使用情况）等指标。这两大类的指标，都会都会被 Prometheus 抓取。但这里边有个比较关键的缺失，我们对宿主机上的异常，检测不够充分，比如说 systemd 有问题，我们需要通过 containerd kubelet 的一些错误才能发现，但这个时候可能为时已晚。因此我们基于社区的 Node Problem Detector（简称 NPD ）做了增强，接下来我们看一下 NPD。
34.18 > 阿里巴巴云原生实践 15 讲 NPD 首先看一下社区 NPD 的介绍：发现节点的问题，并上报到 api-server。 NPD 支持多种检测模式，比如说支持自定义脚本，支持 log 分析，将检测的结果，转化成 condition 或 event，上报到 api-server。前面说到，我们的监控系统是基于 Prometheus 来做的，社区的 NPD 只是将异常事件发送到 API-server，所以上报到 api-server 的方案不满足我们需求的。因此，我们在社区的基础上，增加了 Exporter 层，收集检测结果，然后将检测结果通过不同的 Adapter，上报到不同的系统。我们现在用的比较多是 Prometheus。
35.阿里云原生实践 < 19 看一下我们的方案，其实比较简单，只是在传递检测结果那里，增加了一个通道。在后来，我们和 NPD maintainer 交流之后，社区也开始在做类似的事，具体可以看 PR。https://github.com/kubernetes/node-problem-detector/pull/275上层的发布系统，监控报警系统，通过 NPD 上报的异常信息，已有的节点 agent 和控制面的指标，得到了更多的输入，可以发现更多的问题，可以更快的发现问题。但仅仅发现和上报问题，其实是不够的，还有一些比较小的问题，是完全可以自动修复的，还有一些潜在的问题，是可以通过一定的分析提前预测出来的。接下来我们看看 debugger 的自动修复和异常预测。
36.20 > 阿里巴巴云原生实践 15 讲异常诊断自动修复通过 NPD，我们增加了许多异常检测项，可以获取到节点更多的状态，拿到了很多异常的信息。如何利用这些信息呢？我们开发了一个叫 container debugger 的组件， debugger 基于这些异常信息，以及我们构建的知识库，每个异常都有对应的一个修复方案，发现异常就执行自动修复。比如修复节点上的网卡问题。简单描述一下这个问题的症状，大家都知道，容器的网络离不开 veth pair，有这么一种情况，veth 在宿主机节点的这一端，并没有挂到网桥上，这样容器的网络就有问题，所以呢，我们增加了一个检测项，用于发现这类异常，然后增加了一个 case，如果发现这个问题，就将 veth 再挂回去。像这类比较简单的问题，都可以通过自动修复来解决，但如果遇到实在无法解决的问题，只只能将容器迁移到别的节点。
37.阿里云原生实践 < 21 自动修复与异常预测 debugger 是如何运行的呢？可以分为两部分：自动修复和异常预测。第一部分，自动修复。前面我们说到，每个检测项都被转换成了指标，汇总到 Prometheus。debugger 有个 healer 模块，会自动去 Prometheus 取指标，如果某个指标异常，并且符合 case 的定义，healer 就会调用 staragent 到节点上去执行修复任务。第二部分，就是我们才开始做的，是关于异常预测。大概的原理，就是基于一些无法完全通过设置阈值来做告警的指标，我们通过一些算法，来做分析，提前发现一些潜在的问题。如果确定是风险比较高，则会使用报警通道进行报警，提前人工排查和干预。
38.22 > 阿里巴巴云原生实践 15 讲 Prophet 现在还不是特别准确，只能简单看一下预测的一些结果。
39.阿里云原生实践 < 23 阿里巴巴利用 K8S、Kata 容器和裸金属服务器构建无服务器平台阿里云容器平台技术专家张翼飞（悟鹏）阿里云容器平台高级开发工程师唐华敏（华敏）前言 Serverless 是近一年来比较火的概念，在理解这个概念和使用相应的服务之前，需要理解： ●● 现状中的痛点是什么 ●● Serverless 解决的问题域是什么 ●● Serverless 的解决方案是什么 ●● 如何做的更好本次分享将探讨上述问题，并针对解决方案中核心的安全容器 Kata Containers 做深入分析。现状中的痛点先简单回顾下开发的常见流程：
40.24 > 阿里巴巴云原生实践 15 讲从上图可看出，服务的开发、运维是个持续迭代的过程，在这几个阶段，通常都会有如下问题需要处理： ●● 开发、测试、预发、线上的环境维护，包括准备、调整等 ●● 最佳实践的应用 ●● 有效进行迭代 ●● 快速进行响应上述这些问题很多都是重复性的，且在每个迭代中都会重复进行。纵览一次迭代中不同阶段和事项的耗时，往往投入到业务逻辑开发的耗时占比会很小，大部分的时间是在处理环境维护、运维管理工作，其次是在开发阶段应用最佳实践。 Serverless 解决的问题域抽象下上述描述的问题域： ●● 运行 / 运维成本高 ●● 开发成本高 Serverless 主要解决的是上述两个问题：
41.阿里云原生实践 < 25 Serverless 的解决方案 Serverless 是如何解决上述问题的？先看下来自维基百科中对 Serverless 的定义： Serverless computing is a cloud-computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity. 平台方维护资源池，用户可以动态申请资源，解决用户的环境准备和维护问题，降低用户的运维成本。平台方针对用户使用的资源进行计费，降低用户服务的运行成本。平台方提供诸如无侵入性的日志、监控、告警等常规运维服务，进一步提供服务副本数保障、网络管理、扩缩容等确保服务高可用的服务，进一步降低用户服务的运行和运维成本。平台还可以针对服务开发过程中的通用逻辑进行抽象，使得用户更集中精力在业务逻辑的实现方面，降低服务的开发成本。 Serverless 平台的搭建那么如何搭建 Serverless 平台呢？先思考下 Serverless 平台的挑战，关键有这几方面：
42.26 > 阿里巴巴云原生实践 15 讲安全强调的是 Serverless 平台上的租户的服务安全，不同租户间不能通过非法方式进行访问。成本强调是平台方需要尽可能降低运维平台的成本，虽然单个应用对应单个虚拟机的模型可以很大程度上解决安全问题，但平台上需要承担很大的成本。性能强调的是运行在 Serverless 平台上的租户服务，调度和运行性能需要满足租户的需求。解决上述挑战的关键在于如何支持多租，即不同租户的服务会运行在同一个节点上，需要实现硬多组。细化下多租相关的维度：强隔离是多租需要满足的核心需求，包括数据面和控制面两个层面，其中数据面的强隔离更为关键。不同租户的服务在运行时不能通过非法手段访问到，网络方面要从二层网络隔离。服务运行时一般会依赖其他云产品服务，如 RDS、MQ 等，为了提升云上同一租户的云服务之间相互访问的性能，提升安全性，也需要满足联通的需求。除此之外，启动性能和运行性能是服务运行时的核心诉求，在多租场景下满足安全和成本的同时，不能降低服务运行时的性能。
43.阿里云原生实践 < 27 针对上述问题，解决方案：不同租户的服务运行时的强隔离，通过安全容器来解决。每个服务实例运行在轻量级的 VM 中，独占内核，降低共享内核带来的风险。不同租户的服务网络之间，通过云上的 VPC 强隔离，不同 VPC 内的服务天然不能互通。弹性裸金属服务器是一款同时兼具虚拟机弹性和物理机性能及特性的新型计算类产品，既保留了普通云服务器的资源弹性，又借助嵌套虚拟化技术保留了物理机的体验。基于弹性裸金属服务器，提升服务运行时对性能的诉求。我们基于 Kubernetes 做资源管理和服务编排，按照用户的申请进行资源的调度：
44.28 > 阿里巴巴云原生实践 15 讲 Kubernetes 中有 namespace 的概念，从逻辑上集合一组资源。而在上述多租的设计中，有租户、VPC 的概念，一个租户可以有多个 VPC。为了管理上的方便，需要将此 3 个概念进行映射。有这样的关系： ●● 每个租户有多个 Kubernetes namspace ●● 每个 Kubernetes namespace 与一个租户对应 ●● 每个租户有多个 VPC ●● 每个 Kuberentes namespace 与一个 VPC 对应 ●● 每个 VPC 可以对应多个 Kubernetes namespace 如下图所示：以两个租户为例，有这样的关系：
45.阿里云原生实践这样，完整的 Serverless 平台的架构图如下： < 29
46.30 > 阿里巴巴云原生实践 15 讲平台层面，基于 Kubernetes 提供资源管理和调度的能力。 Kubernetes 的 master 节点部署在 3 个可用区，提升 master 节点的可用性。平台维护高性能的弹性裸金属服务器，不同租户的服务混部在节点上，通过安全容器实现不同租户服务间运行时的强隔离，通过 VPC 网络实现网络层面的强隔离和同一租户内服务间的联通性。用户通过控制链路部署服务，业务流量可通过 SLB 进行访问。 Kata Containers on serverless 平台多租户的 serverless 平台上，kata 给容器提供了与 vm 相同的安全性，为用户提供了更好的隔离性。同时有着容器的各种优化，1）兼容 oci 容器镜像，2）与 runc 相同的启动速度，3）比 vm 更轻量的虚拟化来源于 kata 官网的架构图： serverless 平台的 Kata 架构架构：K8s + pouch cri + containerd + kata-runtime + qemu hypervisor
47.阿里云原生实践 < 31 实践中解决的问题 1）kata-runtime 的架构升级，从 shim v1 切换到 shim v2 一方面解决 v1 架构下 kata 组件太多导致的泄漏问题，另一方面可以解决容器优雅退出的问题。 2）9pfs 的替代方案 kata-rutnime 默认的 9pfs 文件系统有几个问题，不兼容 posix 接口，文件操作可能存在问题，io 性能差，会造成 vm hang 住，自研了 qcow2 graph driver 替换 9pfs，并且同步 containerd 社区的 devicemapper 的解决方案。网络和 IO 的优化 kata 容器是集成了虚拟机优势的技术，自然也带来了一些虚机的劣势，在网络和 io 上是比不上 runc 容器的，我们相应的做了优化，使 kata 容器达到生产水平。
48.32 > 阿里巴巴云原生实践 15 讲网络优化阿里云神龙机型提供了 ENI 网卡，基于这个技术，在 kata 容器中，使用了直通网络模式，性能持平 runc 容器。 ENI 网卡还有以下优势：Kata 容器的 ENI 属于用户自己的 VPC，不同用户的 VPC 网络二层隔离，同用户 VPC 内不同云服务的网络可以互通 IO 优化 kata 默认的 9pfs IO 性能差，并且不兼容 posix 接口，文件操作可能会有问题使用了 2 种优化手段，用块设备替代掉 9pfs 1. qcow2 graphdriver 2. device mapper graphdriver
49.阿里云原生实践 < 33 上图是 qcow2 graphdriver 的设计图，把 pull 下来的镜像保存为 qcow2 格式，启动容器时，通过 qcow2 graphdriver，把 docker 镜像以 qcow2 的形式热插到虚拟机中。 Kata 容器的监控方案
50.34 > 阿里巴巴云原生实践 15 讲设计的通用的监控方案，在 containerd 中放一个 metric plugin，不仅适用于 kata 容器的监控，也适用于 runc 或其他使用 containerd shim v2 的运行时的监控。 kata 容器的链路中，通过 shim v2 的 Stat 接口获取 kata 容器的监控数据。如何做的更好对于平台方，需要针对安全、成本、性能方面持续迭代，进一步增强安全性，降低平台维护、服务运行的成本，提升服务的调度和运行性能，给租户带来更好的体验，如采用更精细化的资源隔离手段、更低成本高新性能的安全容器。除了极大降低运行和运维成本，还需要针对开发流程做进一步抽象，提供针对函数、程序包等的运行环境服务和运维最佳实践服务，使得租户可以进一步将精力集中在满足业务逻辑方面。
51.阿里云原生实践 < 35 CafeDeployment：为互联网金融关键任务场景扩展的 Kubernetes 资源蚂蚁金服技术专家昊天蚂蚁金服高级开发工程师枫晟背景介绍 Kubernetes 原生社区 Deployment 和 StatefulSet 解决了“服务节点版本一致性”的问题，并且通过 rolling update 实现了滚动升级，提供了基本的回滚策略。对于高可用建设要求不高的“年轻”业务，是一个不错的选择。但是，在金融场景下，要解决的场景复杂得多，因此我们在金融分布式架构 - 云应用引擎 (SOFAStack-CAFE）中提出了 CafeDeployment 的云原生模型，致力于解决以下问题： 1. IP 不可变对于很多运维体系建设较为早期的用户，使用的服务框架、监控、安全策略，大量依赖 IP 作为唯一标识而被广泛使用。迁移到 Kubernetes 最大的改变就是 IP 会飘，而这对于他们来说，无异于运维、服务框架的推倒重来。 2. 金融体系下的高可用 Deployment/StatefulSet 无法根据特定属性进行差异化部署。而在以同城双活为建设基础的金融领域，为了强管控 Pod 的部署结构（即保证每个机房 / 部署单元都有副本运行，若通过原生组件进行部署，我们不得不维护多个几乎一模一样的 Deployment/StatefulSet），来保证 Pod 一定会飘到指定机房 / 部署单元的 node 上。在规模达到一定程度后，这疑加大了运维管控的复杂度和成本。 3. 灵活的部署策略 Deployment 无法控制发布步长，StatefulSet 虽然可以控制步长，但是每次都
52.36 > 阿里巴巴云原生实践 15 讲需要人工计算最新版本需要的副本数并修改 Partition，在多机房 / 部署单元的情况下，光想想发布要做的操作都脑袋炸裂。在面对以上这些问题的时候，我们思考：能不能有一个类似 Deployment 的东西，不仅可以实现副本保持，而且还能协助用户管控应用节点部署结构、做 Beta 验证、分批发布，减少用户干预流程，实现最大限度减少发布风险的目标，做到快速止损，并进行修正干预。这就是我们为什么选择定义了自己的 CRD—— CafeDeployment。模型定义 CafeDeployment 主要提供跨部署单元的管理功能，其下管理多个 InPlaceSet。每个 InPlaceSet 对应一个部署单元。部署单元是逻辑概念，它通过 Node 上的 label 来划分集群中的节点，而 InPlaceSet 则通过 NodeAffinity 能力，将其下的 Pod 部署到同一个部署单元的机器上，由此实现 CafeDeployment 跨部署单元的管理。 CafeDeployment 作为多个部署单元的上层，除了提供副本保持，历史版本维护等基本功能，还提供了跨部署单元的分组扩容，分组发布，Pod 调度等功能。模型定义如下：
53.阿里云原生实践 < 37apiVersion:apps.cafe.cloud.alipay.com/v1alpha1kind:CafeDeploymentmetadata:......spec:'>spec: