kubernetes - Draft和Helm vs Ksonnet？

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

3年前关闭。




Improve this question




据我了解所有这些工具 Draft , Helm和 Ksonnet具有重叠功能，例如创建图表以及部署 kubernetes 配置。

我知道这些工具的目的是描述和配置应用程序以及 k8s 环境。

By using Draft we can create Dockerfile, Chart. Nevertheless we can do same thing with Helm and Ksonnet.

我的问题是，如果这些组件在 CI/CD 中创建管道，那么顺序是什么？

例如，

草稿 -> ksonnet > 掌 Helm
或者

草稿 -> 掌 Helm -> ksonnet

Answer 1

总之，草案和 掌 Helm 或多或少是免费的和 ksonnet 是正交的，专门提供了 的替代方案掌 Helm .

在详细阐述时，我将我的答案分为三个主要部分，第一部分描述了 草案和 掌 Helm 交互，第二个描述如何 ksonnet 与其他人正交，最后一节解释了我如何理解这些关于 CI/CD 的内容。

掌 Helm 和草稿

Helm 和 Draft 是互补的，因为 Helm 可以被认为是 Kubernetes 的包管理系统，它提供了 Draft 提供的部分功能，而 Draft 本身本质上是一个 Kubernetes 应用程序开发工具。

Draft 和 Helm 之间的关系可以总结为指出，为了追求简化 Kubernetes 应用程序开发的目标，Draft 使用从您当前的应用程序类型推断的元数据生成一个 Helm 图表(更多关于下面的内容)，如果一个尚不存在或使用和现有的一个来部署/更新您的应用程序的开发版本，而您无需了解它是如何做到的。

用于 Kubernetes 包管理的 Helm

如前所述，Helm 是一个用于基于 Kubernetes 的应用程序的包管理系统。它提供以下功能:

用于定义 Kubernetes list (称为“图表”)的模板方法

包管理，包括用于托管已发布包的基本包存储库服务。

应用程序生命周期管理，包括 Helm 应用程序的部署、更新和清除

包依赖

Helm 采用模板化的 YAML 方法来参数化 Kubernetes list ，并允许在依赖包之间共享和覆盖值。即，假设包 A 依赖于包 B；包 A 可以重用在包 B 上设置的配置值，并且可以使用自己的值覆盖这些参数。也可以使用 Helm 命令行工具覆盖给定部署中所有包的值。

另外值得一提的是，Helm 依赖于其名为“Tiller”的集群端组件的可用性来实际执行具体化模板并将生成的 Kubernetes list 部署到集群的工作。

Kubernetes 应用程序开发草案

Draft的目的是为了dramatically simplify development of Kubernetes applications通过快速构建和部署 Helm 图表/包和运行项目所需的相应 docker 镜像——前提是存在以下内容:

一个Kubernetes集群

Helm 的 Tiller pod 安装在 Kubernetes 集群中

Docker 注册表

draft installation guide提供有关设置这些部件以自己尝试的详细信息。

Draft 还通过提供高级“打包”格式构建在 Helm 上，该格式包括应用程序 helm 图表和 Dockerfile，后者使其能够构建 docker 镜像。

最后，它内置了对特定编程语言的支持，并会在有限的程度上尝试在最初使用 draft create 创建新的 Draft 项目时推断您使用的编程语言和框架。 .

用于 Kubernetes 包管理的 Ksonnet

如前所述，Ksonnet 在很多方面与 Helm 是正交的，在包管理方面提供了基本相同的特性，这些特性包含在不同的术语中——请参阅其 core concepts documentation .值得注意的是，它与 Draft 不兼容，也没有解决相同的问题。

我说 Ksonnet 和 Helm 是正交的，因为它们采用互不兼容的方法来生成和部署 Kubernetes list 。 Helm 使用模板化的 YAML，而 Ksonnet 使用 "data templating" language called Jsonnet 生成 Kubernetes list 。 .此外，Ksonnet 不像 Helm 那样设想“依赖”包，而是通过将它们表示为可组合的“原型(prototype)”来模糊依赖服务之间的界限。最后，Ksonnet 不依赖于具体化和部署 list 模板的集群端应用程序，而是具有 apply类似于 kubectl apply 的子命令.

持续集成/持续交付

那么这些部分在 CI/CD 工作流程中的哪些方面适合呢？好吧，由于本质上有两个相互不兼容的工具集，让我们逐个考虑它们:

草稿 + Helm

根据 the Draft design Q&A section ，它只是作为一种开发人员工具，旨在从主要希望看到他们的应用程序在开发集群中运行的开发人员那里抽象出处理 kubernetes、helm 和 docker 的大部分复杂性。

考虑到这一点，任何涉及这组工具的 CD 方法都必须执行以下操作:

使用 docker 构建 docker 镜像如有必要，CLI

使用 helm 构建 Helm 包命令行

使用 helm 将 Helm 包部署到 Helm 存储库命令行

使用 helm 在适当的 staging/prod Kubernetes 集群上安装/更新 Helm 包命令行

科索内特

与 helm 相比，Ksonnet CD 工作流程有些简化。上面的工作流程:

使用 docker 构建 docker 镜像如有必要，CLI

使用 ks 应用 Ksonnet list 命令行

而使用 Helm，如果您的 Ksonnet list 包含 re-usable prototypes，您可以将应用程序的包部署到 Helm 注册表以供重复使用。这可能对另一个基于 Ksonnet 的应用程序有用，您希望确保它在 git 存储库中可用，如 Ksonnet registry documentation. 中所述。

这意味着如何在 CI/CD 中处理 Ksonnet 定义在很大程度上取决于您决定将它们存储在哪个 git 存储库中以及它们的结构。