Kubernetes 中的通用表达式语言

通用表达式语言 (Common Expression Language, CEL) 用于声明 Kubernetes API 的验证规则、策略规则和其他限制或条件。

CEL 表达式在 API 服务器中直接进行处理， 这使得 CEL 成为许多可扩展性用例的便捷替代方案，而无需使用类似 Webhook 这种进程外机制。 只要控制平面的 API 服务器组件保持可用状态，你的 CEL 表达式就会继续执行。

语言概述

CEL 语言的语法直观简单， 类似于 C、C++、Java、JavaScript 和 Go 中的表达式。

CEL 的设计目的是嵌入应用程序中。每个 CEL "程序" 都是一个单独的表达式，其评估结果为单个值。 CEL 表达式通常是短小的 "一行式"，可以轻松嵌入到 Kubernetes API 资源的字符串字段中。

对 CEL 程序的输入是各种 “变量”。包含 CEL 的每个 Kubernetes API 字段都在 API 文档中声明了字段可使用哪些变量。例如，在 CustomResourceDefinition 的 x-kubernetes-validations[i].rules 字段中，self 和 oldSelf 变量可用， 并且分别指代要由 CEL 表达式验证的自定义资源数据的前一个状态和当前状态。 其他 Kubernetes API 字段可能声明不同的变量。请查阅 API 字段的 API 文档以了解该字段可使用哪些变量。

CEL 表达式示例：

CEL 选项、语言特性和库

CEL 配置了以下选项、库和语言特性，这些特性是在所列的 Kubernetes 版本中引入的：

CEL 函数、特性和语言设置支持 Kubernetes 控制平面回滚。 例如，CEL 可选值（Optional Values） 是在 Kubernetes 1.29 引入的，因此只有该版本或更新的 API 服务器才会接受使用 CEL Optional Values 的 CEL 表达式的写入请求。 但是，当集群回滚到 Kubernetes 1.28 时，已经存储在 API 资源中的使用了 "CEL Optional Values" 的 CEL 表达式将继续正确评估。

Kubernetes CEL 库

除了 CEL 社区库之外，Kubernetes 还包括在 Kubernetes 中使用 CEL 时所有可用的 CEL 库。

Kubernetes 列表库

列表库包括 indexOf 和 lastIndexOf，这两个函数的功能类似于同名的字符串函数。 这些函数返回提供的元素在列表中的第一个或最后一个位置索引。

列表库还包括 min、max 和 sum。 sum 可以用于所有数字类型以及持续时间类型。 min 和 max 可用于所有可比较的类型。

isSorted 也作为一个便捷的函数提供，并且支持所有可比较的类型。

例如：

更多信息请查阅 Go 文档： Kubernetes 列表库。

Kubernetes 正则表达式库

除了 CEL 标准库提供的 matches 函数外，正则表达式库还提供了 find 和 findAll， 使得更多种类的正则表达式运算成为可能。

例如：

更多信息请查阅 Go 文档： Kubernetes 正则表达式库。

Kubernetes URL 库

为了更轻松、更安全地处理 URL，添加了以下函数：

• isURL(string) 按照 Go 的 net/url 检查字符串是否是一个有效的 URL。该字符串必须是一个绝对 URL。
• url(string) URL 将字符串转换为 URL，如果字符串不是一个有效的 URL，则返回错误。

一旦通过 url 函数解析，所得到的 URL 对象就具有 getScheme、getHost、getHostname、getPort、getEscapedPath 和 getQuery 访问器。

例如：

更多信息请查阅 Go 文档： Kubernetes URL 库。

Kubernetes 鉴权组件库

在 API 中使用 CEL 表达式，可以使用类型为 Authorizer 的变量， 这个鉴权组件可用于对请求的主体（已认证用户）执行鉴权检查。

API 资源检查的过程如下：

1. 指定要检查的组和资源：Authorizer.group(string).resource(string) ResourceCheck
2. 可以调用以下任意组合的构建器函数（Builder Function），以进一步缩小鉴权检查范围。 注意这些函数将返回接收者的类型，并且可以串接起来：
   • ResourceCheck.subresource(string) ResourceCheck
   • ResourceCheck.namespace(string) ResourceCheck
   • ResourceCheck.name(string) ResourceCheck
3. 调用 ResourceCheck.check(verb string) Decision 来执行鉴权检查。
4. 调用 allowed() bool 或 reason() string 来查验鉴权检查的结果。

对非资源访问的鉴权过程如下：

1. 仅指定路径：Authorizer.path(string) PathCheck。
2. 调用 PathCheck.check(httpVerb string) Decision 来执行鉴权检查。
3. 调用 allowed() bool 或 reason() string 来查验鉴权检查的结果。

对于服务账号执行鉴权检查的方式：

• Authorizer.serviceAccount(namespace string, name string) Authorizer

更多信息请参阅 Go 文档： Kubernetes Authz library。

Kubernetes 数量库

