（轉）如何使用 CRD 拓展 Kubernetes 集羣

https://blog.ihypo.net/15642142854314.html

在 6 月底 KubeCon 回來以後，就打算寫幾篇關於 CRD 的文章，還在 Twitter 上給人作了些許改進 CRD 相關文檔的承諾，零零碎碎的事不少，直到如今纔有時間落筆。不過在這一個多月裏，我作了一個關於 CRD 的內部分享，兩個 CRD Demo，向同事、客戶數人解釋 CRD 是什麼東西，反而讓我對這個東西更加的清晰。

我會分兩到三篇文章介紹 CRD，這是第一篇，簡單聊一下什麼是 CRD。

太長不看版：

CRD 自己是 Kubernetes 的一種資源，容許咱們本身自定義新的資源類型
除了 CRD 咱們還要提供一個 controller 以實現本身的邏輯
CRD 容許咱們基於已有的 Kube 資源，拓展集羣能力
CRD 可使咱們本身定義一套成體系的規範，自造概念
什麼是 CRD
CRD 自己是一種 Kubernetes 內置的資源類型，是 CustomResourceDefinition 的縮寫，能夠經過 kubectl get 命令查看集羣內定義的 CRD 資源。

kubectl get crd

NAME CREATED AT
apps.app.o0w0o.cn 2019-07-25T07:02:47Z
microservices.app.o0w0o.cn 2019-07-25T07:02:47Z
當和人聊 CRD 聊多了的以後，發現你們對 CRD 有一些常見的誤區，所以，有些概念須要提早明確：

在 Kubernetes，全部的東西都叫作資源（Resource），就是 Yaml 裏 Kind 那項所描述的
但除了常見的 Deployment 之類的內置資源以外，Kube 容許用戶自定義資源（Custom Resource），也就是 CR
CRD 其實並非自定義資源，而是咱們自定義資源的定義（來描述咱們定義的資源是什麼樣子）
對於一個 CRD 來講，其本質就是一個 Open Api 的 schema，就像 Kuber Blog 的一篇文章（https://kubernetes.io/blog/2019/06/20/crd-structural-schema/ ）講到的，不管 R 仍是 CR 都須要 Yaml 來描述，可是，如何確保 Yaml 描述的資源是規範的、合法的，那就是 schema 要作的事情，CRD 就其功能來說，就是想集羣註冊一種新資源，並告知 ApiServer，這種資源怎麼怎麼被合法的定義。

控制器模式
在具體講 CRD 以前先簡單講解一下控制器模式。對 Kubernetes 有過了解的就知道，咱們能夠經過建立 Deployment 來管理 Pod，而其實 Deployment 並無直接建立 Pod，而是 Deployment 管理 RS，而 RS 管理 Pod，這其實就是控制器模式。

控制器模式容許基於已有的資源定義更高階的控制器，來實現更復雜的能力，固然，具體的細節要更復雜，推薦我司楊老溼的文章 《淺析 Kubernetes 控制器的工做原理》（https://www.yangcs.net/posts/a-deep-dive-into-kubernetes-controllers/ ）

CRD 能作什麼
通常狀況下，咱們利用 CRD 所定義的 CR 就是一個新的控制器，咱們能夠自定義控制器的邏輯，來作一些 Kubernetes 集羣原生不支持的功能。

拿一個具體的例子來說，我用 Kubebulder 建立了一個簡單的 CRD（https://github.com/Coderhypo/KubeService ），嘗試在 Kubernetes 集羣內置微服務管理。

我建立了兩種資源，一個叫 App，負責管理整個應用的生命週期，另外一個叫 MicroService，負責管理微服務的生命週期。

具體的邏輯結構能夠這樣理解：

App 能夠直接管理多個 MicroService，而且，每一個 MicroService 支持多個版本，得益於控制器模式，MicroService 能夠爲每一個版本建立一個 Deployment，使得能夠多個版本同時被部署。

若是隻是管理應用的部署未免有些簡單，MicroService 支持爲每一個微服務建立 Service 和 Ingress，以實現四層負載均衡和七層負載均衡：

而且，若是開啓負載均衡的功能，MicroService 將爲每一個版本都建立一個 Service，所以，一個服務將擁有 n + 1 個 SVC，其中 n 是每一個版本都擁有一個，而額外的 1 是微服務建立以後就不會再變更（名字和 clusterIP）的 SVC，而這個 SVC 的 Selector 會始終保持和 CurrentVersion 的 SVC 一致。

換句話講，有一個穩定的 SVC 能夠對其餘組件提供當前版本的服務，而其餘組件也有途徑訪問到特定版本的服務。這個 SVC + CurrentVersion 就很是輕鬆的實現了藍綠髮布的能力。

除了 SVC 外，MicroService 還基於 nginx ingress controller 的能力，實現了灰度發佈的功能，同過修改 LoadBalance 裏 canary 的配置，能夠實現按 比例 / header / cookie 進行灰度發佈。

這個例子中，App 和 MicroService 並無創造 「新能力」，而只是經過對 Kubernetes 已有資源進行組合，就實現了新功能。

可是除了快速對微服務進行藍綠、灰度以外，App 和 MicroService 還有沒有新的價值呢，另外一個看不到的價值就是管理的標準化，以前對應用下的任何操做都須要被翻譯爲 「Kube 語言」，即對那個 Deployment 或者 Ingress 管理，如今能夠有一個統一的入口規範化管理。

總結
以一個簡單的小 Demo 來描述什麼是 CRD 很容易以偏概全，就我目前的思考，我認爲 CRD 有兩個很是重要的能力：

首先是功能上，CRD 使得 Kubernetes 已有的資源和能力變成了樂高積木，咱們很輕鬆就能夠利用這些積木拓展 Kubernetes 原生不具有的能力。

其次是產品上，基於 Kubernetes 作的產品沒法避免的須要讓咱們將產品術語向 Kube 術語靠攏，好比一個服務就是一個 Deployment，一個實例就是一個 Pod 之類。可是 CRD 容許咱們本身基於產品建立概念（或者說資源），讓 Kube 已有的資源爲咱們的概念服務，這可使產品更專一與解決的場景，而不是如何思考如何將場景應用到 Kubernetes。