Kubeflow 如何在没有 ksonnet 的情况下发展

许多软件项目依赖于作为独立开源项目运行的模块。当其中一个模块失去支持（这是不可避免的）时，主项目周围的社区必须决定如何进行。

这种情况现在正在 Kubeflow 社区中发生。Kubeflow 是一个不断发展的开源平台，用于在 Kubernetes 上开发、编排、部署和运行可扩展且可移植的机器学习工作负载。最近，Kubeflow 组件 ksonnet 的主要支持者宣布，它将 不再支持 该软件。

当一个软件失去支持时，决策过程（和结果）会因软件是开源还是闭源而大相径庭。

手机类比

为了说明当组件失去支持时，开源社区和闭源/单一软件供应商如何处理差异，让我们使用硬件设计的例子。

假设您购买了 A 型号手机，但它停止工作了。当您尝试维修时，您发现制造商已倒闭，不再提供支持。由于手机的设计是专有的和封闭的，因此没有其他制造商可以支持它。

现在，假设您购买了 B 型号手机，它停止工作了，并且其制造商也已倒闭，不再提供支持。但是，B 型号手机的设计是开放的，另一家公司正在营业，制造、维修和升级 B 型号手机。

这说明了使用闭源和开源原则编写的软件之间的一个区别。如果闭源软件解决方案的供应商倒闭，则支持将随供应商一起消失，除非供应商出售软件的设计和知识产权。但是，如果开源解决方案的供应商倒闭，则没有知识产权可出售。根据开源原则，源代码可供任何人根据许可使用和修改，因此另一家供应商可以继续维护该软件。

Kubeflow 如何在没有 ksonnet 的情况下发展

ksonnet 的支持者决定停止开发的后果说明了 Kubeflow 的开放和协作设计过程。Kubeflow 的设计人员有多种选择，例如替换 ksonnet、采用和开发 ksonnet 等。由于 Kubeflow 是一个开源项目，因此所有选项都在 Kubeflow 邮件列表中公开讨论。社区的一些建议包括

• 我们是否应该关注 CNCF/Apache 项目？例如 helm
• 我倾向于回归基础。KISS（保持简单，愚蠢）。使用普通的 jsonnet + kubectl + makefile/脚本怎么样？例如，coreos prometheus operator 就是这样做的。这也将降低入门门槛（无需新工具），并让 k8s 供应商（gke、openshift 等）轻松地在其基础上构建。
• 我投票赞成使用一个简单的、程序化的上下文，无论是手动的 jsonnet + kubectl，还是简单的 Python 脚本 + Python K8s 客户端，或者我们可以基于这些构建的任何工具。

邮件列表的成员正在讨论和辩论 ksonnet 的替代方案，并将达成继续开发的决定。我喜欢开源方式的适应性在于它是社区共同完成的。与通常由一家供应商设计的闭源软件不同，开源项目的成员组织可以协作地将项目引导到他们认为最合适的方向。随着 Kubeflow 的发展，它将受益于开放、协作的决策框架。