自定义资源 (CR) 允许用户扩展 Kubernetes API。在创建 CR 之前，我们需要创建一个自定义资源定义 (CRD)，它将描述未来资源的结构和一些元属性。

有很多方法可以为 Kubernetes 创建 CRD。您也可以从头开始编写 CRD，但一些很棒的工具将为您搭建骨架结构，让事情变得更容易。其中一些是kubebuilder、operator-sdk等。

Kubernetes 操作员要求您定义和创建 CRD。通常，当您开发 Operator 时，基本要求是验证 CRD 中的不同字段。kubebuilder 中有很多方法可以执行基本验证，例如设置字段的最大/最小长度、字段的必需/可选验证检查等。

在 Kubernetes 1.25 之前，在 CRD 中创建复杂验证的唯一方法是编写和部署验证 webhook。每个 CRD 都会在系统上运行自己的验证 webhook 部署。当您必须开发和部署大量 CRD 时，这是一项运维和开发开销。此问题在 Kubernetes 1.25 版本中通过引入CEL（通用表达式语言）验证规则得到解决。在这篇文章中，我们将看到在 Kubernetes 中引入 CEL 之前和之后创建不可变 CRD 的过程。

警告

请注意，此功能仍处于测试阶段，可能会发生变化。以下部分假设您了解 Golang、Kubernetes 和operator开发的基础知识。

本文示例说明

在此示例中，我们将尝试创建一个不可变的 CRD，即一旦创建 CR，任何人都无法编辑该对象。如果有人试图编辑对象，API 服务器必须拒绝更改并抛出错误。

本文使用kubebuilder进行crd模块创建。

Kubernetes 1.23 中的 CRD 验证

如上所述，我们需要创建一个用于验证的 webhook。但在此之前，让我们搭建脚手架。

• 创建 Kubernetes 1.23 集群
• 创建一个存储库并使用 go mod 对其进行初始化。

mkdir /tmp/one
cd /tmp/one
go mod init one

• 初始化 kubebuilder

kubebuilder init --domain superops.com --license none --owner "superops"
kubebuilder create api --version v1 --group validate --kind ImmutableKind
kubebuilder create webhook --group validate --version v1 --kind ImmutableKind --programmatic-validation

验证代码集成

将验证 webhook 逻辑添加到代码库api/v1/immutablekind_webhook.go。在这种情况下，我们希望我们的对象是不可变的，因此必须阻止所有更新操作

// ValidateUpdate implements webhook.Validator so a webhook will be registered for the type
func (r *ImmutableKind) ValidateUpdate(old runtime.Object) error {
 immutablekindlog.Info("validate update", "name", r.Name)

 return apierrors.NewForbidden(
     schema.GroupResource{
         Group:    "validate.superops.com",
         Resource: "ImmutableKind",
     }, r.Name, &field.Error{
         Type:     field.ErrorTypeForbidden,
         Field:    "*",
         BadValue: r.Name,
         Detail:   "Invalid value: \"object\": Value is immutable",
     },
 )
}

由于证书问题，默认的 webhook 将不起作用。要解决此问题，您必须安装cert-manager以便于操作。

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.9.1/cert-manager.yaml

• 脚手架编辑配置以启用 webhook、执行注入等部署
• 取消注释patches/webhook_in_immutablekinds.yaml并patches/cainjection_in_immutablekinds.yaml在config/crd/kustomization.yaml
• 取消注释../certmanager和../webhook目录，以及config/default/kustomization.yamlmanager_webhook_patch.yaml中的整个CERTMANAGER替换块
• 创建自定义 CRD

make manifests

• 构建并将 webhook 代码逻辑推送到 dockerhub。在这种情况下，我将图像推送到我的个人 dockerhub 帐户进行部署。您可以相应地更改图像名称。

make docker-build docker-push IMG=superops/immutablekindwebhook:v1

• 安装部署operator

make install deploy IMG=superops/immutablekindwebhook:v1

• 部署CR

kubectl apply -f ./config/samples/validate_v1_immutablekind.yaml