Kubernetes 1.28 添加了对数量字符串（例如 1.5G、512k、20Mi）的操作支持。

• isQuantity(string) 根据 Kubernetes 的 resource.Quantity， 检查字符串是否是有效的 Quantity。
• quantity(string) Quantity 将字符串转换为 Quantity，如果字符串不是有效的数量，则会报错。

一旦通过 quantity 函数解析，得到的 Quantity 对象将具有以下成员函数库：

例如：

类型检查

CEL 是一种逐渐类型化的语言。

一些 Kubernetes API 字段包含完全经过类型检查的 CEL 表达式。 例如，CustomResourceDefinition 验证规则就是完全经过类型检查的。

一些 Kubernetes API 字段包含部分经过类型检查的 CEL 表达式。 部分经过类型检查的表达式是指一些变量是静态类型，而另一些变量是动态类型的表达式。 例如在 ValidatingAdmissionPolicy 的 CEL 表达式中，request 变量是有类型的，但 object 变量是动态类型的。 因此，包含 request.namex 的表达式将无法通过类型检查，因为 namex 字段未定义。 然而，即使对于 object 所引用的资源种类没有定义 namex 字段， object.namex 也会通过类型检查，因为 object 是动态类型。

在 CEL 中，has() 宏可用于检查动态类型变量的字段是否可访问，然后再尝试访问该字段的值。 例如：

has(object.namex) ? object.namex == 'special' : request.name == 'special'

类型系统集成

另见：CEL 类型、 OpenAPI 类型、 Kubernetes 结构化模式。

x-kubernetes-list-type 为 set 或 map 的数组进行相等比较时会忽略元素顺序。 例如，如果这些数组代表 Kubernetes 的 set 值，则 [1, 2] == [2, 1]。

使用 x-kubernetes-list-type 的数组进行串接时，使用 list 类型的语义：

• set：X + Y 执行并集操作，保留 X 中所有元素的数组位置， 将 Y 中非交集元素追加到 X 中，保留它们的部分顺序。
• map：X + Y 执行合并操作，保留 X 中所有键的数组位置， 但是当 X 和 Y 的键集相交时，将 Y 中的值覆盖 X 中的值。 将 Y 中非交集键的元素附加到 X 中，保留它们的部分顺序。

转义

仅形如 [a-zA-Z_.-/][a-zA-Z0-9_.-/]* 的 Kubernetes 资源属性名可以从 CEL 中访问。 当在表达式中访问可访问的属性名时，会根据以下规则进行转义：

当你需要转义 CEL 的任一 保留的 关键字时，你需要使用下划线转义来完全匹配属性名 （例如，sprint 这个单词中的 int 不会被转义，也不需要被转义）。

转义示例：

资源约束

CEL 不是图灵完备的，提供了多种生产安全控制手段来限制执行时间。 CEL 的资源约束特性提供了关于表达式复杂性的反馈，并帮助保护 API 服务器免受过度的资源消耗。 CEL 的资源约束特性用于防止 CEL 评估消耗过多的 API 服务器资源。

资源约束特性的一个关键要素是 CEL 定义的成本单位，它是一种跟踪 CPU 利用率的方式。 成本单位独立于系统负载和硬件。成本单位也是确定性的；对于任何给定的 CEL 表达式和输入数据， 由 CEL 解释器评估表达式将始终产生相同的成本。

CEL 的许多核心运算具有固定成本。例如比较（例如 <）这类最简单的运算成本为 1。 有些运算具有更高的固定成本，例如列表字面声明具有 40 个成本单位的固定基础成本。

调用本地代码实现的函数时，基于运算的时间复杂度估算其成本。 举例而言：match 和 find 这类使用正则表达式的运算使用 length(regexString)*length(inputString) 的近似成本进行估算。 这个近似的成本反映了 Go 的 RE2 实现的最坏情况的时间复杂度。

运行时成本预算

所有由 Kubernetes 评估的 CEL 表达式都受到运行时成本预算的限制。 运行时成本预算是通过在解释 CEL 表达式时增加成本单元计数器来计算实际 CPU 利用率的估算值。 如果 CEL 解释器执行的指令太多，将超出运行时成本预算，表达式的执行将停止，并将出现错误。

一些 Kubernetes 资源定义了额外的运行时成本预算，用于限制多个表达式的执行。 如果所有表达式的成本总和超过预算，表达式的执行将停止，并将出现错误。 例如，自定义资源的验证具有针对验证自定义资源所评估的所有 验证规则的 每个验证 运行时成本预算。

估算的成本限制

对于某些 Kubernetes 资源，API 服务器还可能检查 CEL 表达式的最坏情况估计运行时间是否过于昂贵而无法执行。 如果是，则 API 服务器会拒绝包含 CEL 表达式的创建或更新操作，以防止 CEL 表达式被写入 API 资源。 此特性提供了更强的保证，即写入 API 资源的 CEL 表达式将在运行时进行评估，而不会超过运行时成本预算。