iwh头盔_您如何管理头盔图表？

iwh头盔

无论您喜欢它还是讨厌它，Helm都是管理Kubernetes应用程序的无处不在的工具。 您可以以多种不同的方式使用它，这虽然很棒，但也可能不胜枚举。

我们注意到有几个问题不断出现：

1. 您将Helm图表放在哪里？
   您将它们与应用程序文件保留在一起还是使用图表存储库？
   
2. 您如何划分Helm图表？
   您是否为每个服务使用一个共享图表或维护一个图表？

我将根据我们在投资组合中的初创公司的经验，尝试解决这些问题，但我也将借鉴大型组织的观点。

以下是我将概述的选项：

1. 使用图表存储库存储一个大的共享图表
   
2. 使用图表存储库来存储许多特定于服务的图表。
   
3. 使用特定于服务的图表 ，该图表与服务本身存储在相同的存储库中（破坏者警报：我们更喜欢这一点）。

然后，我将介绍在决定这些选项之一时应考虑的因素，例如依赖性差异和团队结构。

选项1：在图表存储库中维护一个大共享图表

在我们的一个项目中，我们从一张用于部署多种服务的大型图表开始。 它存储在ChartMuseum中 ，并由负责部署基础结构的人员进行维护。

如果您的服务本质上非常相似，则共享图表可以节省很多麻烦。 例如，以Helm维护者Josh Dolitsky在KubeCon 2019上描述的这种情况为例：

我最近在一个项目上工作，有九个微服务……大约在第二或第三位，我意识到它们几乎都是相同的HTTP侦听服务。 因此，我决定让我们构建一个对每个服务都完全相同的头盔图，因此我们使用一个头盔图来部署九种不同的服务，并对每种服务进行不同的配置-只需为该特定服务设置一个新的docker标签。

在这种情况下，将Helm图表存储在图表存储库（如ChartMuseum）中是有意义的。 仅这些值需要保留在这些特定于服务的存储库中。

选项2：在图表存储库中维护多个特定于服务的图表

特定于服务的图表的优点是您可以更改一项服务，而不必担心会破坏另一项服务。 但是它们可能导致重复的工作。 如果要更新通用配置，则必须在每个图表中进行相同的更改。

是否需要将它们保存在图表存储库中是另一个问题。 如果图表仍然是特定于服务的，则没有强大的体系结构论点将它们存储在一起。 但是，如果您有专职人员或团队维护所有图表，这通常会更容易。

例如，我与一位DevOps工程师合作，他在一个中央图表存储库中维护15种不同微服务的图表。 对于他来说，将它们全部更新到一个位置比向15个不同的存储库提交拉取请求要容易得多。 开发人员自己知道如何更新图表，有时会这样做，但是他更喜欢处理与资源相关的设置，例如广告连播中断预算。

选项3：将服务特定的图表与服务本身保存在相同的存储库中

特定于服务的图表对于服务具有显着差异的基于微服务的应用程序是一个不错的选择。 当您将每个图表与服务代码保存在同一存储库中时，此模式会更好。

如果将Helm图表存储在服务存储库中，则更容易独立于其他项目连续地部署服务。 您可以将图表更新（例如添加新变量）与对应用程序逻辑的更改一起提交-使其更易于识别和还原重大更改。

但是，此选项的优势取决于您维护的微服务数量。 如果您遇到两位数的问题（如我在上一节中描述的情况），那么此选项可能更多的是障碍而不是帮助。 如果您要处理非常同质的服务（如Josh Dolitsky的示例），则尤其如此。

决定选择权时要考虑的因素

通常要考虑两个基本方面：

依赖性和可重复性：每个服务的依赖性有何不同？ 对一项服务的更改会破坏另一项服务的风险是什么？ 您如何再现特定开发的条件？

团队结构 ：您是否有小型自治团队负责每项服务？ 您是否拥有对DevOps有一定了解的开发人员？ 您的团队中“ DevOps文化”的流行程度如何？

依赖性和可重复性

如果您将图表与应用程序分开维护，则它们的版本将彼此不同。 如果您在部署时遇到问题，并且需要重现导致该问题的条件，则需要确定：a）服务版本，以及b）用于部署它的图表版本。 可能会想采取一种捷径，并始终使用“最新”图表测试服务xxx，但这是一个糟糕的主意。 您将永远不会重现导致问题的确切条件。

那么，如果您经常发布需要更改图表的版本该怎么办？ 您不应该一起测试这些更改吗？

考虑以下示例场景，其中许多开发人员需要创建同一共享图表的分支版本：

每个 服务 分支都需要使用正确的 图表 分支

• 开发人员（Edeltraud和Eberhardt）都在不同的功能分支上工作，并希望在开发环境中测试他们的更改以及图表更改，因此他们也需要对图表进行分支。
  
• 同时，DevOps工程师Duane正在更新共享图表自己分支中的一些通用组件。

如果没有人更改其图表，则可能会中断另一项服务的部署。

不久前，我们遇到了这个问题。 图表维护者使用新的条件块更新了共享图表。 该语句检查是否将新变量“ foo”设置为“ enabled”。

但是，尚未在所有服务的值文件中定义变量“ foo”。 缺少变量的服务的部署失败了—不幸的是，当时在图表中没有定义默认的回退行为。

如果图表和代码在同一个仓库中，并且可以在同一个分支中进行测试，则测试这类问题要容易得多。

即使一开始看起来过于刻板，我们也会这样做。 我们已经研究了具有很少依赖性的服务：对于每个服务，Helm图表仅部署一个带有特定Docker标签的主容器。 映像名称和docker标签通过变量传递。 尽管如此，我们仍然避免使用共享图表-而是选择在每个服务存储库中放置单独的图表。