apiVersion: validate.superops.com/v1
kind: ImmutableKind
metadata:
labels:
 app.kubernetes.io/name: immutablekind
 app.kubernetes.io/instance: immutablekind-sample
 app.kubernetes.io/part-of: immutable-validation-webhook
 app.kuberentes.io/managed-by: kustomize
 app.kubernetes.io/created-by: immutable-validation-webhook
 mutate: maybe
name: immutablekind-sample
spec:
# TODO(user): Add fields here

为了验证不变性功能，让我们编辑已部署的 CR。

为了简单起见，让我们从上面的代码片段中删除所有标签，然后immutablekind-sample再次部署 CR。

echo "apiVersion: validate.superops.com/v1
kind: ImmutableKind
metadata:
  name: immutablekind-sample" | kubectl apply -f-

Kubernetes API 服务器应该抛出一个阻止更新的错误。

Kubernetes 1.25 中的 CRD 验证

随着出色的 CEL 的引入，我们可以看到实现 CRD 验证的复杂性有明显的不同。最初的脚手架步骤将保持不变。

1. 创建 Kubernetes 1.25 集群
2. 创建一个存储库并使用 go mod 对其进行初始化。

mkdir /tmp/two
cd /tmp/two
go mod init two

初始化kubebuilder步骤同上。

1. 无需使用 CEL 创建用于 CRD 验证的 Webhook
2. 我们不验证此任务中的特定字段。我们要保护整个对象及其所有后续字段
3. 实现我们目标的最佳方法是为整个 kind struct 对象嵌入 kubebuilder 标记注释
4. CEL 不可变验证检查如下所示

// +kubebuilder:validation:XValidation:rule="self == oldSelf", message="Value is immutable"

1. 上面的 CEL 格式的标记注释被 controller-gen 解析生成 CRD。CEL 规则中的XValidation字段转换为x-Kubernetes-validationCRD 中的
2. 上面指定的验证规则确保新请求对象 ( self) 始终等于旧部署对象 ( oldSelf)。如果有任何不同，CEL 验证会抛出一条错误消息
3. 使用 CEL 可以对每个字段进行更精细的验证。但我们的演示用例不需要它
4. 在这种情况下，我们创建了ImmutableKind结构并希望确保它的 CR 是不可变的。将上述验证标记注释添加到结构中
5. 该ImmutableKind结构存在于api/v1/immutablekind_types.go

// +kubebuilder:validation:XValidation:rule="self == oldSelf", message="Value is immutable"
type ImmutableKind struct {
 metav1.TypeMeta   `json:",inline"`
 metav1.ObjectMeta `json:"metadata,omitempty"`

 Spec   ImmutableKindSpec   `json:"spec,omitempty"`
 Status ImmutableKindStatus `json:"status,omitempty"`
}

创建crd并安装验证

make manifests
make install
kubectl apply -f ./config/samples/validate_v1_immutablekind.yaml

配置文件如下：

apiVersion: validate.superops.com/v1
kind: ImmutableKind
metadata:
labels:
 app.kubernetes.io/name: immutablekind
 app.kubernetes.io/instance: immutablekind-sample
 app.kubernetes.io/part-of: immutable-validation-webhook
 app.kuberentes.io/managed-by: kustomize
 app.kubernetes.io/created-by: immutable-validation-webhook
 mutate: maybe
name: immutablekind-sample
spec:
# TODO(user): Add fields here

1. 为了验证不变性功能，让我们编辑已部署的 CR。
2. 为了简单起见，让我们从上面的代码片段中删除所有标签，然后immutablekind-sample再次部署 CR。

 echo "apiVersion: validate.superops.com/v1
kind: ImmutableKind
metadata:
  name: immutablekind-sample" | kubectl apply -f-

对象更新请求将失败

总结

仅一行标记注释，消除了创建 webhook 部署、证书管理/证书管理器部署要求等的所有复杂性。

当然了这只是冰山一角。我们可以通过 CEL 和 Kubernetes 的结合实现许多其他的事情。您可以查看参考资料以进一步使用。