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 部分......

會爲你們仔細講解

剩下的主要是編碼部分，和部署驗證部分

......
獲取視頻+文檔