Kubernetes 策略引擎对于确保集群安全和从一开始就正确设置策略至关重要。 例如，您可能需要一个策略来控制谁有权设置特权 Pod。 这些引擎定义了最终用户可以在集群上执行的操作，并确保集群可以通信。 每次创建 Kubernetes 对象时，策略都会评估并验证或更改请求。 策略可以应用于命名空间或集群中带有特定标签的不同 Pod。
如果 Kubernetes 对象不符合策略的要求，Kubernetes 策略引擎会阻止可能损害或影响集群的对象。 使用策略使用户能够构建其他工具（例如 Terraform 或 Ansible）无法实现的复杂配置。
近年来，策略格局不断发展，可用策略引擎的数量持续增加。 较新的产品与已建立的工具竞争。
本文重点介绍您应该在策略引擎中寻找的一些功能，以及这三个示例的优点和缺点。 它比较了三个流行的开源策略引擎，即 Open Policy Agent (OPA)、Kyverno 和 jsPolicy。
策略引擎功能
我将首先列出各种功能，以便您可以比较策略引擎
- 支持的语言：策略引擎必须使用 Kubernetes 支持的语言，以便于管理策略资源。
- 验证：验证规则决定了可以创建资源的属性。 当资源根据规则进行检查并被接受时，将对其进行验证。
- 变更：变更规则可以修改集群中的特定资源。 这些规则以给定的方式修改特定对象。
- 开发和测试工具：这些工具针对一个或多个策略测试一组资源，以将资源与您期望的结果（在单独的文件中声明）进行比较。
- 包管理：包管理处理规则的存储位置以及它们在集群中的管理方式。
- 镜像验证：使用策略来验证和签名容器镜像。
- 扩展：自定义构建的函数和插件，用于扩展和实现功能，例如对新协议的支持。
- 指标：监控对策略的任何应用更改、与传入请求相关的活动以及作为结果产生的结果。
Open Policy Agent (OPA)
Open Policy Agent (OPA) 是一款易于使用的策略引擎，可以与您的服务位于同一位置，并可以作为 Sidecar、主机级守护程序或库进行集成。 OPA 是一种通用引擎，可以管理多个堆栈中的策略，您可以将其用于其他任务，例如数据过滤和 CI/CD 管道。
OPA 允许您将策略与基础设施、服务或应用程序分离，以便负责策略管理的人员可以独立于服务来控制策略。 您还可以将策略与您喜欢的任何软件服务分离，并使用您想要的任何上下文编写内容感知策略。 分离策略将帮助您大规模构建服务，提高定位违规和冲突的能力，并降低人为错误的风险。
OPA 策略使用一种名为 Rego 的语言。 Rego 是一种查询语言，它扩展了 Datalog 以支持结构化数据模型，例如 JSON。 OPA 提供了一个框架来为您的策略编写测试。 此框架加快了新规则的开发速度，并减少了修改现有规则的时间。 OPA 还可以在运行时报告性能指标。 可以请求单个 API 调用中的这些指标，并将其与 API 响应一起返回。
OPA 的工作方式是决定策略，而不是强制执行策略。 当查询发送到系统时，它会被传递到 OPA，然后 OPA 根据已制定的策略验证查询并做出决定。 OPA 通过将查询输入与策略和数据进行比较来做出策略决策。 OPA 和 Rego 与领域无关，这意味着您可以在策略中描述任何不变式。 此外，策略决策不限于是/否或允许/拒绝答案。 像查询输入一样，您的策略可以创建结构化数据作为输出。
Kyverno
Kyverno 是一种 Kubernetes 策略引擎，它采用声明式管理范例来构建用于更改、验证或生成资源或配置的策略。 与使用策略作为代码的 OPA 相比，您可以指定代码而不是编写代码，然后 Kyverno 会找出如何执行它。 Kyverno 使用 YAML，因此这些策略被视为 Kubernetes 资源，无需学习新语言即可编写。 这使得查看和处理策略结果变得容易。 Kyverno 在这方面优于 OPA，因为用 Rego 语言开发代码可能很困难，尤其是在没有深入知识的情况下。
Kyverno 可以很好地与其他开发人员工具（如 Git 和 kubectl）配合使用。 验证规则是像 Kyverno 这样的准入控制器的主要用例，这使得验证资源在创建时是否遵守策略规则变得非常容易。 Kyverno 使用 Cosign 来验证和签名镜像。 如果在 OCI 注册表中未找到该镜像，或者未使用指定的密钥对其进行签名，则策略规则将不会验证它。 此外，Kyverno 使用 Grafana 来公开和收集来自集群的指标。 它使用容器注册表 (OCI 注册表) 简化和整合策略分发。
Kyverno 充当动态准入控制器，从 Kubernetes API 服务器接收 HTTP 回调，并将匹配的策略应用于这些回调。 这些策略使用诸如名称、种类和标签之类的选择器来匹配资源。 Kyverno 使用 Webhook 作为控制器，因为它处理来自服务器的准入审查请求。 在 Webhook 中，监视器创建和管理所有必需的配置。 有一个生成器控制器，用于生成请求并管理生成的资源的范围，还有一个策略控制器，用于创建、更新、删除和监视策略资源，并定期运行后台扫描以决定要采取的行动。
jsPolicy
jsPolicy 是一种用于 Kubernetes 的开源策略引擎，允许用户使用 JavaScript 或 TypeScript 构建策略。 使用 JavaScript 管理策略的复杂性较低，也更直接。 由于 JavaScript 编程语言、框架以及众多库和模块的广泛使用，jsPolicy 是作为策略引擎工具的自然选择。 与 jsPolicy 相比，Kyverno 和 OPA 更难更改和验证。 它的分发使用 npm 包，并具有用于创建和打包策略的内置 JavaScript SDK。
jsPolicy 是第一个具有控制器策略的策略引擎（响应 Kubernetes 事件的策略）。 此功能允许您对 Kubernetes 事件执行某些操作，并使用 jsPolicy 验证或更改它们。 与 OPA 一样，jsPolicy 是一个策略即代码平台。 但是，它旨在解决 Rego 语言问题，并为 Kyverno 上不可用的一些功能提供一些功能。
您可以将 kubectl 和 Kubernetes API 与 jsPolicy 一起使用，并且传入的每个请求都会保留在 etcd 中。 在请求被持久化之前，Webhook 管理器将在您的集群中执行策略。 它在您的集群中使用预构建的 JavaScript 沙箱来帮助策略执行，从而提高效率和速度。 策略编译器读取 jsPolicy 代码并将其编译成策略包，该策略包被放置并在沙箱中运行以提供策略违规。 查询策略违规以警报和审核违反策略代码的对象。 由于 jsPolicy 允许您使用 JavaScript，因此您可以将整个 JavaScript 生态系统及其用于测试的强大开发工具和框架一起使用来编写、测试和维护策略。
比较 Kubernetes 策略引擎
每个策略引擎的功能都不同。 虽然它们都可以验证和更改资源，但它们在其他特定功能上有所不同。 例如，OPA 和 Kyverno 支持扩展，但 jsPolicy 不支持。 下面的摘要比较了这三个策略的功能
(Joseph Eshiett, CC BY-SA 4.0)
这三种策略引擎都可以进行验证。 以下是差异。
- OPA
- 语言：Rego
- 变更：Alpha
- 开发/测试：有限
- 包管理：NA
- 镜像验证：是
- 扩展：是
- 指标：Prometheus
- Kyverno
- 语言：YAML
- 变更：是
- 开发/测试：有限
- 包管理：NA
- 镜像验证：是
- 扩展：是
- 指标：Grafana
- jsPolicy
- 语言：JavaScript
- 变更：是
- 开发/测试：广泛
- 包管理：npm
- 镜像验证：否
- 扩展：否
- 指标：Prometheus
总结
本文讨论了 Kubernetes 策略引擎相关的概念，并比较了三种不同的 Kubernetes 策略引擎：OPA、Kyverno 和 jsPolicy。
选择哪个引擎取决于您的个人偏好。如果您想要更直接和简单的方法，或者您精通 JavaScript 和 TypeScript，则应该使用 jsPolicy。但是，如果您喜欢 YAML 并希望坚持直接使用 Kubernetes 资源，那么 Kyverno 也是一个不错的选择。
评论已关闭。