Please enable Javascript to view the contents

Helm 2 、Helm 3 比较

 ·  ☕ 4 分钟

Helm 3 终于发布了。我们可以告别 Tiller 了,但 Helm 3 的改变不仅于此。让我们继续探讨其他的变化。

1. 告别 Tiller

Helm 3 移除了 Tiller ,是个不错的决定。但是要理解为什么不错,我们还需要了解一下 Tiller 产生的背景。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 是如何做的呢?它只是多考虑了应用的线上状态(使用三路替代两路,旧的配置,线上状态,新的配置)。例如,假设你部署了一个应用:

1
helm install very_important_app ./very_important_app

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

1
kubectl scale -replicas=0 deployment/very_important_app

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

1
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 进行部署:

1
2
3
containers:
- name: server
  image: my_app:2.0.0

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

1
2
3
4
5
containers:
- name: server
  image: my_app:2.0.0
- name: istio-sidecar
  image: istio-sidecar-proxy:1.0.0

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

1
2
3
containers:
- name: server
  image: my_app:2.1.0

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

1
2
3
4
5
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 移除了。但是你仍然可以以插件的形式安装。

2.6 不再自动创建命名空间

当在不存在的 Namespace 中创建应用时,Helm 2 将会自动创建 Namespace 。Helm 3 遵循其他 Kubernetes 工具的惯例,如果 Namespaces 不存在,则返回错误。

3. 参考


微信公众号
作者
微信公众号