作者 | 陳顯鷺  阿里巴巴高階技術專家

本文整理自《CNCF x Alibaba 雲原生技術公開課》第 23 講，點選“閱讀原文”直達課程頁面。<br>關注“阿里巴巴雲原生”公眾號，回覆關鍵詞**“入門”**，即可下載從零入門 K8s 系列文章 PPT。

**導讀**：在 Kubernetes 裡面， API 程式設計正規化也就是 Custom Resources Definition(CRD)。我們常講的 CRD，其實指的就是使用者自定義資源。為什麼會存在使用者自定義資源問題呢？本文將會從其需求來源出發，對此概念進行逐步深入的講解。

# 一、需求來源
首先我們先來看一下 API 程式設計正規化的需求來源。

在 Kubernetes 裡面， API 程式設計正規化也就是 Custom Resources Definition(CRD)。我們常講的 CRD，其實指的就是使用者自定義資源。

為什麼會有使用者自定義資源問題呢？

隨著 Kubernetes 使用的越來越多，使用者自定義資源的需求也會越來越多。而 Kubernetes 提供的聚合各個子資源的功能，已經不能滿足日益增長的廣泛需求了。使用者希望提供一種使用者自定義的資源，把各個子資源全部聚合起來。但 Kubernetes 原生資源的擴充套件和使用比較複雜，因此誕生了使用者自定義資源這麼一個功能。

# 二、用例解讀

## CRD 的一個例項
我們首先具體地介紹一下 CRD 是什麼。

CRD 功能是在 Kubernetes 1.7 版本被引入的，使用者可以根據自己的需求新增自定義的 Kubernetes 物件資源。值得注意的是，這裡使用者自己新增的 Kubernetes 物件資源都是 native 的、都是一等公民，和 Kubernetes 中自帶的、原生的那些 Pod、Deployment 是同樣的物件資源。在 Kubernetes 的 API Server 看來，它們都是存在於 etcd 中的一等資源。

同時，自定義資源和原生內建的資源一樣，都可以用 kubectl  來去建立、檢視，也享有 RBAC、安全功能。使用者可以開發自定義控制器來感知或者操作自定義資源的變化。

下面我們來看一個簡單的 CRD 例項。下圖是一個 CRD 的定義。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/7e83656cdf154291999a5a4163a92372.png)

首先最上面的 apiVersion 就是指 CRD 的一個 apiVersion 宣告，宣告它是一個 CRD 的需求或者說定義的 Schema。

kind 就是 CustomResourcesDefinition，指 CRD。name 是一個使用者自定義資源中自己自定義的一個名字。一般我們建議使用“頂級域名.xxx.APIGroup”這樣的格式，比如這裡就是 foos.samplecontroller.k8s.io。

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

- 圖中的 group 為 samplecontroller.k8s.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 的一個例項。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/cfa73d286b5f4328b34107c733e6dd86.png)

- 它的 apiVersion 就是我們剛才所定義的 samplecontroller.k8s.io/v1alpha1；
- kind 就是 Foo；
- metadata 的 name 就是我們這個例子的名字；
- 這個例項中 spec 欄位其實沒有在 CRD 的 Schema 中定義，我們可以在 spec 中根據自己的需求來寫一寫，格式就是 key:value 這種格式，比如圖中的 deploymentName: example-foo, replicas: 1。當然我們也可以去做一些檢驗或者狀態資源去定義 spec 中到底包含什麼。

## 帶有校驗的 CRD
我們來看一個包含校驗的 CRD 定義：
![3.png](https://ucc.alicdn.com/pic/developer-ecology/b1ff49141cd94e79a01a513c7e13fe11.png)

可以看到這個定義更加複雜了，validation 之前的欄位我們就不再贅述了，單獨看校驗這一段。

它首先是一個 openAPIV3Schema 的定義，spec 中則定義了有哪些資源，以 replicas 為例，這裡將 replicas 定義為一個 integer 的資源，最小值為 1，最大值是 10。那麼，當我們再次使用這個 CRD 的時候，如果我們給出的 replicas 不是 int 值，或者去寫一個 -1，或者大於 10 的值，這個 CRD 物件就不會被提交到 API Server，API Server 會直接報錯，告訴你不滿足所定義的引數條件。

## 帶有狀態欄位的 CRD
再來看一下帶有狀態欄位的 CRD 定義。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/1bea909664bb40a38b155665010ca5a9.png)

