自定义资源CRD使用介绍
目录
- 介绍
- 定义
介绍
Custom Resource Define简称 CRD,是 Kubernetes(v1.7+)为提高可扩展性,让开发者去自定义资源的一种方式。
CRD 资源可以动态注册到集群中,注册完毕后,用户可以通过 kubectl 来创建访问这个自定义的资源对象,类似于操作 Pod 一样。
不过需要注意的是 CRD 仅仅是资源的定义而已,需要一个对应的控制器去监听 CRD 的各种事件来添加自定义的业务逻辑。
定义
如果说只是对 CRD 资源本身进行 CRUD 操作的话,不需要 Controller 也是可以实现的,相当于就是只有数据存入了 etcd 中,而没有对这个数据的相关操作而已。
比如我们可以定义一个如下所示的 CRD 资源清单文件:
apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: # name 必须匹配下面的spec字段:<plural>.<group> name: foos.crd.example.com # for more information on the below annotation, please see # https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/2337-k8s.io-group-protection/README.md annotations: "api-approved.kubernetes.io": "unapproved, experimental-only; please get an approval from Kubernetes API reviewers if you're trying to develop a CRD in the *.k8s.io or *.kubernetes.io groups" spec: # group 名用于 REST API 中的定义: /apis/<group>/<version> group: crd.example.com # 列出自定义资源的所有 API 版本 versions: - name: v1 # 版本名称,比如v1,v1beta1 served: true # 是否开启通过 REST APIs访问 `/apis/<group>/<version>/...` storage: true # 必须将一个且只有一个版本标记为存储版本 schema: # 定义自定义对象的声明规范 # schema used for validation openAPIV3Schema: type: object properties: spec: type: object properties: deploymentName: type: string replicas: type: integer minimum: 1 maximum: 10 status: type: object properties: availableReplicas: type: integer names: # kind 是 sigular 的一个驼峰形式的定义,在资源清单中会使用 kind: Foo # plural 名字用于 REST API 中的定义:/apis/<group>/<version>/<plural> plural: foos # singular 名称用于 CLI 操作或显示的一个别名 singular: foo # shortNames 相当于缩写形式 shortNames: - fo scope: Namespaced
这个地方的定义和我们定义普通的资源对象比较类似,我们可以随意定义一个自定义的资源对象,但是在创建资源的时候,肯定不是任由我们随意去编写 YAML 文件的,当我们把上面的 CRD 文件提交给 Kubernetes 之后,Kubernetes 会对我们提交的声明文件进行校验,从定义可以看出 CRD 是基于OpenAPI v3 schem进行规范的。
当然这种校验只是对于字段的类型进行校验,比较初级,如果想要更加复杂的校验,这个时候就需要通过 Kubernetes 的 admission webhook 来实现了。关于校验的更多用法,可以前往官方文档查看。
现在我们可以直接使用kubectl来创建这个CRD资源清单:
$ kubectl apply -f crd.example.com_foos.yaml customresourcedefinition.apiextensions.k8s.io/foos.crd.example.com created
这个时候我们可以查看到集群中已经有我们定义的这个CRD资源对象了:
$ kubectl get crd | grep example foos.crd.example.com 2022-05-11T05:28:51Z
这个时候一个新的 namespace 级别的 RESTful API 就会被创建:
/apis/crd/example.com/v1/namespaces/*/foos/...
接着我们就可以使用这个 API 端点来创建和管理自定义的对象,这些对象的类型就是上面创建的 CRD 对象规范中的foo
。
现在在 Kubernetes 集群中我们就多了一种新的资源叫做foos.crd.example.com,我们就可以使用它来定义一个Foo
资源对象了,这个自定义资源对象里面可以包含的字段我们在定义的时候通过schema
进行了规范,比如现在我们来创建一个如下所示的资源清单:
apiVersion: crd.example.com/v1 kind: Foo metadata: name: example-foo spec: deploymentName: example-foo replicas: 1
创建完成后我们就可以用kubectl来管理我们这里创建的Foo对象了,比如:
kubectl get foo NAME AGE example-foo 20m
在使用 kubectl 的时候,资源名称是不区分大小写的,我们可以使用 CRD 中定义的单数或者复数形式以及任何简写。
kubectl get foo example-foo -o yaml apiVersion: crd.example.com/v1 kind: Foo metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"crd.example.com/v1","kind":"Foo","metadata":{"annotations":{},"name":"example-foo","namespace":"default"},"spec":{"deploymentName":"example-foo","replicas":1}} creationTimestamp: "2022-05-11T05:40:38Z" generation: 1 name: example-foo namespace: default resourceVersion: "37605212" uid: 56d5b1d3-f6f9-4106-90c4-a0e3c7d130c0 spec: deploymentName: example-foo replicas: 1
就如上面我们说的,现在我们自定义的资源创建完成了,但是也只是单纯的把资源清单数据存入到了 etcd 中而已,并没有什么其他用处,因为我们没有定义一个对应的控制器来处理相关的业务逻辑。
以上就是自定义资源CRD使用介绍的详细内容,更多关于自定义资源CRD的资料请关注我们其它相关文章!