iwh头盔_头盔2与头盔3：第1部分

iwh头盔

因此，Helm3终于被释放了。 每个人都向蒂勒说再见，但这并不是Helm3的唯一变化。 让我们讨论其他变化。

阿迪奥斯·蒂勒（Adios Tiller）

是的，Tiller已被删除，这是一件好事，但要了解为什么我们需要获得一些背景知识。 Tiller是Helm的服务器端（在Kubernetes集群上运行）组件，其主要目的是使多个不同的运营商可以使用同一组发行版。

在开发Helm 2时，Kubernetes还没有基于角色的访问控制（RBAC），因此要实现上述目标，Helm必须自己照顾自己。 它必须跟踪允许谁在哪里安装什么。

不再需要这种复杂性，因为默认情况下从Kubernetes 1.6启用了RBAC，因此Helm无需执行Kubernetes可以完成的相同工作，这就是为什么在Helm 3分er中完全将其删除了的原因。

蒂勒还被用作Helm发布信息和维护Helm状态的中央枢纽。 在Helm 3中，直接从Kubernetes API Server中获取了相同的信息，并且在客户端呈现了Charts，这使得Helm 3对于Kubernetes而言更“原生”且更简单。

随着Tiller的消失，Helm的安全模型也得到了简化（通过启用RBAC来锁定Tiller以用于生产场景中，这很难管理）。 现在可以使用kubeconfig文件轻松评估Helm权限。

因此，当版本仍记录在群集中时，群集管理员可以将用户权限限制在所需的任何级别，而Helm的其余功能保持不变。

好吧，让我们忘记提勒。 还有什么改变了？

正如我在开始时提到的那样-移除Tiller是一件大事，但不是唯一的重大改变。 让我们来看看其他：

三路战略合并补丁

头盔2使用了双向战略合并补丁。 这意味着，当您要执行任何舵操作时，会将最新清单清单与建议的图表清单进行比较。 它检查了这两个图表之间的差异，以确定需要对Kubernetes中的资源进行哪些更改。

听起来很聪明，对不对？ 问题在于，如果更改是“手动”应用于集群的（例如通过kubectl edit ），则不会考虑更改 。 这导致资源无法回滚到其先前状态，因为Helm2仅将最后应用的图表清单作为其当前状态进行检查，并且由于图表状态没有变化（我们仅更改了集群上的活动状态），Helm只是做了没有看到执行回滚的需要。

那就是三路战略合并补丁的发布。 Helm3如何做到这一点？ 它也只是考虑了活动状态（因此，从现在起我们有了旧清单，活动状态和新清单，因此是3路而不是2路）。

例如，假设您部署的应用程序具有：

helm install very_important_app ./very_important_app

例如，此应用程序Chart设置为具有3个副本集。 现在，如果有人误执行kubectl编辑，或：

kubectl scale -replicas=0 deployment/very_important_app

然后您团队中的某人会意识到，由于某种神秘的原因， very_important_app已关闭，并将尝试执行：

helm rollback very_important_app

在Helm 2中，它将生成一个补丁，将旧清单与新清单进行比较。 因为这是回滚，并且某人仅更改了活动状态（因此清单没有更改），Helm会确定没有要回滚的内容，因为旧清单和新清单之间没有区别（两者都希望有3个副本）。

然后不执行回滚，副本数继续保持为零。

您现在开始惊慌失措...

另一方面，在Helm 3中，将使用旧清单，活动状态和新清单生成补丁。 Helm认识到旧状态为3，活动状态为0，因此它确定新清单希望将其更改回3，因此它生成补丁来解决该问题。

您现在不再惊慌了...

执行升级时，Helm 3也会发生类似的过程。 由于现在考虑了活动状态，因此，例如，如果某个基于控制器的应用程序（或类似服务网格）将任何东西注入到通过Helm部署的kubernetes对象中，则将在使用Helm2进行Helm升级过程中将其删除。

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

而且，如果您现在使用Helm2执行升级过程，您将得到以下结果：

containers:
- name: server
  image: my_app:2.1.0

Istio边车被删除，因为它不在图表中。 但是，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

三向战略合并补丁使Helming方式更可预测且更安全。 如果有香蕉，您不必担心。

秘密作为默认存储驱动程序

Helm 2使用ConfigMaps存储发行信息。 在Helm 3中，将使用Secrets（秘密类型为helm.sh/release ）作为默认存储驱动程序。 这带来了一些优势，并大大简化了Helm的功能。 为了获得（并应用）配置，Helm2必须执行一些操作，因为config本身已加密存储并存储在密钥或ConfigMap之一中。

Helm3将配置直接存储在Secret中，因此无需执行多个操作即可获取配置，而只需提取该机密，解密并应用即可。 另一个优点是，发布名称在整个集群中不再必须是唯一的。 包含发行版的机密存储在安装发行版的名称空间中。 因此，一旦它们位于不同的名称空间中，便可以拥有多个具有相同名称的发行版。

JSON架构图验证

现在可以对图表值强制进行JSON模式验证。 使用该功能，您可以确保用户提供的值遵循图表维护者创建的架构。

这为OPS与DEV的合作创造了更多可能性（OPS团队可以为DEV提供更大的自由度），并且当用户尝试为图表使用一组错误的值时，可以提供更好的错误报告。

现在需要发布名称

在Helm 2中，如果未提供名称，则会生成一个随机名称。 如果在头盔安装中未提供任何名称，则头盔3将引发错误（最终，如果您仍要使用随机名称，则可以使用– generate-name标志）

舵服务 已删除

很少有人使用舵机服务（   为开发目的而在您的计算机上运行本地Chart Repository ），但对于那些这样做的人-现在已将其删除。 尽管您仍然可以将其用作插件。

命名空间不再自动创建

在不存在的命名空间中创建发行版时，Helm 2会自动创建它。 Helm 3遵循其他Kubernetes工具的行为，如果名称空间不存在，则返回错误。

那是Helm最重要的变化，还有更多变化。 如果您有兴趣，请查看Helm官方文档 。 在第2部分中，我将向您展示如何从Helm2迁移到Helm3。

翻译自: https://hackernoon.com/helm2-vs-helm3-part-1-0js3tcb

iwh头盔