我們在使用一些 Deployment 或 Pod 的時候，部署完成之後可能要去檢視當前部署的狀態、是否更新等等。這些都是透過增加狀態欄位來實現的。另外，Kubernetes 在 1.12 版本之前，還沒有狀態欄位。

狀態實際上是一個自定義資源的子資源，它的好處在於，對該欄位的更新並不會觸發 Deployment 或 Pod 的重新部署。我們知道對於某些 Deployment 和 Pod，只要修改了某些 spec，它就會重新建立一個新的 Deployment 或者 Pod 出來。但是狀態資源並不會被重新建立，它只是用來回應當前 Pod 的整個狀態。上圖中的 CRD 宣告中它的子資源的狀態非常簡單，就是一個 key:value 的格式。在 "{}" 裡寫什麼，都是自定義的。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/2b1f72af85ed474b9250e07cb5c69bb5.png)

以一個 Deployment 的狀態欄位為例，它包含 availableReplicas、當前的狀態（比如更新到第幾個版本了、上一個版本是什麼時候）等等這些資訊。在使用者自定義 CRD 的時候，也可以進行一些複雜的操作來告訴別的使用者它當前的狀態如何。

# 三、操作演示
下面我們來具體演示一下 CRD。

我們這裡有兩個資源：crd.yaml 和 example-foo.yaml。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/d925f86d95d64fb3ad87cd80b3dad157.png)

首先建立一下這個 CRD 的 Schema 讓我們的 Kubernetes Server 知道該 CRD 到底是什麼樣的。建立的方式非常簡單，就是 "kuberctl create -f crd.yaml"。
![7.png](https://ucc.alicdn.com/pic/developer-ecology/6650372f2e654d8d9e76c48639cc3844.png)

透過 "kuberctl get crd" 可以看到剛才的 CRD 已經被建立成功了。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/26945de772954dc0b9747a292438ff15.png)

這個時候我們就可以去建立對應的資源 "kuberctl create -f example-foo.yaml"：

![9.png](https://ucc.alicdn.com/pic/developer-ecology/5e36182569f34f36af6bef120fa775f4.png)

下面來看一下它裡面到底有什麼東西 "kubectl get foo example-foo -o yaml" :

![10.png](https://ucc.alicdn.com/pic/developer-ecology/15ff425e9e1046fa9c872e2d0c7ce2aa.png)

可以看到它是一個 Foo 的資源，spec 就是我們剛才所定義的，被選中的部分是基本上所有的 Kubernetes 的 metadata 資源中都會有的。因此，建立該資源和我們正常建立一個 Pod 的區別並不大，但是這個資源不是一個 Pod，也不是 Kubernetes 本身內建的資源，這就是一個我們自己建立的資源。從使用方式和使用體驗上來說，和 Kubernetes 內建資源的使用幾乎一致。

# 四、架構設計

## 控制器概覽
只定義一個 CRD 其實沒有什麼作用，它只會被 API Server 簡單地計入到 etcd 中。如何依據這個 CRD 定義的資源和 Schema 來做一些複雜的操作，則是由 Controller，也就是控制器來實現的。<br> <br>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 的功能。

## 控制器工作流程概覽

![11.png](https://ucc.alicdn.com/pic/developer-ecology/15bb4cdf9e1a41eca64470f54a7eef68.png)

這裡以 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 從佇列中拿到一個物件之後，就會去做相應的操作。

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

![12.png](https://ucc.alicdn.com/pic/developer-ecology/0911ea16df714449bbf1c21ab582dda5.png)

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

一個函式一般會有多個 Worker。多個 Worker 的意思是說比如同時有好幾個物件進來，那麼這個 Controller 可能會同時啟動五個、十個這樣的 Worker 來並行地執行，每個 Worker 可以處理不同的物件例項。

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

# 五、本文總結
本文的主要內容就到此為止了，這裡為大家簡單總結一下：

- CRD 是 Custom Resources Definition 的縮寫，也就是使用者自定義資源，使用者可以使用這個功能擴充套件自己的Kubernetes 原生資源資訊；
- CRD 和普通的 Kubernetes 資源一樣，都可以受 RBAC 許可權控制,並且支援 status 狀態欄位；
- CRD-controller 也就是 CRD 控制器，能夠實現使用者自行編寫，並且解析 CRD 並把它變成使用者期望的狀態。

![直播海報.png](https://ucc.alicdn.com/pic/developer-ecology/289017e144f54013b0bc1679f7cb2698.png)

> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

從零開始入門 K8s | Kubernetes API 程式設計正規化

相關文章