在 2020 年没有人再会去质疑一个平台团队采纳 Kubernetes 作为自己的基础设施的合理性。事实上2020 年的 Kubernetes 项目已经非常接近于地完成了它最重要的使命即为云计算基础设施带来一层可以让平台团队基于此构造“一切”的平台层抽象。我们已经能够看到今天的云原生社区已经开始广泛认可 Kubernetes 项目作为“The platform for platform”的定位与价值越来越多的平台团队正在基于 Kubernetes 构建各种各样的上层平台比如 PaaS / Serverless / AI Platform / Database PaaS 等等。面向终态的声明式 API 与其背后“辛勤”工作的控制器为“构建基础设施层抽象”这个充满了挑战的技术难题提供了一个能够在复杂度与可用性之间取得平衡的解决方案。正是基于此Kubernetes 项目才拥有了庞大的集成生态让这个“企业基础设施的标准抽象”逐步成为了业界公认的事实。而更为重要的是Kubernetes 真正的成功之处在于它真正押注的是构建抽象的方法而非这些抽象本身。在绝大多数情况下企业基于 Kubernetes 构建上层平台都会引入各种各样其他的抽象作为补充甚至取代或者隐藏掉 Kubernetes 的部分内置抽象阿里巴巴开源的 CloneSet、腾讯的 GameStatefulSet 实践等扩展型工作负载等都是这个趋势的最好的案例。伴随着 Kubernetes 生态从底层到应用层能力的逐步完善在 2020 年更多大型互联网终端企业开始加入到了云原生的梯队当中。我们看到原本的 Mesos 生态标杆 Apple 公司成为了 KubeCon 2020 北美上的绝对主角而金融巨头 MasterCard 则分享了他们基于 OAM、Kubernetes 和 Crossplane 项目构建跨云、跨运行时应用交付平台的内部落地案例。而尤为值得一提的是这些以往在底层基础技术上给人以”保守“印象的大型非云企业在 2020 年纷纷祭出了对很多新兴技术比如 Virtual Cluster 和标准应用模型技术上的落地与思考。云原生浪潮对整个技术产业带来的深远影响可见一斑。此外我们也不难观察到Kubernetes 的极大普及以及基于它兴起的上层生态正在跟安卓Android的发展路径越来越明显的趋同。安卓能够对下以一套统一的方式抽象与集成不同的手机、电视、甚至汽车等硬件设备对上则为程序员暴露出统一的一套开发接口使他们能够以这套统一的抽象去访问或者享受到这些基础设施能力。这种定位与 Kubernetes 非常类似这里唯一的区别在于安卓服务的程序员是 APP 开发者而 Kubernetes 服务的“程序员”则是平台构建者。在这个背景下诸如“Kubernetes 抛弃 Docker”之类的新闻会很容易理解安卓本身就不需要专注于手机的电池是哪个牌子的。这个路径可能也是 Google 比较擅长的一个“打法”全力地去免费推广一个“操作系统”真正获取商业价值的方式则是是去“收割”操作系统上层的生态价值而不是操作系统本身。毕竟用户是不会花钱去购买安卓的。所以 Google Cloud 目前正在 All-in 的正是通过 Anthos 这样的 Kubernetes 混合云底座将 Google Cloud 服务交付到在全世界任何一个数据中心上去。正在被打破的云计算“三层架构”长久以来业界对云计算的认知一直围绕着“SaaS PaaS IaaS”这样经典的三层架构模型展开。然而在 2020 年随着云原生技术的极大普及我们却发现这个模型似乎正遭受着挑战。今天的云原生技术起源于 Docker 以及容器这个创新性的技术革命又受益于经典 PaaS 比如 Cloud Foundry持续已久的心智普及最终在开发者与平台构建者的双重关注下以 Kubernetes 生态为载体最终落地。在 2020 年伴随着云原生技术逐步成熟面向用户的应用管理平台的形态也逐渐开始从以 Cloud Foundry/Heroku 为主体的经典 PaaS 形态即企业级 PaaS向轻量级的 App Service 比如 Shipa 和 Kalm 等方向靠拢。不过轻量级 App Service 本质上还是 Heroku 体验在 Kubernetes 底座上的复刻它们在提供出色的开发者使用体验的同时也继承了经典 PaaS 的“封闭”与“不可扩展”这在很多大型企业基于云原生技术栈 “DIY” 属于自己的“PaaS”的诉求下依然会显得力不从心。事实上对于越来越多的平台构建者来说随着云原生技术的日趋落地“PaaS”本身的“解释权”不再属于某一家提供商而更多取决于平台构建者的业务场景和其终端用户的实际需求。此外对于“SaaS”来说云原生带来的容器化软件打包与交付体系和 Kubernetes 底座也已经极大地改变了云端软件的分发与运维方式。所以无论是 PaaS 也好还是 SaaS 也好本质上正在被“云原生”的技术浪潮迅速“压平”在这种背景下传统“水平”划分云计算体系的方法其实已经变得难以自洽。一个典型的例子就是今天你既不能把 Kubernetes 称作是 PaaS也不能把它称作是 IaaS。它是一个独特的基础设施能力接入层与平台层抽象作为平台构建者你可以基于它构建你心目中任何上层平台而至于你把这个上层平台称作是 PaaS / Serverless / FaaS甚至是 SaaS只是进一步抽象的程度和依赖的垂直能力不同而已这里并没有”谁盖在谁头上”这样的划分。下一代云原生平台构建体系的崛起Kubernetes 的成功极大使能了“平台构建者”这个以往被人们遗忘在企业成本中心Cost Center 里的重要角色。事实上Kubernetes 之所以能够取代 Docker 生态成为今天云计算平台上的主角很大程度上是这个群体做出了最终的决定。否则按照 Docker 所触达到的用户群体规模以及其在开发者生态中的被接纳度 Kubernetes 几乎毫无胜算。这一点经常是被大家所忽视的。实际上在企业级平台落地的过程中平台的最终用户比如业务研发与运维虽然是“顾客与上帝”但真正能在这个过程中起到关键作用和具有最终决定权的往往还是业务背后的平台团队和老板们。但与此同时Kubernetes 之上的平台构建生态在今天依然是高度集中的。一个典型的观察就是今天能够基于 Kubernetes 成体系构建出完整上层平台的团队其实集中在一、二线大型互联网公司当中并且其实践往往“仅供参考”鲜有可复制性。进一步的云原生的极大普及似乎并没有真正能够让平台构建者轻松地构建 PaaS 或者其他上层平台。这其实也进一步解释了前面我们观察到的“PaaS 生态“在云原生时代的停滞基于 Kubernetes 构建上层平台包括 PaaS在 2020 年依然是大型公司和高技术水位团队们的专利。这种平台构建生态的高度集中与云原生希望构建的“普惠式”未来显然是不相符的。当然既然技术发展还没有跟上愿景那么云原生社区也就不会停下脚步。事实上平台构建者之所以要基于 Kubernetes 进一步构建上层平台其根本动机无非来自两个诉求更高的抽象维度比如用户希望操作的概念是“应用”和“灰度发布”而不是“容器”和“Pod”。更多的扩展能力比如用户希望的应用灰度发布策略是基于“双 Deployment Istio” 的金丝雀发布而不是 Kubernetes 默认的 Pod 线性滚动升级。这些增强或者扩展能力在 Kubernetes 中一般是以 CRD Controller 的插件方式来实现的。所以说基于 Kubernetes 构建上层平台在今天看起来似乎杂乱无章、没什么规律但本质上都不会离开“抽象 插件能力管理”这两个核心诉求。再举个例子今天大家为 Kubernetes 构建的各种 Dashboard其实就是一种“抽象”的实现方式这些 Dashboard 本质上是在 Kubernetes API 对象的基础上暴露出了一组允许用户填写的字段从而实现了“简化用户使用心智、提升用户体验”的目的 —— 这当然也是所有“抽象”的根本目标。基于对“抽象 插件能力管理”这两个诉求的持续实践与思考云原生社区在 2020 年诞生了像 KubeVela 这样专注于使能平台团队构建上层平台的开源项目。这个项目的定位在整个云原生生态中是非常独特的它并不是某种垂直能力更像是一套基于 Kubernetes 构建上层平台的“工具”组合比如基于模板的抽象机制以及基于此生成能力使用文档和 OpenAPI Schema 的自动化流程从而帮助平台团队快速构建 Dashboard 或者 Appfile。基于 OAM 模型的插件式能力注册、管理与发现机制以此来模块化、自动化的管理插件能力甚至提前预警插件能力之间的冲突等。无独有偶在阿里云开源 KubeVela 项目后不久云计算领头羊 AWS 在 Re:Invent 2020 上也高调宣布了AWS Proton 商业产品的正式诞生其思想同 KubeVela 项目非常类似只不过构建平台的底座换成了 AWS 云平台定义抽象的模板使用了 AWS 自己的 Cloud Formation (KubeVela 目前支持的是 Google 开源的 CUELang 模板语言。可以预见在云原生与 Kubernetes 项目极大程度地统一与标准化了基础设施层抽象之后如何进一步帮助平台团队在此之上快速、轻松、可复制地构建上层平台正在成为业界开始积极思考的一条关键路径。再一次的你很难在传统的云计算“三层架构”中找到适合这些产品的位置无论是 KubeVela 还是 AWS Proton它们既不是 PaaS也不是 IaaS更不是 Kubernetes 的竞争者它们是云原生背景下新一代平台构建体系逐步崛起的萌芽。探索云原生的下一站2020 年的云原生可以说是整个云计算生态中发展最迅速的一条主线脉络而也正是伴随着这样的发展劲头云原生在新的一年里已经要开始思考它的下一步发展空间。事实上我们已经能够看到各种各样的厂商和团队在不同的领域积极发力和探索。1. 本地开发与测试使能开发者面向 Kubernetes 进行本地开发和测试正在开始成为一个备受关注的话题在这个领域中来自纽约的 Tilt 项目是其中的佼佼者。阿里云和腾讯云也分别有这个话题下的不同维度的解决方案比如 KT Connet 和 Nocalhost。2. 云原生“中间件”的技术变革Sidecar 模式正在以更加迅猛的势头将中间件领域的能力下沉至 Kubernetes 这个新一代的应用基础设施当中除了已经如火如荼的 Istio 对流量治理领域的颠覆微软已经不甘示弱的开源了 Open Service Mesh 作为回应。而与此同时 OAM 在微软的姊妹项目 Dapr 则直接拉齐了 Kubernetes 与中间件在“服务发现与绑定”侧的距离老牌项目 Dubbo 亦宣布了下一代云原生中间件的技术蓝图。当然 所有这一切背后的用户动机是非常清晰的云原生时代的中间件要语言无关要平台无关。3. “边缘”与 Kubernetes 发行版Kubernetes 的“安卓化”趋势少不了将 Kubernetes 部署到全世界任何一个数据中心去的“雄心壮志”这里当然也包括“边缘”设备。除了华为的拳头产品 KubeEdge 之外阿里云的 OpenYurt 项目在 2020 年也进入了 CNCF 沙箱孵化而腾讯云则提出了 SuperEdge 紧随其后。与此同时AWS 在 2020 年重磅开源了其 EKS 服务背后的 Kubernetes 发行版 EKS-D这里当然隐含了对 Google Cloud 的 Anthos 和微软云的 Arc 布局的强势回应。可以预见云厂商们对“将 Kubernetes 部署到任何一个角落”的这份执著会让 Kubernetes “安卓化”比想象中来得更快也少不了在 ISV 和服务集成商侧的一番“腥风血雨”。4. 云原生应用管理与 GitOps云原生应用管理与交付已然正在成为 Kubernetes 这个“新安卓”之上重要的价值聚焦点。在这个领域阿里云联合微软的 OAM OpenKruise 组合已经崭露头角与此同时社区上也出现了 KubeVela 这样进一步使能平台构建者的开源框架开发者工具领域的佼佼者 Hashicorp更是不失时机的发布了 Waypoint 这样的跨平台开发者界面工具。而伴随着 Kubernetes 之上的应用层技术快速演进的同时基于 Git 作为应用配置管理中心交付应用的理念即GitOps则正在迅速取代传统 CI/CD 中的 CD 环节成为 Kubernetes 上应用分发的不二之选。在 2020 年末CNCF 应用交付领域小组正式宣布了 GitOps Working Group 的组建很有可能会将 GitOps 逐步推向云原生 CD 的事实标准。在 Kubernetes “安卓化”势不可挡的今天我们对这个领域在新的一年即将出现的更多颠覆与创新充满期待。2020 年没有“确切定义”的云原生“云原生”到底是什么它就是容器和 Kubernetes 吗虚拟机是云原生的吗……这些“灵魂拷问”一直是很多初次接触云原生理念的公司和团队常常提出的困惑。实际上作为一套“以利用云计算技术为用户降本增效”的最佳实践与方法论云原生这个术语自诞生到壮大再到今天的极大普及都处于一个不断的自我演进与革新的过程当中。这种“永远没有确切定义”的持续生命力才是“云原生”之所以对云计算生态充满吸引力的源泉。
)
