使用 Helm 而不是 Terraform 的困惑

Posted 2023-03-24

【中文标题】使用 Helm 而不是 Terraform 的困惑

【英文标题】：Confusion of using Helm rather than Terraform

【发布时间】：2021-05-12 12:30:23

【问题描述】：

我目前正在从 ECS 迁移到 EKS，我对 Helm 和 Terraform 之间的分歧感到困惑。

我们目前有一个专门用于 EKS 集群的 Terraform/Packer 存储库。

然后我们就有了我们的应用程序的 repo。该应用程序需要 AWS RDS 实例和 SQS/SNS。

我的理解是 Helm 不支持 SQS 或其他服务设置，在这种情况下，我质疑在使用纯 Terraform 在 EKS 中部署所有必需的队列/数据库/应用程序非常容易的情况下，我为什么还要打扰 Helm？似乎通过引入 Helm，我最终所做的只是在 K8/NonK8 应用设置的应用设置中创建了不必要的拆分。

我觉得我错过了 Helm 的意义，但我很难看清它是什么？帮我看看我错过了什么！

【参考方案1】：

Helm 用于在您的 EKS 上安装应用程序。 SQS 和 RDS 不是在容器集群上运行的应用程序，它们是基础架构。 对于那些您可以使用 Terraform、CloudFormation 或 CDK。

您可以在此处找到有关如何使用不同工具的更多示例：https://www.eksworkshop.com/

【讨论】：

您现在实际上可以使用适用于 Kubernetes 的 AWS 控制器在您的 Kubernetes 配置中将您的 AWS 服务定义为自定义资源 :) github.com/aws-controllers-k8s/community（开发者预览版）

我不确定这是否能回答问题。 SQS 设置是应用程序的一个组成部分，并且对于每个部署都是独一无二的。仅仅因为它不存在于 EKS 中，就将这个设置与部署分开对我来说毫无意义。 AWS 控制器的评论更符合正确的路线，但指出它不应该在生产中使用

【参考方案2】：

您可以使用其他工具（例如 Terraform）完成 Helm 所做的任何事情。在我看来，这取决于您的背景。

Helm 是 DevOps 人员用来解决“YAML 地狱”的最初工具之一，因为 Kubernetes、云原生、微服务在生产使用中真正起飞。对于习惯于在 shell、命令行或在 Python 脚本中使用 Jinja 文本模板进行黑客攻击的面向操作的人来说，这很容易上手。

正因为如此，Helm 图表背后有很多惯性，许多云原生产品选择发布 Helm 图表作为一种“快速”的方式来让他们的产品在 Kubernetes 集群上启动和运行。

我个人避免使用 Helm 图表，并且（如果这些图表不是太疯狂的话）选择将它们转换为 Terraform，以便它适合 GitOps/IaC 范式，并且我在基础架构配置和部署方面获得了一致性。我还怀疑从长远来看，从团队发展的角度来看，Helm 图表更难维护。

如果 IaC 不是您的偏好，那么 Helm 将是 kustomize 的“更清洁”解决方案，特别是因为它受 Google 支持，并且此时实际上已内置到 kubectl 二进制文件中。这也是一个用于模板化/生成 Kubernetes 清单的实用程序，但不像 Helm 那样引入或依赖外部状态。

【参考方案3】：

Helm 和 Terraform 有两个不同的用途。通常，您将两者都用于以 CI / CD 为重点的云原生配置。 Helm 让您可以轻松配置旨在在 Kubernetes 集群中运行的服务。使用 Terraform，您可以配置 Kubernetes 集群本身或任何其他旨在在 Kubernetes 集群之外运行的 PaaS 组件（例如数据库或消息代理）。有关详细信息，请参阅devops renaissance 上的此博客。