借助Helm创建了一个 Kubernetes Operator
发布时间：2022-07-16 12:12:11 所属栏目：云计算 来源：互联网
导读：K8ssandra 是 Apache Cassandra在 Kubernetes 上的一个发行版，由多个开源组件构建而成。从一开始直到最近的 K8ssandra 1.3 版本，K8ssandra 一直使用 Helm 图表进行安装和管理。虽然该项目的某些组件使用了 Kubernetes Operators包括 Cassandra（cass-opera
|
K8ssandra 是 Apache Cassandra®在 Kubernetes 上的一个发行版，由多个开源组件构建而成。从一开始直到最近的 K8ssandra 1.3 版本，K8ssandra 一直使用 Helm 图表进行安装和管理。虽然该项目的某些组件使用了 Kubernetes Operators——包括 Cassandra（cass-operator）和 Medusa（medusa-operator），但还没有一个 Operator 对所有组件进行整体管理。 K8ssandra 团队最近完成了一个我们讨论了几个月的决定：为 K8ssandra 项目创建一个 Operator。在本文中，我们介绍了我们使用 Helm 的经验，我们为 K8ssandra 创建 Operator 的决定，以及我们希望这将为项目带来的好处。 1 背景 K8ssandra 的核心是 cass-operator，我们使用它来部署 Cassandra 节点。我们围绕它添加了一系列组件，组成一个生态系统，用于在 Kubernetes 中有效地运行 Cassandra。这些组件包括用于管理反熵修复（Reaper）和备份（Medusa）的操作工具。我们引入了用于指标收集和报告的 Prometheus/Grafana 技术栈。Stargate 则是一个数据网关，通过 REST、GraphQL 和 Document API 提供了对 Cassandra 更灵活的访问。 一开始，我们使用 Helm 来帮助管理这些组件的安装和配置。这使我们能够快速启动项目并开始组建社区。最初对该项目感兴趣的人主要是 Cassandra 社区的开发人员，他们不一定有很多 Kubernetes 的专业知识和经验。他们中的许多人发现掌握像 Helm 这样的包管理工具和安装程序比掌握 Operator 和 CRD（定制资源定义）更容易。这并不是说 Helm 是为“不太了解 Kubernetes 的人”准备的，因为 Kubernetes 生态的很大一部分都在使用 Helm。 2 进展：Helm 的优缺点 随着项目的发展，我们开始在 Helm 上遇到一些限制。虽然正确安装 K8ssandra 集群非常简单，但我们在升级和管理集群时遇到了比较多的问题。 编写复杂的逻辑 Helm 通过循环和 if 语句很好地支持控制流。然而，当嵌套层次比较多时，整个代码就很难理解和阅读，而且缩进也成为一个问题。特别是，我们发现对修改后的 Helm 图表进行同行评审变得相当困难。 重用和可扩展性 Helm 变量的作用范围被限制在声明它们的模板内。例如，我们在 Cassandra 数据中心模板中定义了一个变量，在 Stargate 模板中不可能重用它，我们必须在 Stargate 模板中重新创建相同的变量。这使得我们的代码很难保持 DRY 原则，我们发现这是缺陷的来源。 类似地，Helm 有一个很好很大的帮助模板函数库，但是这个库并没有涵盖所有用例，并且没有接口来定义您自己的函数。您可以定义自己的模板，模板可以被大量重用，但它们不能代替函数。 项目结构和继承 伞形图设计模式是 Helm 的最佳实践，但我们在尝试实现该模式时也遇到了困难。我们能够创建一个顶级 K8ssandra Helm 图表，其中包含 Cassandra 和 Prometheus 的子图表，但当我们试图为 Reaper 和 Stargate 创建额外的子图表时，却遇到了变量作用范围的问题。我们的目的是仅仅在顶级图表定义身份验证设置，这样它们不仅可以应用于 Cassandra，还可以应用于 Stargate 和 Reaper。Helm 的继承模型不支持这种将变量向下推到子图表的概念。 定制资源定义（CRD）管理 Helm 可以创建 Kubernetes 的定制资源定义（CRD），但不能管理它们。我们知道这是 Helm 开发者为 Helm 3 做出的深思熟虑的设计选择。由于定制资源的定义是集群范围的，如果多个 Helm 安装过程试图在不同版本的 CRD 上工作可能会带来一些混乱。然而，这给我们带来了一些困难。为了管理资源的更新——比如 Helm 内部的 Cassandra 数据中心，我们必须实现一个变通方案。我们实现了定制的 Kubernetes job，并将它们标记为升级前的钩子（Hook），这样 Helm 就可以在升级时执行它们。每个 job 都用 Go 语言编写，并打包成一个镜像。这本质上就像编写迷你控制器，并且在某种程度上开始感觉像编写 Operator。 临界点：多集群部署 虽然我们已经能够通过 1.3 版本解决这些 Helm 的问题，但我们路线图上的下一个主要特性是实现多集群 K8ssandra 部署（跨越多个 Kubernetes 集群的 K8ssandra/Cassandra 集群）。我们意识到，即使没有复杂的网络配置，我们也无法使用 Helm 有效实现这一步。 3 设定新方向 最后，我们意识到我们让 Helm 做得太多了。很容易陷入这样的情况：您学会了如何使用锤子，所有东西看起来都像钉子，但您真正需要的是螺丝刀。 结果，我们发现我们与 Operator 框架 的创建者有一些共同点，他们已经为 Operator 定义了一个 功能模型，我们将其展示在这里： 如图所示，Helm 最适合 Operator 前两个级别的功能，侧重于简单的安装和升级。执行更复杂的操作如故障处理和恢复、自动伸缩，以及更复杂的安装和升级应该用诸如 Ansible 或 Go 之类的编程语言来实现，而不是使用像 Helm 这样的模板语言。 构建一个 Operator：K8ssandra 2.0 基于这一分析，团队决定开始构建一个 Operator，我们将其称之为 K8ssandra 2.x 系列版本。2.0 版本的首要任务是移植我们在 Helm 图表中已有的功能，确保 Operator 具有相同的特性，并在其中增加多集群支持。我们仍然打算解决 1.x 版本中的 bug 或漏洞，但我们正试图将所有主要的新功能都集中在 Operator 上。 Helm 仍有一席之地 在工具方面，我们不认为 Helm 和 Operator 是相互排斥的。这两种方法是互补的，我们需要根据其优势来使用每一种方法。我们将继续使用 Helm 执行基本的安装操作，包括安装 Operator 以及设置 Cassandra 和其他组件使用的管理员服务帐号（Administrator Service Account）。这些都是 Helm 这样的包管理器最擅长的功能。 （编辑：我爱制作网_潮州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330565号