1 Helm 介绍
其实在我们 K8S 中有一个包管理工具。主要解决了安装服务的问题，其实很好理解对于我们的 K8S 中包管理工具他叫做 helm，helm 可以通过一个仓库去下载我们需要安装服务的一些 yaml文件，因为在 K8S 中所有的资源都是通过 yaml 文件来进行创建的，我们去修改这些 yaml 文件的属性就可以安装出来我想去对应安装的系统/服务信息。
所以说对于我们的 helm 来说它的重要性不次于我们 Linux 操作系统之间的 yum ，接下来我就将这个重要的组件给大家去讲解一下。然后再通过 helm 去安装一些对应的集群化的措施，比如我们在 K8S 中实现我们的监控，实现我们所谓的 ELK 日志的收集展示。
1.1 Helm 是什么
在没使用 helm 之前，如果我们向 K8S 部署应用，我们需要依次部署 Deployment、SVC 等资源，步骤比较繁琐。况且随着很多项目服务化，复杂的应用在容器部署以及管理显得更复杂，helm 通过打包的方式，支持发布的版本管理和控制，很大程度上简化了 Kubernetes 应用的部署和管理。
简单的来说就是一种安装流程，helm 的本质就是让 K8S 的应用管理（deployment、SVC 等）可配置，能动态生成。通过动态生成 K8S 资源清单文件（Deployment.yaml、Service.yaml）等。然后调用 kubectl 自动执行 K8S 资源部署。也就意味着这个所谓的 Yaml 文件他并不是一尘不变的，这种 yaml 文件不想以前创建保存退出他就不会自己更改，但是对于我们的 helm 来说我们可以通过传递类似于环境变量的东西给它进行所谓的修改信息。更能使用到我们的生产环境中，然后调用 kubectl 自动执行 K8S 的资源部署。
1.2 Helm架构
在本节中，我们将简要介绍 Helm 的高级架构。除了对云原生 Kubernetes 应用程序和软件包管理的概念性讨论外
1.2.1 chart
我们已经在本章中讨论了 Helm 软件包。在 Helm 的词汇表中，有一个软件包叫作 chart（航海图）。这个名字是对 Kubernetes（在希腊语中是“船长”的意思）和Helm（舵，船舶的操纵机构）的航海性质的一种诠释。chart 描绘了 Kubernetes 应用程序的安装方式。
chart 是遵循 chart 规范的一组文件和目录，用于描述要安装到 Kubernetes 中的资源。这里将介绍一些高级概念。
- chart 包含一个名为 chart.yaml 的文件，它描述了该 chart，包含有关 chart 版本、chart 名称和说明以及 chart 作者的信息。
- chart 也包含模板。这些也是 Kubernetes 清单，可能用模板指令进行注解。
- chart 也可以包含提供默认配置的 values.yaml 文件。此文件包含安装和升级期间可以覆盖的参数。
- 这些是你将在 Helm chart 中找到的基本文件，不过，当你看到一个 Helm chart 时，它可能是以未打包或打包的形式呈现的。一个未打包的 Helm chart 只是一个目录。
- 在里面，它会有一个 Chart.yaml、一个 values.yaml、一个 templates/ 目录等。
- 打包的 Helm chart 包含与未打包的 Helm chart 相同的信息，但它被 tar 打包并用 gzip 压缩到单个文件中。
- 未打包的 chart 由一个带有 chart 名称的目录表示。例如，名为
mychart的 chart 将被解压到名为mychart/的目录中。 - 相比之下，打包的 chart 有 chart 的名称和版本，以及 tgz 后缀：
mychart-1.2.3.tgz - chart 存储在 chart 存储库中，Helm 知道如何从存储库下载和安装 chart。
1.2.2 资源、安装和发布
为了将本节中介绍的术语联系起来，当某个 Helm chart 被安装到 Kubernetes 中时，会发生以下情况：
- Helm 读取 chart（必要时下载）。
-
它将值发送到模板中，生成 Kubernetes 清单。
-
清单被送到 Kubernetes 。
-
Kubernetes 在集群内创建请求的资源。
当一个 Helm chart 被安装时，Helm 将根据需要生成尽可能多的资源定义。有些 chart 可能创造一个或两个定义，其他的可能创造数百个定义。当 Kubernetes 收到这些定义时，将为它们创建资源。 Helm chart 可能有许多资源定义。Kubernetes 认为每个资源定义都是独立的。但在 Helm 看来，chart 定义的所有资源都是相关的。
例如：我的 WordPress 应用程序可能有一个 Deployment 、一个 ConfigMap 、一个 Service 等。但它们都是一个 chart 的一部分。
安装它们时，它们都是同一个安装的一部分。同一 chart 可以安装多次（每次使用只需不同的名称即可）。因此，我可能拥有相同 chart 的多个安装，就像我可能拥有相同 Kubernetes 资源类型的多个资源一样。
这带来了最后一个术语。一旦安装了 WordPress chart ，我们就拥有了一个该 chart 的安装。然后我们用 helm upgrade 来升级该 chart 。
现在，这个安装有两个版本。每次使用 Helm 修改安装时，都会创建一个新的安装版本。当安装新版本的 WordPress 时，会创建一个版本。但是，当我们仅仅更改安装的配置或者回滚安装时，也会创建一个版本。这是 Helm 的一个重要特征。
1.2.3 关于Helm 2的简要说明
熟悉 Helm 2 的人可能会注意到本文中缺少某些概念：Tiller 或 gRPC 。这些东西已从 Helm 3 中删除，而本文的主题是讲述 Helm 3 。此外，本文着重讲述第2版Helm chart。 因为 Helm chart 版本与 Helm 版本的递增是不一致的。所以 Helm v2 使用 Helm Charts v1 ，Helm v3 使用 Helm Charts v2 。它们在一些重要的方面与第1版的Helm Charts不同，最显著的是在声明依赖项的方式上。Helm 2 和 Helm Charts v1 被认为已弃用。
1.3 结论
本章的内容是其他章节的基础。只有使 Kubernetes 对新用户和长期使用 Helm 的运营团队和 SRE 都更有用，Helm 才能成功。本文的其余部分致力于（用大量的例子）解释如何最大限度地发挥Helm的作用，以及如何安全地、习惯地做到这一点