Kubernetes 正变得“无聊”，云原生是云计算领域的开源运动

作者丨赵钰莹

云原生是现在的热门技术趋势，很多开发者都对由此而兴起的一众技术十分追捧，但推及到落地实践环节，大部分企业还都处于探索阶段。云原生发展到现在已经不是普及的问题，而是落地的问题了。本文，InfoQ 有幸采访到了灵雀云 CTO 陈恺，听他分享对云原生各项技术发展现状和趋势的想法。

1 云原生不是普及问题，更多是落地问题

单就某一种技术的概念普及来说，可能并没有什么难点。在科技发展的过往数十年中，技术本身历经了数次更迭，开发者对新兴技术的接受度还是比较高的。随着 CNCF 社区的发展，开发者对于云原生这一概念基本达成了理解和共识，普及并不是非常难的事情，而难点在于落地。

采访中，陈恺表示，不同技术的落地难度也不一样，容器是相对来说比较简单的，对应用进行容器化并运行在 Kubernetes 上就可以了，目前 Kubernetes 的核心部分已经趋于成熟，从去年年底，很多开发者就开始说 Kubernetes 正在变得 boring 。这有几层意思：

第一，核心的技术变更开始变慢，这是向好的迹象，一方面表明技术已经成熟，另一方面定位和边界非常清晰，哪些东西放在核心里面，哪些东西通过扩展去做非常明确；第二，创新仍在持续，但创新会转移到技术栈的更上层；第三，Kubernetes 会变得无处不在，人们会对它习以为常。

Kubernetes 核心社区主要致力于三个主要目标：第一，持续提升核心技术栈的稳定性、易用性、可扩展性；第二，将更多的技术集成到以 Kubernetes 为核心的 “云原生技术栈”；第三，将“云原生技术栈” 扩展到更广泛的应用场景。

此外，CNCF 社区正在将更多的技术集成到 Kubernetes 的生态，越来越多的应用场景和技术会被推到 Kubernetes 中，虚拟机可以用 K8s 管，数据中心里面承载的内容可以用 K8s 管，Serverless 基于 K8s 实现等。

但是，DevOps 和微服务改造都不是那么容易。具体来说，DevOps 涉及文化、组织架构等与人相关的因素。微服务架构改造则涉及重新开发、重构、重写等问题，如果是核心业务改造，风险又会非常大。

陈恺补充道，微服务架构本质上是以运维的复杂度为代价去换取敏捷性，这时候要考虑企业是否真的有敏捷性需求，如果答案是否定的，就不要引入更多的复杂度。如果答案是肯定的，需要引入复杂度，那么如何管理多出来的复杂度，就是我们一直讨论微服务治理的原因。微服务治理不只是 Service Mesh 或者 Spring Cloud，它需要一个完整的基础设施去支撑。

微服务最大的挑战是引入运维的复杂度，所以自动化运维非常重要，尤其是可观测性。在微服务后面需要各种后端数据服务，如何管理后端的数据服务，把这些服务暴露给应用，是要考虑的问题。

最后，聚焦到微服务内部，服务和服务之间的连接和通讯治理，这是狭义上的微服务治理。这个问题的解决方案现在有一个很时髦的名词叫 Service Mesh，微服务治理进入到后 Kubernetes 时代。早期，微服务作为一个需求、一个用例在推动容器和 Kubernetes 的发展，当 Kubernetes 变成标准之后，它会反过来驱动，重新定义微服务治理的最佳实践。

在陈恺看来，如今的云原生已经在业界达成共识：如果基于 Kubernetes 平台做微服务治理，ServiceMesh 就是最佳实践。在数据层面，Envoy 差不多是一个标准，各种选型包括 API 等都会倾向于使用 Envoy，因为其对标准的支持力度最大。在控制层面，虽然还没有形成所谓的标准，但 Istio 也是目前唯一的选择，未来是不是会出现更多方案是值得期待的。总体来说，如果需要调整业务代码和架构，改造过程就会比较困难。因此，陈恺建议对于新技术有必要先想清楚再挑一部分慢慢沉淀，直接大刀阔斧的改革不是很有必要。

2 Serverless 的标准化问题

