Kubernetes CRD 分享

Kubernetes CRD 分享

本次分享主题《Kubernetes CRD》  Kubernetes CRD 的产生经验分享：举例对比，Kubernetes CRD 的好处Kubernetes CRD 的实战项目案例应用讲解（含代码）

分享时间：2020.3.21日（周六） 21:00-22:00直播地址：https://ke.qq.com/course/1645953?taid=7501899118484865&tuin=31589b0e主讲师：SC曾就职于小米，现就职于 Bat 企业。一直从事 docker 方面的研发工作，最初主要研发基于 Mesos 架构的容器平台，后来转向 Kubernetes 的研发和维护，目前主要基于 Docker 和 K8s 研发其他云计算服务和私有云的建设；具备丰富的 Kubernetes 落地经验。CRDGitHub地址：https://github.com/kubernetes-sigs/kubebuilderKubernetes 里资源类型有如下所示：

上述资源类型可以满足大多数分布式系统部署的需求

但是在不同应用业务环境下，对于平台可能有一些特殊的需求，这些需求可以抽象为  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 为例，如下：

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

归纳一下就是：

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

将扩展资源的数据存储到 Kubernetes 的 etcd 集群借助 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.

到目前这个项目包含：

设置了 flag初始化了一个 manager，它会跟踪所有的 controller启动 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: int32、int64和resource.Quantity(举例：resources requests and limits )

Spec:

Schedule: 定时Template：pod spec

第三步：创建 controller

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

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

请看代码：

Import 部分......

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

......