Kubernetes CRD

CRD

GitHub地址：https://github.com/kubernetes-sigs/kubebuilder

Kubernetes 里资源类型有以下所示：

上述资源类型能够知足大多数分布式系统部署的需求

可是在不一样应用业务环境下，对于平台可能有一些特殊的需求，这些需求能够抽象为 Kubernetes 的扩展资源，而 Kubernetes 的 CRD (CustomResourceDefinition)为这样的需求提供了轻量级的机制，保证新的资源的快速注册和使用。

举个栗子：

我但愿在 kubernetes 中有 KafkaSource 这个资源， 资源示例 kafka-source.yaml以下：

咱们但愿在执行 kubectl create -f kafka-source.yaml 以后，在 kubernetes 里会启动一个 pod，这个 pod 会作下面的事情：

• 它会从地址是 my-cluster-kafka-bootstrap.kafka:9092，topic 是 knative- demo-topic 的 kafka 机群里读取消
• 将读到的消息，发送到 kubernetes 的一个 Service 去执行

Kuberentes 里并无 KafkaSource 这个资源可使用，因此直接执行 kubectl create -f kafka-source.yaml 的时候，会出错。可是 kubernetes 提供的 CRD 机制可让咱们轻松的把上述功能添加到 kubernetes 里。

CRD 机制以上述 Kafkasource 为例，以下：

1. 须要把 KafkaSource 这个资源注册到 kubernetes 中，这样 kubernetes 才会知道这个资源
2. 注册以后，还须要开发一个 controller 组件，来监听用户是否建立了 KafkaSource，也就是部署、更新或者删除如上的 yaml 文件。
3. Controller 监听到有用户建立了 KafkaSource，就会建立一个 pod 来作相应的工做

概括一下就是：

用户向 Kubernetes API 服务注册一个带特定 schema 的资源，并定义相关 API

1. 将扩展资源的数据存储到 Kubernetes 的 etcd 集群
2. 借助 Kubernetes 提供的 controller 模式开发框架，实现新的 controller，并借助 APIServer 监听 etcd 集群关于该资源的状态并定义状态变化的处理逻辑

具体流程以下图：

在这个流程里，大部分是 client-go 为用户提供的框架和逻辑，能够直接使用，灰色的 AddFunc等是用户须要实现的关于该扩展资源的业务逻辑。informer 会借助 APIServer 跟踪该扩展资源定义的变化，一旦被触发就会调用回调函数，并把变动的具体内容放到 Workqueue 中，自定义 controller 里面的 worker会获取Workqueue 里面内容，并进行相应的业务处理。

注册使用 CustomResourceDefinition，以以下 kafkasource 的一个简化版本为例，kubectl create -f kafkasource-customresourcedefinition.yaml:

可能这时候，你们仍是不知道如何进行开发，就算好不容易搞清楚了，感受开发也是很复杂的事情，咱们可使用工具-kubebuilder 来作开发，咱们来作一下小的 demo，来看一下 kubebuilder 是如何帮咱们进行开发的。

安装

依赖：docker/go/kubebuilder

https://github.com/kubernetes-sigs/kubebuilder/releases

到相应的网址下载相应的二进制包，解压压缩包，并把二进制包放到系统路径里。接下来咱们一步一步建立一个自定的 CronJob, 这也是一个比较经典的例子：

第一步：建立项目

kubebuilder init --domain tutorial.kubebuilder.io --license apache2 --owner "Authors"

• A license. The reference project uses Apache 2.
• A domain name. This is the unique domain used to identify your project's resources.
• An author name. This is the copyright owner listed in the copyright notice at the top of each source file.

让咱们看一下生成的项目的结构：

go.mod:项目第三方依赖

Makefile:用来构建和部署 controller

PROJECT: metadata

Main.go: 应用执行入口

Config 目录下目前只包含启动在集群里启动controller的文件，还不包含CustomResourceDe nitions, RBAC con guration,and WebhookCon gurations.

config/manager: launch your controllers as pods in the cluster

config/rbac: permissions required to run your controllers under their own service account

main.go 中的 schemeHui 描述 Kinds 的 go types.

到目前这个项目包含：

1. 设置了 flag
2. 初始化了一个 manager，它会跟踪全部的 controller
3. 启动 manager

第二步：建立 API

Groups， Versions and Kinds

kubebuilder create api --group batch --version v1alpha1 --kind SampleSource

讲解一下自动建立的三个文件

接下来咱们看一下，建立好的文件内容,看代码：

api/v1: 只须要修改CronJobSpec和CronJobStatus

+kubebuilder:object:root :表示这是一个Kind

设计 API 的规则：

（1） 变量须要是驼峰，因此须要使用 tag 来标注

（2） 变量的类型也有要求

Numbers: int3二、int64和resource.Quantity(举例：resources requests and limits )

Spec:

• Schedule: 定时
• Template：pod spec

第三步：建立 controller

Controller 是 kubernetes 的核心，它负责保持集群资源实际状态和指望的状态一致（pod 数量之类的的），这个过程叫作 reconciling.

对某个具体的 Kind 进行 reconciling 的部分，叫作 reconciler.

请看代码：

Import 部分......

会为你们仔细讲解

剩下的主要是编码部分，和部署验证部分

......
获取视频+文档