自从伯克利犀利断言：Serverless 计算将会成为云时代默认的计算范式，并取代 Serverful （传统云）计算模式，因此也就意味着服务器 - 客户端模式的终结，这一技术的发展动态时刻被关注，但在过去一年，这项技术一直没有在标准层面有所突破，这让很多企业和开发者有所顾虑。

Kubernetes 正变得“无聊”，云原生是云计算领域的开源运动

采访中，陈恺表示，目前绝大多数 Serverless 的应用场景都运行在 Lambda 之上。对国内的企业而言，公有云其实本身就是一道槛，在公有云之上使用 Serverless 架构又是另一道槛，因此其落地会比较困难。陈恺表示，目前企业对于 on premise 的 Serverless 架构还是很有兴趣的。

首先，Serverless 从个人开发者角度来看是没有服务器的，从另外一个角度来说肯定是有服务器的，只是公有云厂商在负责服务器，如果转换为私有云，服务器真实可见。

其次，Serverless 的可扩展性规模是从 0 到无限，这是很大的亮点。公有云上可以这么做，私有环境假设只有一台机器，是无法实现这样的可扩展性的，这是相对于公有云的局限性。

最后，就使用场景上而言，私有云相对公有云会有一些弱势，但是目前看来，企业对于私有云场景下使用 Serverless 有很大兴趣，所以社区也好，厂商也好，都对此有投入。

从技术上来说，开发者已经慢慢达成共识：K8s 可以编排容器、虚拟机等一切东西，当然也可以用来编排函数；Docker 本身可以打包应用，当然也可以用来打包函数；K8s 可以作为应用运行时，当然也可以作为容器的运行时。这个逻辑看上去比较合理，所以这些技术最后都会往 K8s 上靠。

FaaS 最佳实践

Serverless 本身的概念比函数计算广很多，函数本身只解决计算问题，数据的问题还是需要通过数据服务来解决，这些服务在公有云上可以很容易的获取，很难说这其中的哪一个是最佳实践，还是需要结合具体用例、使用场景和需求来选择，函数计算也无法满足所有企业的所有场景诉求。

陈恺表示，函数计算本身的好处就是在有事件触发时，可以迅速扩展，对于负载不可预测类应用非常适合，函数计算的付费原则是按需计费，不使用时不会产生任何费用。此外，一些做数据处理的在编程模式上也会比较适合，一些在不同系统中起到连接作用的功能也会比较适合。

3 云原生实践思考：先上云还是云原生？

整个云原生领域的创新仍在持续，这种创新开始转移到技术栈的上层。陈恺表示，我们会慢慢看到从这些技术当中沉淀出一个核心的云原生技术栈，底层是 Kubernetes，中间是 ServiceMesh，往上是 Serverless。Kubernetes 解决的是部署管理的问题。ServiceMesh 解决应用层面、网络连接相关的问题。Severless 把整个运行时都做了虚拟化、抽象。

在云原生时代，很多企业希望借助此技术实现数字化转型，陈恺表示，数字化转型最核心的是应用，最后承载企业价值的就是应用和软件。但是光有软件是不够的，光有软件不见得转型成功，也不见得有什么竞争力，关键的是软件是如何设计、开发并交付的，能不能很快将价值传递出去，这是想通过软件做的事情。在这一点上，云原生是可以发挥作用的，因为云原生讲的就是如何最大化利用其交付模式，并发挥云计算的所有生产力，使得一系列应用从设计到开发、交付，再到管理的思维方式，将最佳实践和技术结合在一起，让应用最快传递价值。

目前，陈恺表示，传统企业对此的接受程度还是挺高的，灵雀云对于头部客户的覆盖非常好，因为大部分 CIO 也都很明白自己的痛点，最终需要软件交付的能力。在过去，很多传统企业可能都没有属于自己的软件产品，甚至企业内部不配备专门的研发人员，大量使用第三方的标准化软件。

如今， 在数字化转型的压力下，企业对 IT 产品有了明确的需求，需要开发、上线、运营自己的产品，对开发模式、迭代速度和频率也与以前的需求完全不一样，因为现在的软件产品已经变成了竞争性的场景，比如车联网、自动驾驶、风控、营销、互联网金融等，如果实力不够很可能导致相应业务的缺失，这就是 Gartner 提到的“以敏态为主的应用”，这类应用的初衷就是做得更好，迭代更快，用户体验更好，才可能带来更多业务，这也是云原生应用最开始落地的场景，这类应用最大的特点是属于新型应用，没有历史包袱。