主要是因为我们只处理四种服务。 但是我们的开发人员也更喜欢拥有所有会影响CI / CD的配置。 但是，并非总是如此，因此现在是检查其他维度的好时机：

团队架构

图表维护的问题还取决于谁拥有部署过程。

另一位Helm维护者Matt Farina撰写了一篇很棒的文章，他谈到了Helm试图解决的复杂性 。 他阐明了必须处理Kubernetes的复杂性的三个主要角色。 为了清楚起见，我将对他进行释义，并将其角色描述如下：

1. 应用程序开发人员-这些人构建服务，添加功能并修复错误。
   
2. 部署人员-这些人负责将应用程序推向世界。 希望有不错的自动化为他们部署应用程序，但是他们知道它的工作方式，并且可以根据需要进行更改。
   
3. 系统工程师-这些人维护部署人员部署到的Kubernetes环境。 他们是管理计算资源的专家，并试图最大程度地减少服务停机时间。

第一个和第三个角色与您可能在野外找到的普通职位相匹配。 “部署者”的角色有点模棱两可。

该角色通常由同时也是其他两个角色之一的人接任-这影响了您如何管理Helm图表。

我们通过经验中学到了这一点。

初创公司中的DevOps

如前所述，我们的业务是为往往不得不Swift扩大规模的初创公司提供运营支持。

我们已经看到了许多“非常规”的设置和分工。 在早期阶段，应用程序开发人员可能会戴着不同的帽子，甚至有些人还可以帮助您完成sysadmin任务，例如设置打印机或配置Office VPN。 他们将尽全力争取其他两个职位，因为没有其他人可以帮助他们（直到我们参与进来）。

一旦找到了Helm，大多数应用程序开发人员便会将其图表放在最容易处理的地方，即与他们维护的仓库相同。

大型组织中的DevOps

您可能会在一个更大的结构化团队中工作，您可能会以不同程度的恐惧阅读上一节。

在这种情况下，您可能拥有自己的DevOps工程师甚至整个DevOps部门。 这个人或团队也经常觉得对“部署者”角色负责。 很有可能，他们会倾向于采用更集中的方法，例如将所有图表存储在ChartMuseum这样的图表存储库中。 让应用程序开发人员过多参与Helm图表的意愿降低（通常是出于充分的理由）。

例如，我最近观看了VMWare系统工程师Amy Chen进行的名为“ 从头开始构建Helm Charts ”的老技术演讲。 她在介绍性发言中说：

“在基础架构中，您的主要目标是始终为失败做好准备，对吗？ 没有信任-就好像我真的不想信任我的应用程序开发人员，而我真的不需要信任我的应用程序开发人员一样”

这是可以理解的。 您不希望应用程序开发人员弄乱诸如CPU和内存限制或pod中断预算之类的设置。 但是，“ DevOps文化”的整个概念是专门为改善基础架构维护者与开发人员之间有时遥远的关系而发展的。

应用DevOps文化

Atlassian（JIRA和Trello的所有者）出版了“ Team Playbook ”，其中定义了DevOps文化，如下所示：

“ DevOps文化就是关于开发人员和运营人员之间的共识，以及对他们所构建软件的责任分担。 这意味着在开发，IT /运营和“业务”之间提高透明度，沟通和协作。

如果您将其实际应用于一般的Helm图表维护和基础结构配置，那么您将把大部分责任交给应用程序开发人员。 他们还承担“部署者”的角色，并更改其拥有的存储库中的配置。

系统工程师仍然可以集中他们唯一维护的设置。 例如，一些团队还维护一个中央基础结构存储库，该存储库存储公用资源，例如Terra引导配置或Helm文件，这些资源是引导新项目（例如，用于设置入口控制器和证书管理器）的。 Helm 3还支持所谓的“ 库图表 ”，该库图表只能作为另一个图表的一部分进行部署。 这使得区分常见更改和服务特定更改的责任变得更加容易。

即使将图表保存在服务库中，系统工程师仍可以充当重要更改的看门人。 例如，您可以使用GitHub CODEOWNERS文件来确保将系统工程师添加为审阅者，以进行回购后图表目录的任何更改。

如果系统工程师需要主动进行与应用程序开发无关的更改，则他们可以指示开发人员为他们进行更改，并解释为什么更改至关重要。 请考虑更新先前的插图以反映这种情况：

开发人员可以了解有关基础架构以及这些更改如何影响其服务的更多信息。

指引

如果有一个简单的经验法则，那就是：首先看选项＃3 。

尝试维护服务存储库中每个服务的Helm图表。 或者至少考虑一下我之前描述的混合方法。

如果您有数十个非常相似的服务，那么最好使用共享图表。 请记住，您必须将其维护在中央存储库中。 这增加了意外耦合的风险，这可能会中断服务部署。 更高的风险意味着您将对部署更加谨慎，这反过来意味着您将减少部署频率。

即使您确实具有特定于服务的图表，也可能需要集中存储它们，因为您没有人或专业知识来以分布式方式进行管理。 或者，您的组织需要明确区分“部署者”和“应用程序开发者”之间的责任。

无论您决定做什么，我都希望我已经澄清了在进行最终通话时需要考虑的事项。 成为“部署者”并不容易，尤其是当这不是您的日常工作时。

关于作者和项目A的披露说明

Merlin在Project A上发布了有关开发人员创新和新技术的博客，这是一家专注于早期创业公司的风险投资机构。 项目A 向其投资组合公司提供运营支持，包括开发人员专业知识。 作为IT团队的一员，他介绍了Project A的工作重点，帮助初创公司发展成为蒸蒸日上的成功案例。

翻译自: https://hackernoon.com/how-to-you-manage-helm-charts-rb56309o

iwh头盔