继 我们介绍他的哥哥 - 。 这是一个开源项目，用于将系统组件安装到 Kubernetes 集群中，这些组件可以称为附加组件。
为什么还要添加任何内容？
众所周知，Kubernetes 不是一款现成的一体化产品，要构建一个“成人”集群，您将需要各种添加。 Addon-operator 将帮助您安装、配置这些附加组件并使其保持最新。
集群中对附加组件的需求在 同事 。 简而言之，目前 Kubernetes 的情况是，对于简单的“玩转”安装，您可以使用开箱即用的组件，对于开发人员和测试，您可以添加 Ingress，但对于完整安装，大约需要你可以说“你的生产已经准备好了”，你需要添加十几个不同的附加组件：用于监控的东西，用于日志记录的东西，不要忘记入口和证书管理器，选择节点组，添加网络策略，季节使用 sysctl 和 pod 自动缩放器设置...
与他们合作的具体细节是什么？
实践表明，问题不仅仅限于一次安装。 为了舒适地使用集群，需要更新、禁用附加组件（从集群中删除），并且您需要在将它们安装到生产集群中之前测试一些附加组件。
那么，也许 Ansible 就足够了？ 或许。 但 一般来说，成熟的附加组件如果没有设置就无法生存。 这些设置可能会有所不同，具体取决于集群变体（aws、gce、azure、裸机、do...）。 有些设置无法提前指定；它们必须从集群中获取。 而且集群不是静态的：对于某些设置，您必须监视更改。 这里 Ansible 已经缺失了：你需要一个位于集群中的程序，即Kubernetes 运营商。
那些在工作中尝试过的人 ，他们会说安装和更新附加组件以及监控设置的任务可以使用完全解决 对于 shell 操作符。 您可以编写一个执行条件的脚本 kubectl apply 并监视，例如 ConfigMap，其中将存储设置。 这大约是在 addon-operator 中实现的。
这是如何在 addon-operator 中组织的？
在创建新的解决方案时，我们遵循以下原则：
- 附加安装程序必须支持 模板化和声明性配置。 我们不制作安装附加组件的神奇脚本。 Addon-operator 使用 Helm 来安装插件。 要安装，您需要创建一个图表并选择将用于配置的值。
- 设置可以是 安装时生成， 他们能 从集群中获取或 接收更新、监控集群资源。 这些操作可以使用钩子来实现。
- 设置可以是 存储在集群中。 为了在集群中存储设置，需要创建一个 ConfigMap/addon-operator，并且 Addon-operator 会监视对此 ConfigMap 的更改。 插件操作符使钩子能够使用简单的约定来访问设置。
- 添加取决于设置。 如果设置已更改，则插件操作员将推出具有新值的 Helm 图表。 我们将 Helm 图表、其值和挂钩模块的组合称为（更多详细信息请参见下文）。
- 分期。 没有神奇的发布脚本。 更新机制类似于常规应用程序 - 将附加组件和附加操作符收集到图像中，标记它们并推出它们。
- 结果控制。 Addon-operator 可以为 Prometheus 提供指标。
addon-operator 中的 padding 是什么？
添加可以被视为向集群添加新功能的任何内容。 例如，安装 Ingress 就是一个很好的附加组件示例。 这可以是任何具有自己的 CRD 的操作员或控制器：prometheus-operator、cert-manager、kube-controller-manager 等。 或者一些小但更容易使用的东西 - 例如，秘密复制器，它将注册表秘密复制到新的命名空间，或者 sysctl 调谐器，它在新节点上配置 sysctl 参数。
为了实现附加组件，Addon-operator 提供了几个概念：
- 舵图 用于将各种软件安装到集群中 - 例如 Prometheus、Grafana、nginx-ingress。 如果所需的组件有Helm图表，那么使用Addon-operator安装它会非常简单。
- 值存储。 Helm 图表通常有许多不同的设置，这些设置会随着时间的推移而改变。 Addon-operator 支持存储这些设置，并可以监视它们的更改，以便使用新值重新安装 Helm 图表。
- 挂钩 是附加操作符在事件上运行并访问值存储的可执行文件。 该钩子可以监视集群中的变化并更新值存储中的值。 那些。 使用钩子，您可以在启动时或根据计划进行发现以从集群中收集值，也可以进行持续发现，根据集群中的变化从集群中收集值。
- 模 是 Helm 图表、值存储和钩子的组合。 可以启用或禁用模块。 禁用模块意味着删除所有 Helm Chart 版本。 模块可以动态地启用自己，例如，如果启用了它需要的所有模块，或者如果发现在挂钩中找到了必要的参数 - 这是使用辅助启用脚本完成的。
- 全局挂钩。 这些是“独立”的钩子，它们不包含在模块中，并且可以访问全局值存储，其值可用于模块中的所有钩子。
这些部分如何协同工作？ 我们看一下文档中的图片：
有两种工作场景：
- 全局钩子由事件触发 - 例如，当集群中的资源发生变化时。 该挂钩处理更改并将新值写入全局值存储。 Addon-operator 注意到全局存储已更改并启动所有模块。 每个模块使用其钩子确定是否需要启用并更新其值存储。 如果启用该模块，Addon 操作员将开始安装 Helm 图表。 在这种情况下，Helm图表可以访问模块存储和全局存储中的值。
- 第二种情况更简单：模块钩子由事件触发并更改模块值存储中的值。 插件操作员注意到这一点并启动具有更新值的 Helm 图表。
添加可以作为一个单独的钩子或一个 Helm 图表来实现，或者 甚至作为几个依赖模块 - 这取决于集群中安装的组件的复杂性以及所需的配置灵活性级别。 例如，在存储库中（）有一个 sysctl-tuner 插件，它既作为带有钩子和 Helm 图表的简单模块实现，又使用值存储，这使得可以通过编辑 ConfigMap 添加设置。
交付更新
关于组织 Addon-operator 安装的组件更新的几句话。
要在集群中运行 Addon-operator，您需要 构建带有附加内容的图像 以hook和Helm图表文件的形式，添加二进制文件 addon-operator 以及钩子所需的一切： bash, kubectl, jq, python ETC。 然后，可以将该映像作为常规应用程序推广到集群，并且您很可能希望组织一种或另一种标记方案。 如果集群很少，与应用程序相同的方法可能是合适的：新版本、新版本、转到所有集群并更正 Pod 的映像。 然而，在部署到大量集群的情况下，从通道自我更新的概念更适合我们。
我们是这样做的：
- 通道本质上是一个可以设置为任何内容的标识符（例如，dev/stage/ea/stable）。
- 频道名称是图像标签。 当您需要对频道进行更新时，会组装一个新图像并用频道名称标记。
- 当注册表中出现新映像时，Addon-operator 将重新启动并使用新映像启动。
正如中所写，这不是最佳实践 。 不建议这样做，但我们正在讨论 位于同一集群中的常规应用程序。 对于 Addon-operator 来说，一个应用程序是分散在集群中的大量 Deployment，自我更新有很大帮助，让生活变得更轻松。
渠道帮助和 测试中：如果有辅助集群，可以配置到通道 stage 并将更新滚动到其中，然后再将其发布到频道 ea и stable。 如果通道上有集群 ea 发生错误，您可以将其切换到 stable，同时正在调查该集群的问题。 如果集群不再受到主动支持，它会切换到“冻结”通道 - 例如， freeze-2019-03-20.
除了更新 hooks 和 Helm 图表之外，您可能还需要 更新和第三方组件。 例如，您注意到条件节点导出器中的错误，甚至想出了如何修补它。 接下来，您打开了 PR，正在等待新版本遍历所有集群并增加镜像的版本。 为了避免无限期地等待，您可以构建节点导出器并在接受 PR 之前切换到它。
一般来说，这可以在没有 Addon-operator 的情况下完成，但是使用 Addon-operator，用于安装节点导出器的模块将在一个存储库中可见，用于构建镜像的 Dockerfile 可以保留在那里，对于所有参与者来说都变得更容易了解发生了什么的过程...如果有多个集群，那么测试您的 PR 并推出新版本就会变得更容易！
这种组件更新组织对我们来说很成功，但毕竟可以实施任何其他合适的方案 在本例中，Addon-operator 是一个简单的二进制文件.
结论
Addon-operator 中实现的原则允许您构建一个透明的流程，用于在集群中创建、测试、安装和更新附加组件，类似于常规应用程序的开发流程。
模块格式（Helm 图表 + 挂钩）的 Addon-operator 的附加组件可以公开提供。 我们，Flant 公司，计划在夏季以此类新增内容的形式发布我们的开发成果。 加入 GitHub 上的开发 (, ），尝试根据 и ，等待有关哈布雷和我们的消息 !
PS
另请阅读我们的博客：
- «“;
- «“。
来源： habr.com