在没使用 helm 之前，向 kubernetes 部署应用，我们要依次部署 deployment、svc 等，步骤较繁琐。况且随着很多项目微服务化，复杂的应用在容器中部署以及管理显得较为复杂，helm 通过打包的方式，支持发布的版本管理和控制，很大程度上简化了 Kubernetes 应用的部署和管理，就像 Java 使用 maven；node 使用 npm；python 使用 pip；Linux 使用 yum **,Helm 本质就是让 K8s 的应用管理（Deployment,Service 等 ) 可配置，能动态生成。通过动态生成 K8s 资源清单文件（deployment.yaml，service.yaml）。然后调用 Kubectl 自动执行 K8s 资源部署**。,Helm 使用的包格式称为
chart，它是一个描述 Kubernetes 相关资源对象的文件集合。它的技术特点类似 jinja模版，以渲染模版的方式，生成运行一个服务实例所需的一系列资源对象文件，并以此进行服务的发布。通过这种方式，我们也可以十分简单的制作自定义的 chart。,Chart 有自已特定的目录布局，我们以官方提供的
wordpress为例说明，chart 的文件目录结构如下：,Repo,Helm chart 可以被存储在专用的 HTTP 服务器上，称为
chart 仓库（repositories)，和
yum repository类似，chart 仓库提供了一个
index.yaml 来描述一批 chart，并且提供了每个 chart 的下载地址信息。,Helm 客户端可以指向多个 chart 仓库，默认情况下是没有配置仓库的，需要使用
helm repo add 来进行添加。helm3 中对于一些常用服务的下载安装，用
bitnami 仓库 取代了原来的
stable 仓库，但是仍保留了
stable 仓库的使用,Release,当 chart 被发布后，Helm 库会创建一个
release 来跟踪这个发布的对象，它的实质是在 Kubernetes 中运行的各种资源，
service、
deployment、
configmap、
secret 等，在 K8S 集群中的直接的表现就是一个或多个 pod.,Helm 的 release 是允许启动多个不同服务的，且每个服务之间遵循依赖关系，这点就比较类似 docker compose.,1.Helm3新增的功能,Helm3新增了许多新功能，以下几个功能需要特别指出：,2.重要变化概述,1）移除Tiller,
Tiller 在 Helm2 中是一个重要的组成部分。Helm2 使用它和
GRPC 来处理
Helm chart 的安装和管理，呈现
chart 并将其推送到 Kubernetes API Server。
Tiller 允许团队共享一个 Kubernetes 集群，多个 operator 可以使用同一组发行版，团队成员通过它就可以在一个共享的 Kubernetes 集群中管理复杂的应用发布。,但是从 Kubernetes 1.6 开始，考虑到安全性，集群默认会开启角色访问控制（
RBAC），这使得管理和配置Tiller会变得非常复杂，因为可能的安全策略数量太多了。为了简化安全模型实现方式，并使管理员/SRE不需要去深入研究 Kubernetes 的安全组件，helm 提供了一个不需要太过关注安全规则的默认配置，但是这又会使得授权变得宽松，这反而会导致安全隐患。,因此在 Helm3 中干脆移除了 Tiller，而是选择从 Kubernetes API Server 中获取信息来渲染 Charts 客户端，并在 Kubernetes 中存在安装记录，这些过程既没有 Tiller 也可以实现。,Helm3 可以支持所有的 Kubernetes 认证及鉴权等全部安全特性。Helm和本地的 kubeconfig flie 中的配置使用一致的权限。管理员可以按照自己认为合适的粒度来管理用户权限，下图可详细看出helm2到helm3的改变,
,2）Chart仓库升级,在 Helm3 中，
helm search 除了支持本地 repository 搜索外，还支持
helm search hub 搜索 Artifact Hub 中所有公开的 charts。,3）改进升级策略：使用三路策略合并补丁,在 Helm2 中，使用了双路策略合并补丁，简单来说就是在使用
helm upgrade 更新过程中，会比对本次发布的 chart manifest 和 最近一次发布的 chart manifest 的差异，以此来决定哪些更改被应用到 Kubernetes 的资源中去。并且，Helm 只会将最后一次应用的 chart manifest 作为 release 的当前状态，如果 chart 状态没有更改，资源的活动状态就不会更改，也就是说使用诸如
kubectl edit 、
kubectl scale 这种外部方式进行的修改不会被 Helm 识别的，这种情况下如果发生回滚操作，Helm 会由于 chart 并没有发生变化而导致回滚失败。,而在 Helm3 中，这种策略被升级成了三路策略合并，Helm 在生成一个补丁时，也会考虑之前老的 manifest 的活动状态。也就是说，在使用老的 chart manifest 生成新的补丁时，Helm 还会考虑当前的活动状态，并将其与之前老的 manifest 进行比对，并再比对新的 manifest 是否有改动，并进行自动补全，以此来生成最终的更新补丁。,示例说明,用Chart渲染生成的manifest如下,通过非Helm的方式将应用的活动状态修改如下：,而现在我们想要将应用的镜像升级到2.1.0，通过chart进行升级操作,在 Helm2 中，由于不会考虑 chart 之外的修改，而是检测 chart 生成的 manifest 之间的区别，因此修改后的状态如下：,而在 Helm3 中，通过三路合并策略，会检查到除了 chart 的修改外，还多了一个 sidecar 容器，因此会进行补全，最终修改状态如下：,4）release名称存储位置改变,在 Helm2 中，release 的相关信息都被保存在 Tiller 的 namespace下，所以 release 的名称必须是唯一的；而随着 Tiller 组件的移除， Helm3 中release 相关的信息都被保存在了应用自己相对应的 namespace 下，因此根据 namespace 的隔离性质，在不同的 ns 下，release 的名称可以重复。,Helm3 中，在执行
helm list 时需要添加
--all-namespaces 参数才能获取到 Helm2 中同样的结果,5）requirements.yaml合并入 Chart.yaml,动态依赖关系的chart 依赖从
requirements.yaml 和
requirements.lock 移至
Chart.yaml 和
Chart.lock。 推荐在 Helm3 的新 chart 中使用 Chart API v2 的新格式，但是 Helm3 中依然可以识别 v1 版本，并且会自动加载已有的
requirements.yaml 文件。,在 Helm2 中，
requirements.yaml 的表达式类似如下形式：,而在 Helm3 中，表达式的形式并没有变化，但是现在需要写在
Chart.yaml 中。Chart 依然会下载和放置在
charts/ 目录，所以
charts/ 目录中的子 chart 不需要做任何修改，可以沿用 Helm2 的。,6）CLI命令重命名,7）简化模板对象 .Capabilities,
Capabilities 是 Helm 模版可以访问的内置对象之一，其提供了关于 Kubernetes 集群支持的功能的信息，包含以下内容：,1、版本形式,Helm 的版本用
x.y.z 的形式描述，
x 是主版本，
y 是次版本，
z 是补丁版本。当一个 Helm 的新版本发布时，都是针对 Kubernetes 的一个特定版本编译的，比如
3.0.0 基于 Kubernetes 的
1.16.2 的客户端API版本构建，则可以兼容 Kubernetes 1.16。,2、可支持的版本偏差,相较于 Helm2 对于 Kubernetes 次版本变更支持的严格（
n-1），Helm3 可以向下兼容
n-3 的次版本，比如你使用一个针对 Kubernetes 1.18 客户端 API 版本编译的 Helm3 版本，那么它可以支持的 Kubernetes 版本为 1.18、1.17、1.16、1.15 ；,如果你使用一个针对 Kubernetes 1.15 客户端 API 版本编译的 Helm2 版本，那么它可以支持的 Kubernetes 版本为 1.15、1.14。, Helm 没有向上兼容机制，故按照官方推荐安装即可：
