CRD 概述

CR（Custom Resource）其實就是在 Kubernetes 中定義一個自己的資源類型，是一個具體的 “自定義 API 資源” 實例，為了能夠讓 Kubernetes 認識這個 CR，就需要讓 Kubernetes 明白這個 CR 的宏觀定義是什么，也就是需要創建所謂的 CRD（Custom Resource Definition）來表述。

可能這么說并不是太直觀，換個方式表達一下，我們想要創建一個 Pod 的時候，那么會編寫一個 YAML 配置，然后前兩行一般會這么寫：

[root@liqiang.io]# head -2 pod.yamlapiVersion: v1kind: Pod

這里的 Resource 就是 Pod，我們可以它通過在 Kubernetes 中創建一個真實的 Pod，但是這個 Pod 要運行哪些 Container？這些 Container 我們要怎么在 pod.yaml 中定義，這個要怎么知道呢？這就需要有個描述文件用來定義 Pod 這個 Resource 需要具有哪些屬性，這些屬性的類型是什么，結構是怎樣的，這個描述文件就是所謂的 CRD。

當然，Pod 作為一個內置資源，是沒有這種所謂的 CRD 的，這里是作為一個介紹，當我們要創建一個非內置資源的時候，就需要有這么一個叫做 CRD 的描述文件了。

1. 操作CRD

1.1 創建 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.ionames:kind: Adminplural: adminsscope: Namespacedversions:- name: v1served: truestorage: trueschema:openAPIV3Schema:description: Admin define the admin user for liqiang.io website.type: objectproperties:spec:type: objectproperties:username:type: stringpassword:type: stringemail:type: string

• apiVersion 就是指 CRD 的一個 apiVersion 聲明，聲明它是一個 CRD 的需求或者說定義的 Schema。

• kind 就是 CustomResourcesDefinition，指 CRD。

• metadata.name 是一個用戶自定義資源中自己自定義的一個名字。一般我們建議使用“頂級域名.xxx.APIGroup”這樣的格式，比如這里就是 admins.admin.liqiang.io，APIGroup對應spec.group標簽，值為 “admin.liqiang.io” 。

• spec 用于指定該 CRD 的 group、version。比如在創建 Pod 或者 Deployment 時，它的 group 可能為 apps/v1 或者 apps/v1beta1 之類，這里我們也同樣需要去定義 CRD 的 group。

  • 圖中的 group 為 admin.liqiang.io；
  • verison 為 v1alpha1；
  • names 指的是它的 kind 是什么，比如 Deployment 的 kind 就是 Deployment，Pod 的 kind 就是 Pod，這里的 kind 被定義為了 Foo；
  • plural 字段就是一個昵稱，比如當一些字段或者一些資源的名字比較長時，可以用該字段自定義一些昵稱來簡化它的長度；
  • scope 字段表明該 CRD 是否被命名空間管理。比如 ClusterRoleBinding 就是 Cluster 級別的。再比如 Pod、Deployment 可以被創建到不同的命名空間里，那么它們的 scope 就是 Namespaced 的。這里的 CRD 就是 Namespaced 的。

當寫完這個 CRD 的描述文件之后，可以直接通過 kubectl apply 00-admin-crd.yaml 在 Kubernetes 集群中注冊 CRD 對象。然后 Kubernetes 中的 kube-apiserver 組件中運行的 apiextensions-apiserver 就會檢查對應 CRD 的名字是否合法之類的，當一切檢查都 OK 之后，那么就會返回給你創建成功的狀態了：

[root@liqiang.io]#  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

內部的流程是這樣的：

1.2 操作 CRD

現在在 Kubernetes 中已經多了一種新的資源叫做 admins.admin.liqiang.io，可以使用它來定義系統的管理員了，這里我就添加一個：

記得，需要 apply 一下：

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

現在就創建成功了。然后，不要了，那就刪除掉，刪除也是很簡單的：

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

這個新建和刪除 Admin 的過程雖然用得挺簡單，但是，事實上，他們除了把 Kubernetes 當作一個 DB 之外，沒有太多的實際價值。他們更多的價值體現在我后續介紹的 Controller 和 Operator 之上。所以，管理 CRD 的定義以及使用的基本內容就是這么多了，非常簡單。

2. 其他筆記

2.1 Kubectl 發現機制

在我創建完 CRD 之后，kubectl 會通過 API 服務器的 discovery information 來查找關于新資源的信息，下面展示當使用 kubectl 獲取一個 CR 時，內部的流程：

這個過程是通過 discovery RESTMapper 實現的，關于 RESTMapper 我在后面會繼續介紹。

2.2 校驗 CR

