Knative（无服务器Kubernetes）开局不稳？

笔者真的很喜欢Knative。它是AWSLambda的云原生计算解决方案。这是一个开源社区项目，它将无服务器、云原生应用与Kubernetes集成在一起。它是为了让开发人员能够专注于他们的代码，消除资源调配和管理服务器的繁琐工作。但笔者不太喜欢1.0的Knative。

1.0只是一个版本号，但当看到1.0时，特别是在一个开源项目中，笔者期待的是它已经在生产中使用了多年。笔者期望成熟的代码像以往一样值得信赖，但Knative 1.0并非如此。

相反，正如发布团队所说，“Knative由许多组件组成，这些组件具有不同的成熟度级别，从‘试验性’到‘已GA’。我们仍然希望保持版本同步，因此决定将所有组件移动到版本1.0。GA级别将单独标记。“

在1.0版本中还有试验性的？为什么？

他们解释说，“两个原因：一个面向用户，一个面向贡献者。最大的、面向用户的原因是，当用户了解他们安装了什么以及什么可以一起工作时，它为用户提供了一个可依赖的数字。较小的、面向贡献者的原因是，我们所有的基础设施都设计为管理单个版本号，并将其更新为支持多个版本号似乎不是一个很好的时间利用方式。”

真的吗？笔者对一个平台下的多个版本的程序没有任何意见。至于基础设施被设置为管理单个版本号，笔者不会这么做。

展望未来，他们补充道，“除非我们等待与Knative相关的一切都完成，否则我们总会有一些组件或功能处于alpha或beta状态。虽然这有时发生在组件边界上，但也可能发生在组件内部，因此版本号不能作为“GA”或“否”的唯一指标。”

他们还补充说，该项目“将清楚地了解各种组件或功能的成熟度水平，并将功能沿着走向GA或退役的道路移动。”你知道，在笔者看来，这似乎像是用很多词来描述大多数人使用版本号的事情。

这一切意味着什么？Knative的核心组件，如Serving和Eventing将GA。各种扩展组件，包括serving/eventing功能、net-*插件、通道/代理和源将处于Alpha、Beta或GA状态。要了解每个组件的功能，你需要查看它们的README.md或文档页面。

这听起来仍然让笔者困惑。这对任何人都没有帮助，因为Knative总是让人有点困惑。它从三个独立的部分开始：Serving、Eventing和Build。Knative Build被剥离出来，成为Tekton项目。

今天，Knative提供eventing和serving。正如谷歌软件开发人员Ahmet Alp Balkan所说，“这会造成混乱，可能会影响采用决策，因为项目确实做了两件事，而不是一件。对于试图了解更多关于Knative的开发人员来说，提出问题‘我必须同时使用这个吗？’、‘我可以单独安装它们吗？’，并最终由于感知到复杂性而不使用项目是完全正常的。”

然而，正如Balkan所指出的，“它带来了大量的功能，如基于请求的自动缩放、并发控制、meat屏蔽、具有流量分割能力的可复制部署（修订）、回滚、开箱即用遥测、缩放到零等，这些都是开发人员真正关心的。

除此之外，以下是Knative 1.0带来的内容。它将使你能够在无服务器应用程序中使用事件驱动架构。具体而言，它：

——提供快速、独立、可扩展、安全、无状态的服务。

——具有针对常见应用程序用例的具有更高级别抽象的重点API。

——提供可插拔组件，使你能够携带自己的日志记录和监控、网络和服务网格程序。

——从理论上讲，你可以在任何运行Kubernetes的地方运行。

——支持多个HTTP路由层，包括Istio、Contour、Kourier和Ambassador。

——提供对HTTP/2、gRPC和WebSocket的支持。

——支持GitOps、DockerOps和ManualOps。

——支持许多常见的编程工具和框架，如Django、RubyonRails、Spring等。

展望未来，Knative已经很流行，而且潜力巨大。正如Balkan所观察到的，“Knative服务远不止是一个‘构建块’，我认为它是在Kubernetes上运行微服务所缺少的服务层。”而且，“如果你在Kubernetes上所做的只是运行服务，那么你只需使用Knative Service API就够了，可以在Kubernetes中几乎不涉及任何其他内容。”

原文链接：

https://thenewstack.io/knative-serverless-kubernetes-is-off-to-a-bumpy-start/