目录

    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 是如何做的呢?它只是多考虑了应用的线上状态(使用三路替代两路,旧的配置,线上状态,新的配置)。例如,假设你部署了一个应用:

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

    2.6 不再自动创建命名空间

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

    3. 参考