• Kubernetes CRD 介绍


            CR(Custom Resource)其实就是在 Kubernetes 中定义一个自己的资源类型,是一个具体的 “自定义 API 资源” 实例,为了能够让 Kubernetes 认识这个 CR,就需要让 Kubernetes 明白这个 CR 的宏观定义是什么,也就是需要创建所谓的 CRD(Custom Resource Definition)来表述。

            可能这么说并不是太直观,换个方式表达一下,我们想要创建一个 Pod 的时候,那么会编写一个 YAML 配置,然后前两行一般会这么写:

    1. [root@liqiang.io]# head -2 pod.yaml
    2. apiVersion: v1
    3. kind: Pod

            这里的 Resource 就是 Pod,我们可以它通过在 Kubernetes 中创建一个真实的 Pod,但是这个 Pod 要运行哪些 Container?这些 Container 我们要怎么在 pod.yaml 中定义,这个要怎么知道呢?这就需要有个描述文件用来定义 Pod 这个 Resource 需要具有哪些属性,这些属性的类型是什么,结构是怎样的,这个描述文件就是所谓的 CRD。

            当然,Pod 作为一个内置资源,是没有这种所谓的 CRD 的,这里是作为一个介绍,当我们要创建一个非内置资源的时候,就需要有这么一个叫做 CRD 的描述文件了。

            创建 CRD

            在 Kubernetes 中,CRD 本身也是一种资源,它是 Kubernetes 内部 apiextensions-apiserver 提供的 API Group:apiextensions.k8s.io/v1,注意,这里是 v1 版本,在 Kubernetes 1.16 版本中,CRD 转正了,成为了正式版本 CRD GA,但是,在 v1.16 之前以及 v1.7 以及之后,都是以 v1beta1 的版本存在,所以在编写的时候注意一下你的 Kubernetes 版本。

            自己定义一个 CRD 也需要编写 YAML 文件,这里是我的一个示例,我通过这个 CRD 来定义我的网站 liqiang.io 的管理员的 CR,当我想添加一个管理员的时候,只需要直接添加一个 CR 就可以了:

    1. ---
    2. apiVersion: apiextensions.k8s.io/v1
    3. kind: CustomResourceDefinition
    4. metadata:
    5. name: admins.admin.liqiang.io
    6. spec:
    7. group: admin.liqiang.io
    8. names:
    9. kind: Admin
    10. plural: admins
    11. scope: Namespaced
    12. versions:
    13. - name: v1
    14. served: true
    15. storage: true
    16. schema:
    17. openAPIV3Schema:
    18. description: Admin define the admin user for liqiang.io website.
    19. type: object
    20. properties:
    21. spec:
    22. type: object
    23. properties:
    24. username:
    25. type: string
    26. password:
    27. type: string
    28. email:
    29. type: string

            当写完这个 CRD 的描述文件之后,可以直接通过 kubectl apply 00-admin-crd.yaml 在 Kubernetes 集群中注册 CRD 对象。然后 Kubernetes 中的 kube-apiserver 组件中运行的 apiextensions-apiserver 就会检查对应 CRD 的名字是否合法之类的,当一切检查都 OK 之后,那么就会返回给你创建成功的状态了:

    1. [root@liqiang.io]# kubectl apply -f 00-admin-crd.yaml
    2. customresourcedefinition.apiextensions.k8s.io/admins.admin.liqiang.io created
    3. k get crds
    4. NAME CREATED AT
    5. admins.admin.liqiang.io 2019-11-23T06:52:23Z

            内部的流程是这样的:

            操作 CRD

            现在在 Kubernetes 中已经多了一种新的资源叫做 admins.admin.liqiang.io,可以使用它来定义系统的管理员了,这里我就添加一个:

            记得,需要 apply 一下:

    1. [root@liqiang.io]# kubectl apply -f 01-admin-cr.yaml
    2. admin.admin.liqiang.io/liuliqiang created
    3. [root@liqiang.io]# kubectl get admins.admin.liqiang.io
    4. NAME AGE
    5. liuliqiang 117s

            现在就创建成功了。然后,不要了,那就删除掉,删除也是很简单的:

    1. [root@liqiang.io]# kubectl delete admins.admin.liqiang.io liuliqiang
    2. admin.admin.liqiang.io "liuliqiang" deleted
    3. [root@liqiang.io]# kubectl get admins.admin.liqiang.io
    4. No resources found in default namespace.

            这个新建和删除 Admin 的过程虽然用得挺简单,但是,事实上,他们除了把 Kubernetes 当作一个 DB 之外,没有太多的实际价值。他们更多的价值体现在我后续介绍的 Controller 和 Operator 之上。所以,管理 CRD 的定义以及使用的基本内容就是这么多了,非常简单。

            其他笔记

            Kubectl 发现机制

            在我创建完 CRD 之后,kubectl 会通过 API 服务器的 discovery information 来查找关于新资源的信息,下面展示当使用 kubectl 获取一个 CR 时,内部的流程:

            这个过程是通过 discovery RESTMapper 实现的,关于 RESTMapper 我在后面会继续介绍。

            校验 CR

            创建资源的时候,肯定不是任由我们随意得编写 YAML 声明文件,当提交给 Kubernetes 之后,Kubernetes 会对我们提交得声明文件进行校验,从前边 CRD 的定义中可以看到,CRD 是基于 OpenAPI v3 schema 进行的。

            同时也可以看到,这种校验是比较初级的,比较简略的。如果想要实现更加复杂的校验,那么可以通过 Kubernetes 的 admission webhook 来实现,这个在我介绍 Istio 的时候有介绍过,如果没印象,不妨找来看看。

            Adminssion webhook 的内部校验流程是这样的:

            简称和属性

            当我输入 kubectl api-resources 的时候,可以看到我定义的 CRD 和一些内置的 Resource 还是有一些区别的,例如内置的 Service 有简写: svc,那么 CRD 是否可以有简写,答案是肯定的:

            如果通过 kubectl get all 来列举所有的资源,然后会发现并不会看到自己的 CRD,如果想要让自己的 CRD 对应的 CR 出现在 get all 中,那么可以在 CRD 的声明中加入 categories 属性:

            自定义列

            当我用 kubectl get admins.admin.liqiang.io 查看 CR 的时候,只能看到简单的 NAME 和 AGE,如果需要看到更多该怎么处理:

            子资源

            We briefly mentioned subresources in “Status Subresources: UpdateStatus”. Subresources are special HTTP endpoints, using a suffix appended to the HTTP path of the normal resource. For example, the pod standard HTTP path is /api/v1/namespace/namespace/pods/name. Pods have a number of subresources, such as /logs, /portforward, /exec, and /status.

  • 相关阅读:
    Linux网络通信(线程池和线程池版本的服务器代码)
    盘点 JavaScript 中类的继承
    使用爬虫代码获得深度学习目标检测或者语义分割中的图片。
    【python】内置函数——isinstance()/issubclass()判断参数1是否是参数2类型
    YOLOv8改进实战 | 更换损失函数之MPDIOU(2023最新IOU)篇
    相似度系列-3:传统方法ROUGE ROUGE: A Package for Automatic Evaluation of Summaries
    【多目标追踪算法】多目标跟踪评价指标
    ctk插件框架,如何实现停止插件时,停止插件注册的服务?
    「前端+鸿蒙」核心技术HTML5+CSS3(十三)
    2023-09-27 Cmake 编译 OpenCV+Contrib 源码通用设置
  • 原文地址:https://blog.csdn.net/qq_19734597/article/details/133992537