解读容器的 2019：把“以应用为中心”进行到底
作者丨张磊
2019 年，云原生生态少了以往的“剑拔弩张”与“针锋相对”；但这一年，却也是云原生最蓬勃发展的一年。
在这一年，这个生态具有标志性意义的 KubeCon，史无前例的吸引到了一万两千人涌入圣地亚哥，整个会议的赞助商列表，多到一张十余米长的巨幅海报才堪堪放下。在这一年，Kubernetes 终于成为了广受认可的基础设施领域工业标准，而这个标准的确立，则以 AWS 的重量级投入画上了圆满的句号。在这一年，在社区头部参与者的持续推进下，“规模”与“性能”终于成为了 Kubernetes 项目的重要关键词，这不仅真正意义上打通了 Kubernetes 在企业生产环境中大规模落地的最后一公里，也让 Kubernetes 第一次成为了“双十一”等顶级互联网规模化场景中实实在在的技术主角。
在下一个十年交替之际，你是否知道，这个看似波澜不惊的云原生技术生态，又在孕育和经历着哪些全新的变革呢？
如果要提名 2019 年的云原生技术演进的重要节点，那么“规模”一定是其中最当仁不让的关键词。
出于设计理念上的侧重点考虑，Kubernetes 项目在过去乃至到 2019 年之前的很长一段时间内，也并不把“规模”作为整个项目演进的核心优先级来对待。这里的主要原因在于 Kubernetes 的设计思想是“以应用为中心”的基础设施，所以相比于传统作业编排调度管理项目（比如 Mesos 和 Yarn 等）关注的资源效能问题，Kubernetes 的核心竞争力则一直放在工作负载描述、服务发现、容器设计模式等更高纬度的应用基础设施构建上。当然，另一方面的原因在于，对于 Kubernetes 服务提供商，比如 GKE 来说，他们对于规模与性能诉求也是比较有限的。
这个状态，随着 2019 年初顶级互联网公司对 Kubernetes 社区的重量级投入而被打破。事实上，Kubernetes 本身的规模与性能优化并不是一个“不可解”的问题，但是整个社区长期以来欠缺大规模场景和专门的工程力量投入，最终使得发现、诊断和修复整个容器编排与管理链路中各个性能障碍成了一个遥不可及的事情。
在这条关键链路当中， Kubernetes 的规模性问题又可以细分为：以 etcd 为代表的“数据面”、以 kube-apiserver 为代表“管控面”和以 kubelet 及各种 Controller 组成的“生产 / 消费面”三个问题域。在场景的推动下，Kubernetes 以及 etcd 社区在过去的一年里，正是围绕这三个问题域进行了大量的优化，例如：
数据面： 通过优化 etcd 底层数据库的数据结构和算法，将 etcd 百万键值对随机写性能提升 24 倍；
管控面： 为 kube-apiserver 添加 Bookmark 机制，将 APIServer 重启时需要重新同步的事件降低为原来的 3%，性能提高了数十倍；
生产 / 消费面： 将 Kubernetes 节点向 APIServer 的心跳机制从“定时发送”修改为“按需发送”，从而大大减少了规模化场景下 kubelet 对 APIServer 带来的巨大压力，大幅提高了 Kubernetes 所能支持的节点数目上限。
除此之外，在规模化 Kubernetes 落地的具体场景中，围绕着上述三个问题域、在生产环境中经历了充分验证的规模与性能优化实践也在 KubeCon 等技术演讲中浮出水面。比如：如何让多个 kube-apiserver 更均衡的处理生产 / 消费请求、避免性能热点；如何通过合理的设置主备 Controller，让升级 Controller 时无需大量重新同步数据，从而降低 controller 恢复时对 API Server 的性能冲击等等。
这些 Kubernetes 规模与性能领域的“全链路优化”工作，几乎全部源自于真实的互联网级规模化场景，而它们最终完成的得益于顶级开源社区的协同与所有参与者的共同努力。而规模化与性能问题的逐步解决不仅仅带来了为 Kubernetes 项目带来了充足的底气，也正在迅速改变着整个基础设施领域的基本格局。
2019 年 5 月，Twitter 公司在旧金山总部正式宣布 Twitter 的基础设施将从 Mesos 全面转向 Kubernetes。这个新闻仿佛给当时略显沉闷的技术社区里扔进了一颗重磅炸弹一般，一时间传言四起。
事实上，早在一年前，Twitter 公司的工程师就已经成为了湾区“大规模集群管理小组（ CMWS， Cluster Mgmt at Web Scale）”里的重要成员和分享常客。CMWS 是一个专门针对大规模场景下的集群管理问题而成立的闭门组织，其创始成员包括了阿里巴巴、Pinterest、Linkedin、Netflix、Google、Uber、Facebook、Apple 等一大批全球顶级技术公司。该小组成员会在每个月举行闭门 Meetup，围绕具体的议题进行深度技术分享和交流，推动小组成员更快更好的在互联网场景中落地 Kubernetes 技术体系。众所周知，出于规模和性能的考虑，湾区的互联网公司一直以来都是 Mesos 项目的重度用户，而此次 Twitter 的转变，实际上只是 CMWS 小组成员中的一位而已。
尽管一路高歌猛进，但其实哪怕在 2019 年，还是有很多人对“云原生”充满了疑惑甚至误解。这想必也是为何，我们一直能够在不同的场合听到关于云原生的各种不同的定义。有人说，云原生就是 Kubernetes 和容器；也有人说，云原生就是“弹性可扩展”；还有人说，云原生就是 Serverless；而后来，有人干脆做出判断：云原生本身就是“哈姆雷特”，每个人的理解都是不一样的。
实际上，自从这个关键词被 CNCF 和 Kubernetes 技术生态“借用”之初，云原生的意义和内涵，就是非常确定的。在这个生态当中，云原生的本质是一系列最佳实践的结合；更详细的说，云原生为实践者指定了一条低心智负担的、能够以可扩展、可复制的方式最大化地利用云的能力、发挥云的价值的最佳路径。
所以说，云原生并不指代某个开源项目或者某种技术，它是一套指导软件与基础设施架构设计的思想。这里关键之处在于，基于这套思想构建出来的应用和应用基础设施，将天然能够与“云”天然地集成在一起，将“云”的最大能力和价值发挥出来。
这种思想，以一言以蔽之，就是“以应用为中心”。
正是因为以应用为中心，云原生技术体系才会无限强调让基础设施能更好的配合应用、以更高效方式为应用“输送”基础设施能力，而不是反其道而行之。而相应的， Kubernetes 、Docker、Operator 等在云原生生态中起到了关键作用的开源项目，就是让这种思想落地的技术手段。
以应用为中心，是指导整个云原生生态和 Kubernetes 项目蓬勃发展至今的重要主线。
带着这样一条主线，我们回过头来重新审视 2019 年云原生生态的技术演进，会稍微清晰一些。
大家可能听说过，在这次以 Kubernetes 为代表的基础设施领域的演进过程中，总是伴随着一个重要的关键词，那就是应用基础设施能力的“下沉”。
在过去，我们编写一个应用所需要的基础设施能力，比如，数据库、分布式锁、服务注册 / 发现、消息服务等等，往往是通过引入一个中间件库来解决的。这个库，其实就是专门的中间件团队为你编写的服务接入代码，使得你可以在不需要深入了解具体基础设施能力细节的前提下，以最小的代价学习和使用这些基础设施能力。这其实是一种朴素的“关注点分离”的思想。不过更确切的说，中间件体系的出现，并不单单是要让“专业的人做专业的事”，而更多是因为在过去，基础设施的能力既不强大、也不标准。这就意味着，假如没有中间件来把这些的基础设施细节给屏蔽掉、把接入方式统一掉，业务研发就必须“被迫营业”，去学习无数晦涩的基础设施 API 和调用方法，对于“生产力就是一切”的研发同学来说，这显然是不可接受的。
不过，基础设施本身的演进过程，实际上也伴随着云计算和开源社区的迅速崛起。时至今日，以云为中心、以开源社区为依托的现代基础设施体系，已经彻底的打破了原先企业级基础设施能力良莠不齐、或者只能由全世界几家巨头提供的情况。
这个变化，正是云原生技术改变传统应用中间件格局的开始。更确切的说，原先通过应用中间件提供和封装的各种基础设施能力，现在全都被 Kubernetes 项目从应用层“拽”到了基础设施层也就是 Kubernetes 本身当中。而值得注意的是，Kubernetes 本身其实也不是这些能力的直接提供者， Kubernetes 项目扮演的角色，是通过声明式 API 和控制器模式把更底层的基础设施能力对用户“暴露”出去。这些能力，或者来自于“云”（比如 PolarDB 数据库服务）；或者来自于生态开源项目（比如 Prometheus 和 CoreDNS）。
这也是为什么 CNCF 能够基于 Kubernetes 这样一个种子迅速构建起来一个数百个开源项目组成的庞大生态的根本原因：Kubernetes 从来就不是一个简单的平台或者资源管理项目，它是一个分量十足的“接入层”，是云原生时代真正意义上的“操作系统”。
可是，为什么只有 Kubernetes 能做到这一点呢？
这是因为， Kubernetes 是第一个真正尝试以“应用为中心“的基础设施开源项目。
以应用为中心，使得 Kubernetes 从第一天开始，就把声明式 API 、而不是调度和资源管理作为自己的立身之本。声明式 API 最大的价值在于“把简单留给用户，把复杂留给自己”。通过声明式 API，Kubernetes 的使用者永远都只需要关心和声明应用的终态，而不是底层基础设施比如云盘或者 Nginx 的配置方法和实现细节。注意，这里应用的“终态”，不仅仅包括应用本身的运行终态，还包括了应用所需要的所有底层基础设施能力比如路由策略、访问策略、存储需求等所有应用依赖的终态。
这，正是以“应用为中心”的切实体现。
所以说，Kubernetes 并没有让中间件消失，而是把自己变成了一种“声明式的”、“语言无关的”中间件， 这正是应用基础设施能力“下沉”的真实含义。
应用基础设施能力“下沉”，实际上伴随着整个云原生技术体系和 Kubernetes 项目的发展始终。比如， Kubernetes 最早提供的应用副本管理、服务发现和分布式协同能力，其实就是把构建分布式应用最迫切的几个需求，通过 Replication Controller，kube-proxy 体系和 etcd “下沉”到了基础设施当中。而 Service Mesh ，其实就更进一步，把传统中间件里至关重要的“服务与服务间流量治理”部分也“下沉”了下来。当然，这也就意味着 Service Mesh 实际上并不一定依赖于 Sidecar ：只要能无感知的拦截下来服务与服务之间的流量即可（比如 API Gateway 和 lookaside 模式）。
随着底层基础设施能力的日趋完善和强大，越来越多的能力都会被以各种各样的方式“下沉”下来。而在这个过程中，CRD + Operator 的出现，更是起到了关键的推进作用。 CRD + Operator，实际上把 Kubernetes 声明式 API 驱动对外暴露了出来，从而使得任何一个基础设施“能力”的开发者，都可以轻松的把这个“能力”植入到 Kubernetes 当中。当然，这也就体现了 Operator 和自定义 Controller 的本质区别：Operator 是一种特殊的自定义 Controller，它的编写者，一定是某个“能力”对应的领域专家比如 TiDB 的开发人员，而不是 K8s 专家。 遗憾的是当前的 Operator Framework 的发展并没有体现出这个深层含义：太多的 K8s Controller 细节被暴露给了 Operator 的开发者，这是不对的。
在 2019 年，Service Mesh 生态取得了长足的进步，并且从原本 Istio 的绝对统治地位，来到了更接近于“诸侯争鸣”的局面。毕竟，“中间件”这个生态，在过去也很难出现完全一家独大的状态，而 Google “一如既往”的宣布 Istio 项目暂时不捐赠给任何一个开源社区，其实也只是给这个趋势增加一个推波助澜的作用而已。其实，作为这波 Service Mesh 浪潮中应用基础设施能力“下沉”的集大成者，Istio 项目已经在跟 Kubernetes 项目本身产生越来越多的“局部冲突”（比如跟 kube-proxy 体系的关系）。在未来，具体某种“声明式中间件”的能力是 Kubernetes Core 还是 Mesh 插件来提供，可能会有更多的争论出现，而在这个过程中，我们也会看到 Istio 更多的“侵入”到 Kubernetes 的网络甚至容器运行时层面当中，这将使得基础设施变得越来越复杂、越来越“黑科技”化。
所以一个不争的事实是，Kubernetes 项目的其实会越来越复杂、而不是越来越简单。
更确切地说，“声明式基础设施”的基础，就是让越来越多的“复杂”下沉到基础设施里，无论是插件化、接口化的 Kubernetes “民主化”的努力，还是 容器设计模式，或者 Mesh 体系，这些所有让人兴奋的技术演进，最终的结果都是让 Kubernetes 本身变得越来越复杂。而声明式 API 的好处就在于，它能够在基础设施本身的复杂度以指数级攀升的同时，至少保证使用者的交互界面复杂度仍然以线性程度上升。否则的话，如今的 Kubernetes 恐怕早就已经重蹈了 OpenStack 的灾难而被人抛弃。
“复杂”，是任何一个基础设施项目天生的特质而不是缺点。今天的 Linux Kernel 一定比 1991 年的第一版复杂不止几个数量级；今天的 Linux Kernel 开发人员也一定没办法像十年前那样对每一个 Module 都了如指掌。这是基础设施项目演进的必然结果。
但是，基础设施本身的复杂度，并不意味着基础设施的所有使用者都应该承担所有这些复杂度本身。 这就好比我们每一个人其实都在“使用” Linux Kernel，但我们并不会抱怨“Linux Kernel 实在是太复杂了”：很多时候，我们甚至并不知道 Linux Kernel 的存在。
为了更好的说明 Kubernetes 的“复杂性”问题，我们需要先阐述一下当前的 Kubernetes 体系覆盖的三类技术群体：
基础设施工程师： 在公司里，他们往往称作“Kubernetes 团队”或者“容器团队”。他们负责部署、维护 Kubernetes 及容器项目、进行二次开发、研发新的功能和插件以暴露更多的基础设施能力。他们是 Kubernetes 与容器领域里的专家，也是这个生态里的中坚力量。
运维工程师（含运维研发和 SRE）： 他们以及他们开发的工具和流水线（Pipeline），是保障关键业务稳定和正确运行的基石，而 Kubernetes 项目对他们来说，则是供给和研发运维能力的核心基础依赖。理想情况下，运维工程师是 Kubernetes 项目的最重要使用者。
业务研发工程师： 当前的 Kubernetes 项目用户中，业务研发的比重很小。他们本身对基础设施并不感冒，但是也有可能被 Kubernetes 的“声明式中间件”的能力被吸引，逐步接受了依赖 Kubernetes 提供的基础设施原语来编写和部署应用。
上述三种使用群体在不同的公司内可能会有重合，而 Kubernetes 与生俱来的“复杂”，却对上述三种使用者都有着深远的影响。在 2019 年，云原生生态也正在从上述三个角度出发，试图解决 Kubernetes 复杂度对不同使用者带来的问题。
自然的，Kubernetes 生态首先希望解决的是基础设施工程师面对的复杂度。在这里声明式 API 其实已经帮了很大的忙，但是部署和运维 Kubernetes 本身还是一个挑战。这正是类似 kubeadm 、kops 项目，以及 Kubernetes 托管项目和服务（比如 GKE，ACK，EKS 等）的重要价值点。
另一方面，在帮助基础设施工程师缓解复杂度问题的过程中，有一部分公有云提供商逐步发现了这样一个事实：Kubernetes 工程师实际上也不希望关心更底层基础设施比如网络、存储、宿主机的细节和特性。这就好比一个电器工程师，怎么会去关心发电厂里的事情呢？
所以很多公有云提供商先后推出了 Serverless Kubernetes 的服务。这种服务保留了 Kubernetes 的 Control Plane，但是把 Kubernetes 中的 kubelet 组件、以及相应的网络、存储等诸多 IaaS 相关概念去掉，然后用 Virtual Kubelet 项目把 Kubernetes Control Plane 直接对接到一个叫做 Serverless Container 的服务上来直接接入 IaaS 的能力。所谓 Serverless Container，实际上就是把虚拟机以及相应的网络存储等依赖，通过一个容器 API 暴露出来，比如 Microsoft 的 ACI，AWS 的 Fargate 以及阿里云的 ECI。由于从用户视角来看，他看到的效果是 Kubernetes 里面的 Node 被去掉了，所以这种服务方式又被称作“Nodeless”。
Nodeless 从 Kubernetes 中移除最让人头疼的节点和资源管理部分，所以它在使用上非常简单，底层资源的问题也完全不必用户操心，可谓省心省力无限弹性；而相应的折衷是 kubelet 的缺失会为 Kubernetes 的功能完整性打上折扣。
在 2019 年底，AWS 在 Re:Intent 大会上宣布的 EKS on Fargate 服务之后，迅速在业界引起了巨大的反响。EKS on Fargate 去掉底层基础设施细节的思路跟 Serverless Kubernetes 是类似的，但差异点在于它并没有使用 Virtual Kubelet 来直接去掉 Node 的概念，而是通过 Fargate 服务申请 EC2 虚拟机并在里面安装 kubelet 使之成为 Node，然后确保一个 Node 里永远只运行一个 Pod（即：Node : Pod = 1:1）。在这个架构里，kubelet 的存在为更好的保留 Kubernetes 功能完整度打下了基础。对于这种保留了 Node 的 Serverless Kubernetes 设计，我们可以称作 Serverless Infrastructure。
在 2019 年中旬，阿里就已经在 Kubernetes 社区提出了 Virtual Cluster 架构。它的核心思想是，在一个“基础 Kubernetes 集群（元集群）”上，可以为每个租户“虚拟出”一个独立的该租户专属的 Kubernetes 集群，这个集群由独立的 Control Plane 和若干个虚拟的租户 Node 组成。可以看到，这个思路跟 EKS on Fargate 的设计不谋而合但走的更远：Fargate 目前需要将同一个租户的 Node 与 Pod 1：1 来配置以保证租户之间的隔离性，而 Virtual Cluster 则已经做到了租户 Node 与 Pod 的 1：N 配置，并且在元集群中通过 KataContainers 实现不同租户共享同一个宿主机的目的。不过，我们猜测 EKS on Fargate 最终也会通过 Firecracker 逐步走向 Virtual Cluster 架构。与 Virtual Cluster 类似的另一个商业产品，就是 VMware 的 Project Pacific：它通过“魔改” kubelet，在 vSphere 之上实现了“虚拟出” 租户 Kubernetes 集群的目的。
作为开源界的 EKS on Farge 和 Project Pacific，Virtual Cluster 目前是 Kubernetes 上游 多租工作组 的核心孵化项目并且已经进行过多次 PoC，非常值得关注。
从 Nodeless 到 Virtual Cluster，2019 年的云原生生态正在全力以赴的解决基础设施工程师的烦恼。不过，更加重要的运维工程师和业务研发所面临的问题，却似乎一直被忽视至今。要知道，他们其实才是抱怨“Kubernetes 复杂”的主要群体。
这里的本质问题在于，Kubernetes 项目的定位是“The Platform for Platform”，所以它的核心功能原语服务的对象是基础设施工程师，而不是运维和研发；它的声明式 API 设计、CRD Operator 体系，也是为了方便基础设施工程师接入和构建新基础设施能力而设计的。这就导致作为这些能力的使用者和终端受益者，运维工程师和业务研发实际上跟 Kubernetes 核心定位之间存在着明显的错位；而现有的运维体系和系统，跟 Kubernetes 体系之间也存在着巨大的鸿沟。
为了解决这个问题，很多公司和组织落地 Kubernetes 的时候实际上采用了“ PaaS 化”的思路，即：在 Kubernetes 之上再构建一个 PaaS 系统，通过 PaaS API（或者 UI）把 Kubernetes 跟业务运维和业务研发隔离开来。这样做的好处在于，Kubernetes 的基础设施能力真的就变成了“基础设施”：业务运维和研发真正学习和使用的是这个 PaaS，Kubernetes 的“复杂性”问题也迎刃而解了。
但这种做法从本质上来说，其实跟 Kubernetes “以应用为中心”的设计是不一致的。Kubernetes 一旦退化成了“类 IaaS 基础设施”，它的声明式 API、容器设计模式、控制器模型就根本无法发挥出原本的实力，也很难接入到更广泛的生态。在 Kubernetes 的世界里，传统 PaaS 提供的各项能力比如 CI/CD、应用打包托管、发布扩容，现在都可以通过一个个的 CRD Controller 的方式作为插件部署在 Kubernetes 当中，这跟应用基础设施“下沉”的过程其实是类似的。当然，在这个过程中，这些插件就成了如何将 Kubernetes 与现有的运维体系进行对接和融合的关键所在。 比如：如何做应用原地升级、固定 IP，如何避免 Pod 被随意驱逐，如何按照公司运维规范统一管理和发布 Sidecar 容器等等。在 2019 年 KubeCon 上海，自定义工作负载开源项目 OpenKruise 的发布，其实正是 Kubernetes 与现有运维体系成功对接的典型案例。一句话：在现代云原生技术体系当中，“运维能力”可以直接通过声明式 API 和控制器模型成为 Kubernetes 基础设施的一部分。所以在大多数情况下，其实并不需要一个运维 PaaS 的存在。
但是，即使做到了“运维能力”云原生化这一点，“以应用为中心”的基础设施其实也才刚刚起步。
跟传统中间件从业务研发视角出发不同，云原生乃至整个应用基础设施“下沉”的革命，是从底向上开始的。它起始于 Google Borg/Omega 这样比“云计算”还要底层的容器基础设施构建理念，然后逐层向上透出“以应用为中心”的设计思想。出于基础设施本身与生俱来的高门槛和声明式应用管理理论被接纳的速度，直到 2019 年，社区对 Kubernetes 体系的认识其实才刚刚从“类 IaaS 基础设施”、“资源管理与调度”，堪堪上升到“以应用为中心的运维能力”的维度上来。
当然，这次“以应用为中心”的技术革命，一定不会在“运维”这个节点就戛然而止。那么接下来呢？
实际上，声明式 API 和控制器化，是将底层基础设施能力和运维能力接入 Kubernetes 的手段但并非目的。Kubernetes 打造“以应用为中心”的基础设施真正希望达成的目标，是让”应用“变成基础设施中的绝对主角，让基础设施围绕“应用”构建和发挥作用，而不是反之。
具体来说，在下一代“以应用为中心”的基础设施当中，业务研发通过声明式 API 定义的不再是具体的运维配置（比如：副本数是 10 个），而是“我的应用期望的最大延时是 100 ms”。接下来的事情，就全部会交给 Kubernetes 这样的应用基础设施来保证实际状态与期望状态的一致，这其中，副本数的设置只是后续所有自动化操作中的一个环节。只有让 Kubernetes 允许研发通过他自己的视角来定义应用，而不是定义 Kubernetes API 对象，才能从根本上的解决 Kubernetes 的使用者“错位”带来的各种问题。
而对于业务运维来说，下一代“以应用为中心”的基础设施，必须能够从 应用的视角对运维能力进行封装和再发现，而不是直接让运维人员去学习和操作各种底层基础设施插件。 举个例子，对于 kube-ovn 这样一个 Kubernetes 网络插件来说，运维人员拿到的不再是 kube-ovn 本身的使用文档或者 CRD，而是这个插件能够提供的一系列运维能力的声明式描述，比如：“动态 QoS 配置 CRD”、“子网隔离配置 CRD”。然后，运维人员只需要通过这些声明式 API ，为某个应用绑定它所需要的动态 QoS 和子网隔离的具体策略值即可。剩下的所有事情就全交给 Kubernetes 了。
这样，在底层基础设施层逐渐 Serverless 化、运维能力也越来越多的接入到 Kubernetes 体系当中之后，云原生的下一站将会继续朝着“把以应用为中心进行到底”的方向不断迈进。
在 2019 年 4 月，Google Cloud 发布了 Cloud Run 服务，第一次把 Serverless Application 的概念呈现给大众。2019 年 9 月，CNCF 宣布成立应用交付领域小组，宣布将“应用交付”作为云原生生态的第一等公民。2019 年 10 月，Microsoft 发布了基于 Sidecar 的应用中间件项目 Dapr ，把“面向 localhost 编程”变成了现实。而在 2019 年 10 月，阿里巴巴则联合 Microsoft 共同发布了 Open Application Mode（OAM）项目，第一次对“以应用为中心”的基础设施和构建规范进行了完整的阐述。在 2019 年，我们已经能够切实感受到一场新的云计算革命正在兴起。在这场革命的终态，任何一个符合“以应用为中心“规范的软件，将能够从研发而不是基础设施的视角 自描述 出自己的所有属性，以及自己运行所需要所有的运维能力和外部依赖。这样的应用才能做到天生就是 Serverless Application： 它可以被“自动匹配”到任何一个满足需求的“以应用为中心”的运行平台上去运行，我们不再需要关心任何基础设施层面的细节和差异性。
2019 年，在 Kubernetes 技术体系的规模性问题逐渐解决之后，整个云原生生态正在积极的思考和探索如何达成云原生技术理念“以应用为中心”的最终愿景。而从 Serverless Infrastructure 到 Serverless Application，我们已经看到云原生技术栈正在迅速朝“应用”为中心聚拢和收敛。我们相信在不久的未来，一个应用要在世界上任何一个地方运行起来，唯一要做的，就是声明“我是什么”，“我要什么”。在这个时候，所有的基础设施概念包括 Kubernetes、Istio、Knative 都会“消失不见”：就跟 Linux Kernel 一样。
我们拭目以待。
点个在看少个 bug 👇
相关内容
微信扫码咨询专知VIP会员