笔者真的很喜欢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/