官方文檔：https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
kubernetes 有兩種機制供用戶擴展API
第一種：CRD，復用Kubernetes的API Server，無須編寫額外的APIServer。用戶只需要定義CRD，並且提供一個CRD控制器，就能通過Kubernetes的API管理自定義資源對象了，同時要求用戶的CRD對象符合API Server的管理規范。
第二種：使用API聚合機制 ，用戶需要編寫額外的API Server，可以對資源進行更細粒度的控制（例如，如何在各API版本之間切換），要求用戶自行處理對多個API版本的支持。
CRD 定義：
CRD 的全稱是 Custom Resource Definition。顧名思義，它指的就是，允許用戶在 Kubernetes 中添加一個跟 Pod、Node 類似的、新的 API 資源類型，即：自定義 API 資源。
Custom resources：
是對K8S API的擴展，代表了一個特定的kubetnetes的定制化安裝。在一個運行中的集群中，自定義資源可以動態注冊到集群中。注冊完畢以后，用戶可以通過kubelet創建和訪問這個自定義的對象，類似於操作pod一樣。
Custom controllers 自定義控制器:
Custom resources可以讓用戶簡單的存儲和獲取結構化數據。只有結合控制器才能變成一個真正的declarative API（被聲明過的API）。控制器可以把資源更新成用戶想要的狀態，並且通過一系列操作維護和變更狀態。定制化控制器是用戶可以在運行中的集群內部署和更新的一個控制器，它獨立於集群本身的生命周期。
定制化控制器可以和任何一種資源一起工作，當和定制化資源結合使用時尤其有效。
Operator模式
是一個customer controllers和Custom resources結合的例子。它可以允許開發者將特殊應用編碼至kubernetes的擴展API內。
通俗理解：CR即創建一個自定義資源，CRD是對資源的描述，CC是提供CRD對象的管理。
CRD本身只是一段聲明，用於定義用戶自定義的資源對象。但僅有CRD的定義並沒有實際作用，用戶還需要提供管理CRD對象的CRD控制器（CRD Controller），才能實現對CRD對象的管理。CRD控制器通常可以通過Go語言進行開發，並需要遵循Kubernetes的控制器開發規范，基於客戶端庫client-go進行開發，需要實現Informer 、ResourceEventHandler、Workqueue等組件具體的功能處理邏輯，
以官網的例子說明：
以下就是創建一個CronTab 資源。其中 Group: stable.example.com ,version:v1,resource:CronTab。而這個yaml文件，就是一個具體的“自定義API資源”，也叫CR（Custom resources），而為了讓kubernetes 能夠認識這個CR，你就需要讓kubernetes 明白這個CR的宏觀定義是什么，即CRD（Custom Resource Definition）
apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
name: my-new-cron-object
spec:
cronSpec: "* * * * */5"
image: my-awesome-cron-image
# Deprecated in v1.16 in favor of apiextensions.k8s.io/v1
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
# name must match the spec fields below, and be in the form: <plural>.<group>
name: crontabs.stable.example.com
spec:
# group name to use for REST API: /apis/<group>/<version>
group: stable.example.com
# list of versions supported by this CustomResourceDefinition
versions:
- name: v1
# Each version can be enabled/disabled by Served flag.
served: true
# One and only one version must be marked as the storage version.
storage: true
# either Namespaced or Cluster
#該API的生效范圍，可選項為Namespaced（由Namespace限定）和Cluster（在集群范圍全局生效，不局限於任何Namespace），默認值為Namespaced。
scope: Namespaced
names:
# plural name to be used in the URL: /apis/<group>/<version>/<plural>
# 復數形式的名稱，要求全部小寫
plural: crontabs
# singular name to be used as an alias on the CLI and for display
# 單數形式的名稱，要求全部小寫
singular: crontab
# kind is normally the CamelCased singular type. Your resource manifests use this.
# CRD的資源類型名稱，要求以駝峰式命名規范進行命名
kind: CronTab
# shortNames allow shorter string to match your resource on the CLI
# 縮寫形式的名稱，要求全部小寫
shortNames:
- ct
preserveUnknownFields: false
# CRD的校驗（Validation）機制
validation:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
image:
type: string
replicas:
type: integer
CRD的高級用途
1、CRD的subresources子資源
Kubernetes從1.11版本開始，在CRD的定義中引入了名為subresources的配置，可以設置的選項包括status和scale兩類。
- stcatus：啟用/status路徑，其值來自CRD的.status字段，要求CRD控制器能夠設置和更新這個字段的值。
- scale：啟用/scale路徑，支持通過其他Kubernetes控制器（如HorizontalPodAutoscaler控制器）與CRD資源對象實例進行交互。用戶通過kubectl scale命令也能對該CRD資源對象進行擴容或縮容操作，要求CRD本身支持以多個副本的形式運行。
subresources:
status: {}
2、CRD的校驗（Validation）機制
validation:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
image:
type: string
replicas:
type: integer
3、自定義查看CRD時需要顯示的列
# 自定義查看CRD時需要顯示的列，即kubectl get 命令能夠顯示的字段
additionalPrinterColumns:
- JSONPath: .status.conditions[-1:].type
name: State
type: string
- JSONPath: .metadata.creationTimestamp
name: Age
type: date
4、Finalizer（CRD資源對象的預刪除鈎子方法）
Finalizer設置的方法在刪除CRD資源對象時進行調用，以實現CRD資源對象的清理工作。
接下來，好好研究怎么編寫Custom controllers
參考：https://blog.csdn.net/weixin_41806245/article/details/94451734