赫尔姆出了什么问题?为什么它没有被广泛采用并优先用于 k8s 应用程序? [关闭]

2024-04-20

到目前为止,Helm 是我所知道的唯一 K8s 包管理器。它可以帮助无缝部署和管理 k8s 应用程序依赖项。为什么这么多 K8s 应用程序仍然没有采用或优先考虑它?

我用过不少流行的,比如Argo、Istio等。他们似乎提倡默认安装方法$ kubectl apply -f <http path to YAML config>。有些确实支持 Helm 安装方法,但它被进一步推到下面,并且在许多情况下缺乏文档或已经过时。有些甚至不支持 Helm 图表。

人们如何实际配置、部署和管理具有层层依赖关系的大型 K8s 应用程序,就像其他平台中常见的那样?他们实际上手动管理每个依赖项吗?如果是这样的话,技术债务将是巨大的,因为 K8s 管理员需要了解应用程序中每个依赖项的配置逻辑的每个细节。


这个问题有几个方面。

集群安全

从历史上看,第一个是安全。

在 Helm3 之前,Helm 确实依赖于一些在集群中运行的 Tiller 容器,某种集群管理员能够代表您创建资源。

当时,反对 Helm 的主要论点之一是 Tiller,它是任何试图提升其特权的攻击者的特权目标。

从 Helm 3 开始:Tiller 消失了。这个论点不再有效——尽管要注意 Helm 2 并没有消亡,但我仍然时不时地遇到 Tillers pod。

兼容性

Helm Charts 通常无法开箱即用,具体取决于您的集群,并且通常需要一些补丁。

一个常见问题是图表尝试在没有任何 PodSecurityPolicy 或 SecurityContextConstraints 配置的情况下启动特权容器,从而导致容器无法启动。或者更常见的是缺少 Pod 或容器 SecurityContexts,无法通过现有值自定义它们,在未配置云集成且 MetalLB 不可用时,LoadBalancer 服务,...

根据经验,图表往往在没有 RBAC、没有安全性的 Kubernetes 上运行得很好……事情可能会变得“复杂”,具体取决于集群强制执行的选项。

Quality

这引出了另一个常见问题:质量。它有两个方面:所提供的 Kubernetes 配置的质量、它的相关性如何、它如何适合您正在打包的应用程序。以及您所依赖的用于打包该应用程序的容器映像的质量。

最好的情况是,您的图表来自您尝试安装的软件的编辑器。通常,容器镜像构建得相对较好。

但编辑可能没有很多 Kubernetes 专业知识:他们可能缺少资源分配、亲和力/反亲和力/拓扑扩展约束,可能存在一些没有意义的部署策略或滚动参数,经常尝试绑定在特权端口上,当这种情况可以避免时,...有时他们没有太多时间来研究这些主题,而是专注于他们的产品本身。

从历史上看,我可以尝试的第一个图表是由一些 GitHub 用户编写的,与编辑器没有任何关系,并且对他们在编写 Kubernetes 配置和 Dockerfile 时所做的事情有不同的理解。

不管编辑的参与如何,我不会特别责怪任何人,但是有各种各样的容器映像和 Helm Charts,绑定在特权端口上并以 root 身份运行,除了“这就是当你 apt-获取安装”。 chmod 777s。可能不起作用的东西。确实可以,但我会质疑其安全隐患。可以简化的事情,...

Support

评估 Chart 时要考虑的最后一点是其容器镜像和 Kubernetes 配置的维护情况。

您可以在公共 CVS 上找到资源吗?它的活跃程度如何,是否存在任何突出的错误,是否及时修复?如果您的设置中出现任何问题,您是否能够贡献自己的力量?

结论

基于这些方面以及您对集群的要求(这是一个测试、一个应该托管 CI 的开发人员、一个 PCI-DSS 银行的产品……)以及您可以花费的设置时间:您可能信任给定的 Helm Chart,或者更喜欢构建自己的解决方案。

尽管 Helm 架构(在 Helm 3 之前)曾经是主要障碍,但现在不采用 Chart 的理由通常与其质量有关。

我对 Helm 的第一个不满是图像和配置的质量不稳定,有时甚至非常差。这并不是说没有好的或很棒的图表。但这需要您根据具体情况根据您的情况进行评估。

正如评论中指出的:Helm 并不总是最终的答案。您可以使用 Kustomize。 Kustomize 可以依次安装 Helm Charts。或不。您可以应用纯文本文件。您可以考虑 ArgoCD 从 Git 存储库应用配置。 OpenShift 有“模板”(尽管它不允许大量模板:在这方面,Helm 更好)

如果我们要考虑替代方案,这取决于您想做什么。考虑到大多数时候,我会部署多个对象,并且彼此之间存在关系……可以说,执行此操作的“最佳”方法是操作员。您可以使用 Go、Ansible (operator-sdk)、Java、Python (kopf) 等编写您的代码,...有大量可用的库。虽然 Helm/Templates/Kustomize 只会应用一堆配置, 运算符是状态机(在创建 Y 之前等待 X 启动)。


回答你的最后一个问题:人们如何实际配置、部署和管理具有层层依赖关系的大型 K8s 应用程序?

依靠。对此没有明确的答案。

我可以告诉你,我现在合作的客户使用 Terraform,并有一个应用 Ansible Playbooks 的自定义提供程序,从一些模板生成 Kustomization 文件,然后应用纯文本文件,或者有时调用 Artifactories 上托管的 Helm Charts。这些有时会部署 Operators(用 java/go/python 编写),这又会创建自己的对象,...

您可以随心所欲地执行此操作。只要您的安全部门同意(如果您有一个)、可供您的开发人员使用、可由您的操作人员管理,...

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

赫尔姆出了什么问题?为什么它没有被广泛采用并优先用于 k8s 应用程序? [关闭] 的相关文章

随机推荐