使用Helm Charts还是基于Manifests的部署方式需要建议

Question

使用Helm Charts还是基于Manifests的部署方式需要建议

kubernetesbuildmanifestkubernetes-helmkustomize

4

在我当前的工作中，我们运行多个k8s集群并允许多个团队在集群中运行服务。每个服务/git仓库都会有一个kustomize文件，其中包含所有补丁列表。在CD阶段，我们将此kustomize转换为给定环境/区域的k8s清单（服务，configmap，部署），并运行kubectl apply命令在我们的kubernetes中运行。

现在，我们开始使用helm charts，而不是将Kustomize转换为k8s清单，计划生成通用helm chart的values.yaml文件，并使用git sha部署helm发行版。因此，对于这种方法是否有任何建议或建议，从k8s清单迁移到helm chart发布基础的部署是否有任何优势。还有在团队计划执行蓝/绿或金丝雀部署时，helm chart是否有任何优势？

目标是：

1.拥有一种工件 2.回滚计划 3.测试用例以验证yaml，并检查服务是否正常运行。

非常感谢您提供任何相关信息。

- cloudbud

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Ilia Kondrashov · Accepted Answer

Helm 可以为您执行以下多个任务：

模板化 k8s 清单 - 类似于 Kustomize 在您的环境中当前正在执行的操作
处理升级安装- 这包括删除已删除的资源
跟踪您的安装版本- 这样您就可以轻松回滚
允许您将 helm chart 添加到应用程序作为依赖项 - 这样您的应用程序 chart 也将包括 mysql 和 redis 等 - 所有这些都在一个地方进行管理并一起部署
为默认微服务定义图表（具有监视、入口配置等）并使用它跨公司的大多数团队，具有广泛的配置选项
等等

看起来最后一个点与您的需求非常匹配，因为您有来自多个团队的许多应用程序。

我认为，相对于裸的k8s清单，使用可重用的helm chart 是一个很好的下一步。

此外，您可以定义测试以执行验证发布。