創建資源的時候，肯定不是任由我們隨意得編寫 YAML 聲明文件，當提交給 Kubernetes 之后，Kubernetes 會對我們提交得聲明文件進行校驗，從前邊 CRD 的定義中可以看到，CRD 是基于 OpenAPI v3 schema 進行的。

同時也可以看到，這種校驗是比較初級的，比較簡略的。如果想要實現更加復雜的校驗，那么可以通過 Kubernetes 的 admission webhook 來實現，這個在我介紹 Istio 的時候有介紹過，如果沒印象，不妨找來看看。

Adminssion webhook 的內部校驗流程是這樣的：

2.3 簡稱和屬性

當我輸入 kubectl api-resources 的時候，可以看到我定義的 CRD 和一些內置的 Resource 還是有一些區別的，例如內置的 Service 有簡寫： svc，那么 CRD 是否可以有簡寫，答案是肯定的：

如果通過kubectl get all來列舉所有的資源，然后會發現并不會看到自己的 CRD，如果想要讓自己的 CRD 對應的 CR 出現在 get all 中，那么可以在 CRD 的聲明中加入 categories 屬性：

3. 架構設計

3.1 控制器概覽

只定義一個 CRD 其實沒有什么作用，它只會被 API Server 簡單地計入到 etcd 中。如何依據這個 CRD 定義的資源和 Schema 來做一些復雜的操作，則是由 Controller，也就是控制器來實現的。

Controller 其實是 Kubernetes 提供的一種可插拔式的方法來擴展或者控制聲明式的 Kubernetes 資源。它是 Kubernetes 的大腦，負責大部分資源的控制操作。以 Deployment 為例，它就是通過 kube-controller-manager 來部署的。

比如說聲明一個 Deployment 有 replicas、有 2 個 Pod，那么 kube-controller-manager 在觀察 etcd 時接收到了該請求之后，就會去創建兩個對應的 Pod 的副本，并且它會去實時地觀察著這些 Pod 的狀態，如果這些 Pod 發生變化了、回滾了、失敗了、重啟了等等，它都會去做一些對應的操作。

所以 Controller 才是控制整個 Kubernetes 資源最終表現出來的狀態的大腦。

用戶聲明完成 CRD 之后，也需要創建一個控制器來完成對應的目標。比如之前的 Foo，它希望去創建一個 Deployment，replicas 為 1，這就需要我們創建一個控制器用于創建對應的 Deployment 才能真正實現 CRD 的功能。

控制器工作流程概覽

這里以 kube-controller-manager 為例。

如上圖所示，左側是一個 Informer，它的機制就是通過去 watch kube-apiserver，而 kube-apiserver 會去監督所有 etcd 中資源的創建、更新與刪除。Informer 主要有兩個方法：一個是 ListFunc；一個是 WatchFunc。

• ListFunc 就是像 “kuberctl get pods” 這類操作，把當前所有的資源都列出來；
• WatchFunc 會和 apiserver 建立一個長鏈接，一旦有一個新的對象提交上去之后，apiserver 就會反向推送回來，告訴 Informer 有一個新的對象創建或者更新等操作。

Informer 接收到了對象的需求之后，就會調用對應的函數（比如圖中的三個函數 AddFunc, UpdateFunc 以及 DeleteFunc），并將其按照 key 值的格式放到一個隊列中去，key 值的命名規則就是 “namespace/name”，name 就是對應的資源的名字。比如我們剛才所說的在 default 的 namespace 中創建一個 foo 類型的資源，那么它的 key 值就是 “default/example-foo”。Controller 從隊列中拿到一個對象之后，就會去做相應的操作。

下圖就是控制器的工作流程。

首先，通過 kube-apiserver 來推送事件，比如 Added, Updated, Deleted；然后進入到 Controller 的 ListAndWatch() 循環中；ListAndWatch 中有一個先入先出的隊列，在操作的時候就將其 Pop() 出來；然后去找對應的 Handler。Handler 會將其交給對應的函數（比如 Add(), Update(), Delete()）。

一個函數一般會有多個 Worker。多個 Worker 的意思是說比如同時有好幾個對象進來，那么這個 Controller 可能會同時啟動五個、十個這樣的 Worker 來并行地執行，每個 Worker 可以處理不同的對象實例。

工作完成之后，即把對應的對象創建出來之后，就把這個 key 丟掉，代表已經處理完成。如果處理過程中有什么問題，就直接報錯，打出一個事件來，再把這個 key 重新放回到隊列中，下一個 Worker 就可以接收過來繼續進行相同的處理。

參考

Kubernetes CRD 介紹
從零開始入門 K8s | Kubernetes API 編程范式