随着技术不断地深入，很多传统企业都有大量的复杂传统应用，开发模式依旧没有改变，这时就要考虑如何对传统应用进行改造，兼顾两种类型的应用，即敏态和稳态应用。随着时间的演进，企业愿意把这些应用全面云原生化。陈恺表示，此时，企业需要识别哪些应用适合进行云原生改造，哪些不适合，对于适合的应用，也需要考虑改造步骤，如何循序渐进对技术进行选择。

总结来看，云原生应用架构要在企业 IT 环境落地，必须务实。陈恺提到了几大需要遵循的原则：第一，并不是所有应用都需要做微服务的拆分，做微服务化，多种粒度的服务同时并存，是很正常的事情，甚至可以反过来考虑这件事情，默认的、缺省的应该从比较大的粒度开始，当真正有业务层面敏捷性需求时，再按照变更的边界和优先级去逐步做微服务的拆分。

第二，当有敏捷性需求，一定要意识到微服务化之后会带来运维的复杂度，所以做了微服务化一定要拥抱云原生，将微服务应用迁移到 Kubernetes 平台上，甚至在 Kubernetes 平台上应该用 Service Mesh 对它做微服务治理。

第三，API 在整个架构中起到非常重要的作用，一个应用即便不做微服务拆分、不改动技术架构，也可以做一些服务化的适配，把关键能力通过 API 暴露出来。通过 API 来实现内部集成和对外能力开放。

第四，需要做 API 治理，API 治理一般通过 API 网关来实现，但可能不会只有一个 API 网关，可能有多个层级的 API 网关。一般来说，越往上，API 网关的职能越偏向运营，越往下，API 网关的职能越偏向技术。

在具体实践中，关于先上云再做云原生改造，还是直接进行云原生改造，灵雀云接触到的大部分客户基本以私有部署为主，会先从云原生改造开始，上不了公有云的客户也可以很好地使用容器等云原生方面的能力。所有客户上公有云，这会是一条长期且漫长的道路。为了帮助这些企业更好得进行云原生改造，灵雀云今年 6 月底发布了一站式云原生应用赋能平台 Alauda Container platform （ACP）2.0 的重大升级。这次升级是技术架构的重大升级，产品架构完全转成 Kubernetes 原生架构。原来产品所有功能都迁移到新的架构上，同时把 DevOps（Alauda DevOps）平台和 Service Mesh（ASM）在集群和多租户平台上对齐，三个产品融合到 Kubernetes 原生的架构下面。

陈恺表示，在 ACP 的后续版本中，将持续引入更多 Operators，一方面通过 Operators 来实现平台自身的自动化部署、运维和升级。另一方面，让客户便捷地使用一些社区和其他厂商提供的成熟的 Operators。基于 Kubernetes 扩展机制，将运维知识编写成 “面向应用的 Kubernetes 原生控制器”，从而将一个应用的整体状态作为 API 对象通过 Kubernetes 进行自动化管理。灵雀云近期也推出了 API 层面的新产品——企业级 API 管理平台 Alauda API Management platform（AMP），它的定位是企业总的 API 网关，主要负责南北向的 API 治理，更偏运营，主要职责是 API 全生命周期管理、API 能力开放运营（API Economy）、API 治理。

2011 年，Marc Andreessen 说“软件正在吞噬世界”，这句话被无数人反复说起。现在，开源软件变成软件交付的一种主要形式，也可能变成软件标准制定的唯一方式。云计算变成了主流，公有云甚至变成了主流。最近一两年，人们开始讨论云原生。陈恺认为，一定程度上，可以把云原生看作是云计算领域的开源运动。

嘉宾介绍

陈恺，灵雀云创始人兼 CTO。曾任职微软公有云 Azure 云平台核心创始成员及首席研发经理，是大规模计算、企业级云平台和云原生领域全球顶级技术专家。在灵雀云担任 CTO 以来，带领团队打造了基于容器技术、以 DevOps 为理念、面向微服务应用的企业级云原生 PaaS 平台，成功实现了从开源技术到商业价值的转化。由陈恺带领的灵雀云技术团队在开源领域的贡献和产品化成果获得了业内广泛认可，培养出了一大批 K8s、DevOps、Istio 领域的技术人才。

点个在看少个 bug 👇