Kubernetes CRD 系列：CRD 介绍

概述

本文是承接 Kubernetes 入门系列之后的非入门系列，在这个系列中，我会介绍 Kubernetes 中的 CRD 以及相关的 Controller 和 Operator。如果对于 Kubernetes 尚不太熟悉，我建议可以先回顾一下 Kubernetes 入门系列：

因为这个系列将不再介绍基础知识，而是专注于 CRD 相关的内容进行介绍，同时，因为我对 Kubernetes CRD 和 Controller 开发的基础知识都是从 <Promgraming Kubernetes> 这本书中学习来的，所以，在这个系列，不少内容都可能会来自于我的读书笔记，但是，我还会加上不少个人的见解和实践（大概会占比 50% 左右）。

同时需要注意的是这个系列是在 Kubernetes 1.16 的版本之上进行介绍的，因为 1.16 正式 GA 了 CRD，所有对比 1.16 之前的版本，CRD 的定义和使用有一些区别，我会在系列的最后一篇中进行介绍。如果在跟着本系列的验证过程中出现异常，请注意检查一下集群的版本（kubectl get nodes 即可）！

Kubernetes CRD 系列之 CRD 介绍

声明式编程

在 Kubernetes 中我们使用 Deployment、DamenSet，StatefulSet 来管理应用 Workload，使用 Service，Ingress 等来管理应用的访问方式，使用 ConfigMap 和 Secret 来管理应用配置。在集群中，对这些资源的创建，更新，删除的动作都会被转换为事件(Event)，Kubernetes 的 Controller Manager 负责监听这些事件并触发相应的任务来满足用户的期望。这种方式我们称为声明式，用户只需要关心应用程序的最终状态，其它的都通过 Kubernetes 来帮助我们完成，通过这种方式可以大大简化应用的配置管理复杂度。

对应的，当我们对 Kubernetes 的使用逐渐加深之后，会发现这些默认的 Controller 和资源不足以支撑我们的系统，例如就拿 Prometheus Operator 来说，要想实现横向扩展并不容易；还有拿 Nginx Ingress 来说，要想实现截流器也并不容易。对于一些非通用的特性，Kubernetes 提供了一种扩展性的支撑方式，其实就是所谓的 CRD 和 Controller（Operator）。

CRD

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

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

[[email protected]]# head -2 pod.yaml
apiVersion: v1
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 就可以了：

---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: admins.admin.liqiang.io
spec:
  group: admin.liqiang.io
  names:
    kind: Admin
    plural: admins
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          description: Admin define the admin user for liqiang.io website.
          type: object
          properties:
            spec:
              type: object
              properties:
                username:
                  type: string
                password:
                  type: string
                email:
                  type: string

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

[[email protected]]#  kubectl apply -f 00-admin-crd.yaml
customresourcedefinition.apiextensions.k8s.io/admins.admin.liqiang.io created
k get crds
NAME                            CREATED AT
admins.admin.liqiang.io         2019-11-23T06:52:23Z

内部的流程是这样的：

操作 CRD

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

记得，需要 apply 一下：

[[email protected]]# kubectl apply -f 01-admin-cr.yaml 
admin.admin.liqiang.io/liuliqiang created
[[email protected]]#  kubectl get admins.admin.liqiang.io 
NAME         AGE
liuliqiang   117s

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

[[email protected]]#  kubectl delete admins.admin.liqiang.io liuliqiang 
admin.admin.liqiang.io "liuliqiang" deleted
[[email protected]]#  kubectl get admins.admin.liqiang.io
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.

格物致知

All Posts