Helm 2 、Helm 3 比较

Helm 3 移除了 Tiller ，是个不错的决定。但是要理解为什么不错，我们还需要了解一下 Tiiller 产生的背景。Tiller 是 Helm 的服务端组件（运行在 Kubernetes 集群上），主要目的是为了让多个不同的操作者能够在同一个集群上操作。开发 Helm 2 时，由于 Kubernetes 没有基于角色的访问控制（RBAC），Helm 不得不自己控制谁、在哪里能够安装应用。直到 Kubernetes 1.6 中开启了 RBAC ，这件事就变得简单了。Helm 也不必与 Kubernetes 做重复的事情，因此 Helm 3 彻底移除了 Tiller 。

Tiller 作为维护 Helm 应用信息和状态的核心。Helm 3 直接从 Kubernetes API Server 就可以获取到相同的信息，并且在客户端呈现 Charts 。对于 Kubernetes 来说，这种方式更加简单而原生。

移除 Tiller 之后，Helm 的安全模型也变得简单（使用 RBAC 来控制生产环境 Tiller 的权限非常不易于管理）。Helm 3 使用 kubeconfig 鉴权。集群管理员针对应用，可以设置任何所需级别的权限控制，而其他功能保持不变。

2. 好吧，除了 Tiller ，还有什么改变？

正如前面提到的，移除 Tiller 是一件大事，但不是唯一的一件。让我们看看其他的。

2.1 三路合并补丁策略

Helm 2 使用的是两路合并补丁策略。也就是，当你想执行任何 helm 操作时，比较最新的 chart 包与期望的 chart 包配置。这两个包之间的不同，决定了应该调整 Kubernetes 中的哪些资源。听起来不错，对吗？但是没有考虑手动修改应用的情况（例如，使用 kubectl edit）。这将导致应用无法回滚到之前的状态，因为 Helm 2 将最新的 chart 包当做最新的状态，而最新的 chart 包里面没有改变（我们只是更新了应用在集群的状态），Helm 2 忽略了这一变化的回滚。

三路策略合并补丁可以解决这个问题。Helm 3 是如何做的呢？它只是多考虑了应用的线上状态（使用三路替代两路，旧的配置，线上状态，新的配置）。例如，假设你部署了一个应用：

helm install very_important_app ./very_important_app

这个应用的副本数量设置为 3 。现在，如果有人不小心执行了 kubectl edit 或：

kubectl scale -replicas=0 deployment/very_important_app

然后，团队中的某个人发现 very_important_app 莫名其妙宕机了，尝试执行命令：

helm rollback very_important_app

在 Helm 2 中，这个操作将比较旧的配置与新的配置，然后生成一个更新补丁。由于，误操作的人仅修改了应用的线上状态（旧的配置并未更新）。Helm 在回滚时，什么事情也不会做。因为旧的配置与新的配置没有差别（都是 3 个副本）。然后，Helm 不执行回滚，副本数继续保持为 0 。此时，你有些慌了…

另一方面，在 Helm 3 中，将使用旧的配置，线上状态，新的配置生成更新补丁。Helm 发现旧的配置副本数是 3 ，线上状态是 0 ，判断出新的配置期望改回 3 ，因此生成一个更新补丁回滚。此时，你不那么慌了…

使用 Helm 3 进行升级时，也会发生类似的过程。例如，某个基于控制器的应用（或类似服务网格）注入任何内容到 Helm 部署的 Kubernetes 对象中。在 Helm 2 中进行升级时，注入的内容将被移除。在 Helm 3 中，由于考虑到了在线状态，注入的内容将会被保留。假设我们想要在集群上安装 Istio 。Istio 将 Sidecar 注入到每个部署中。使用 Helm 进行部署：

containers:
- name: server
  image: my_app:2.0.0

安装 Istio 之后，你的容器定义看起来像这样：

containers:
- name: server
  image: my_app:2.0.0
- name: istio-sidecar
  image: istio-sidecar-proxy:1.0.0

如果使用 Helm 2 进行升级，你将得到如下结果：

containers:
- name: server
  image: my_app:2.1.0

Istio Sidecar 由于不在配置中，将会被移除。然而，Helm 3 将基于旧的配置、在线状态、新的配置生成一个更新补丁。Helm 3 会将 image 更新为 2.1.0 ，另外在线状态还包含一些额外的配置。最终，使用 Helm 3 升级将得到你想要的：

containers:
- name: server
  image: my_app:2.1.0
- name: istio-sidecar
  image: istio-sidecar-proxy:1.0.0

三路策略合并补丁更新，让 Helm 升级更加可控和安全。

2.2 Secrets 作为默认存储器

Helm 2 使用 ConfigMaps 存储应用的信息。在 Helm 3 中，改为 Secrets （secret 类型为 helm.sh/release ）作为默认存储器。这带来了一些优势，并极大简化了 Helm 的功能。Helm 2 必须要经过一系列操作才能获取（和应用）配置。这些配置加密、打包存储在某一个 keys 或 ConfigMap 中。Helm 3 直接将配置存储在 Secret ，无需执行复杂操作，只需要提取、解码、使用即可。另一个优点是，应用名称不必集群唯一。包含应用信息的 Secrets 存储在应用安装的 Namespace 中。因此，在不同的 Namespace 中，应用可以具有相同的名字。

2.3 JSON Schema 验证 Chart 信息

可以使用 JSON Schema 强制对 chart 中的 values 值进行校验。基于此功能，你能够确保使用者提供的 values 值符合 chart 包的要求。这给 OPS 与 DEV 创造了更多合作机会（OPS 团队能给 DEVs 更大自由度），当用户 values 值设置错误时，能够给出更好的错误提示。

2.4 现在需要应用名字了

如果没有提供应用名，在 Helm 2 中，将会随机生成一个；在 Helm 3 中，将会报错（如果还是想使用随机名称，可以加上 — generate-name 标识）。

2.5 移除了 Helm serve

本来就没有很多人使用 helm serve（用来给开发，在机器上跑一个本地的 Chart Repository）。现在 helm serve 移除了。但是你仍然可以以插件的形式安装。