CRD 定制化资源声明
CRD和CR解释
CRD(Custom Resource Definition) 本身是一种 Kubernetes 内置的资源类型,顾名思义定制化资源声明,将声明的内容注册到Kubernetes,官方提供一个扩展方式,适配Restful的风格去调用API(apiextensions.k8s.io/v1)进行定制化资源声明,本身是无名字空间的,可在所有名字空间中访问。
CR(Custom Resource)定制化资源,除了kubernetes自带内置的资源,不同场景和业务需要进行扩展,根据CRD声明去创建kubernetes除内置之外的资源,也可称为CRD的实例,这些实例遵循CRD中定义的schema。
总结:CRD无命名空间的限制,CR对CRD有着依赖关系,需要根据CRD的声明对号入座。独立于内建的资源类型之外,如 Pod、Service、Deployment 等,通过定义 CRD,用户可以将自己的应用程序或服务的业务逻辑抽象为 Kubernetes 中的一种资源类型,从而更方便、更一致地进行管理和编排。
CRD用例
如下为官方用例和相关参数解释:官方地址
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
# 名字必需与下面的 spec 字段匹配,并且格式为 '<名称的复数形式>.<组名>'
name: crontabs.stable.example.com
spec:
# 组名称,用于 REST API:/apis/<组>/<版本>
group: stable.example.com
# 列举此 CustomResourceDefinition 所支持的版本
versions:
- name: v1
# 每个版本都可以通过 served 标志来独立启用或禁止
served: true
# 其中一个且只有一个版本必需被标记为存储版本
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
image:
type: string
replicas:
type: integer
# 可以是 Namespaced 或 Cluster
scope: Namespaced
names:
# 名称的复数形式,用于 URL:/apis/<组>/<版本>/<名称的复数形式>
plural: crontabs
# 名称的单数形式,作为命令行使用时和显示时的别名
singular: crontab
# kind 通常是单数形式的驼峰命名(CamelCased)形式。你的资源清单会使用这一形式。
kind: CronTab
# shortNames 允许你在命令行使用较短的字符串来匹配资源
shortNames:
- ct
- apiVersion 就是指 CRD 的一个 apiVersion 声明,声明它是一个 CRD 的需求。
- apiextensions.k8s.io/v1beta1 这个apiversion已经废弃。
- metadata.name 是一个用户自定义资源中自己自定义的一个名字。一般我们建议使用“顶级域
名.xxx.APIGroup”这样的格式,比如这里就是 crontabs.stable.example.com,APIGroup对应spec.group标签,值为 “stable.example.com” ,对象名称必须是合法的 DNS 子域名。 - spec.group定义了 CRD 的 API 组。
- spec.version 指明不同版本,每个版本包含 name(版本名称)、served(是否提供服务,即是否可以创建资源实例)和 storage(是否进行持久化存储)等属性。,可以同时声明,但有优先级区分,对于指定多个版本中的示例,版本排序顺序为 v1,后跟着
v1beta1。 这导致了 kubectl 命令使用 v1 作为默认版本,除非所提供的对象指定了版本。
- v10
- v2
- v1
- v11beta2
- v10beta3
- v3beta1
- v12alpha1
- v11alpha2
- foo1
- foo10
创建操作和验证
1、创建CRD
这里声明一个command的CRD,用途:通过创建不同的CR,不同的shell指令查询不同image启动后的信息。
注意细节
crd.metadata.name: 代表crd name, 必须是 {plural}.{group}
crd.spec.group: 代表 group name ,提供给 REST API : /apis/{group}/{version}
[root@k8s-docker-master ~]# cat crd-test.yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: commands.shell.xinyi.cn
spec:
group: shell.xinyi.cn
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
description: command shell one for list /
type: object
properties:
spec:
type: object
properties:
commandshell:
type: string
image:
type: string
replicas:
type: integer
scope: Namespaced
names:
kind: CommandShell
plural: commands
singular: command
2、生成CRD和查看是否正常创建
[root@k8s-docker-master ~]# kubectl apply -f crd-test.yaml
customresourcedefinition.apiextensions.k8s.io/commands.shell.xinyi.cn created
3、创建CR
[root@k8s-docker-master ~]# cat centos-cr.yaml
apiVersion: "shell.xinyi.cn/v1"
kind: CommandShell
metadata:
name: centos-shell-test
spec:
commandshell: "ls -l /"
image: "docker.io/library/centos:7"
replicas: 1
4、执行yaml生成CR,查看CR资源是否正常
注意查看资源清单是根据CRD的metadata.name的值
官方提供的kind这个key定义(kind 通常是单数形式的驼峰命名(CamelCased)形式。你的资源清单会使用这一形式。)不一定查得到
[root@k8s-docker-master ~]# kubectl apply -f centos-cr.yaml
commandshell.shell.xinyi.cn/centos-shell-test created
[root@k8s-docker-master ~]# kubectl get commands.shell.xinyi.cn
NAME AGE
centos-shell-test 4m34s
5、查看创建定制对象时在 YAML 文件中指定的定制字段 cronSpec 和 image
[root@k8s-docker-master ~]# kubectl get commands.shell.xinyi.cn -o yaml
apiVersion: v1
items:
- apiVersion: shell.xinyi.cn/v1
kind: CommandShell
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"shell.xinyi.cn/v1","kind":"CommandShell","metadata":{"annotations":{},"name":"centos-shell-test","namespace":"default"},"spec":{"commandshell":"ls -l /","image":"docker.io/library/centos:7","replicas":1}}
creationTimestamp: "2025-01-20T08:31:40Z"
generation: 1
name: centos-shell-test
namespace: default
resourceVersion: "287189"
uid: 0ddc3e85-7101-4bf6-866e-f7ebf5bfac57
spec:
commandshell: ls -l /
image: docker.io/library/centos:7
replicas: 1
kind: List
metadata:
resourceVersion: ""