一、概述

CRD（Custom Resource Definition） 本身是一種 Kubernetes 內置的資源類型，即自定義資源的定義，用于描述用戶定義的資源是什么樣子。CRD 的相關概念：

• CRD 是 v1.7 +新增的無需改變代碼 就可以擴展 Kubernetes API 的機制，用來管理自定義對象。它實際上是ThirdPartyResources（TPR） 的升級版本，而 TPR 已經在 v1.8 中刪除。
• 從 Kubernetes 的用戶角度來看，所有東西都叫資源 Resource，就是 Yaml 里的字段 Kind 的內容，例如 Service、Deployment 等。
• 除了常見內置資源之外，Kubernetes 允許用戶自定義資源 Custom Resource，而 CRD 表示自定義資源的定義。
• 當你創建新的 CustomResourceDefinition（CRD）時，Kubernetes API 服務器會為你所指定的每個版本生成一個新的 RESTful 資源路徑。
• 基于 CRD 對象所創建的自定義資源可以是名字空間作用域的，也可以是集群作用域的， 取決于 CRD 對象 spec.scope 字段的設置。
• 定義 CRD 對象的操作會使用你所設定的名字和模式定義（Schema）創建一個新的定制資源， Kubernetes API 負責為你的定制資源提供存儲和訪問服務。 CRD 對象的名稱必須是合法的 DNS 子域名。

DNS 子域名

很多資源類型需要可以用作 DNS 子域名的名稱。名稱必須滿足如下規則：

• 不能超過 253 個字符
• 只能包含小寫字母、數字，以及 '-' 和 '.'
• 必須以字母數字開頭
• 必須以字母數字結尾

CRD 官方文檔：https://kubernetes.io/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/

二、定制資源

定制資源（Custom Resource） 是對 Kubernetes API 的擴展。

1）定制資源 和 定制控制器

• 資源（Resource） 是 Kubernetes API 中的一個端點， 其中存儲的是某個類別的 API 對象的一個集合。例如內置的 Pod 資源包含一組 Pod 對象。
• 定制資源（Custom Resource） 是對 Kubernetes API 的擴展， 定制資源所代表的是對特定 Kubernetes 安裝的一種定制。不過，很多 Kubernetes 核心功能現在都用定制資源來實現，這使得 Kubernetes 更加模塊化。
• 定制資源可以通過動態注冊的方式在運行中的集群內或出現或消失，集群管理員可以獨立于集群更新定制資源。
• 一旦某定制資源被安裝，用戶可以使用 kubectl 來創建和訪問其中的對象， 就像他們為 Pod 這種內置資源所做的一樣。

2）定制控制器

• 就定制資源本身而言，它只能用來存取結構化的數據。當你將定制資源與定制控制器（Custom Controller） 結合時， 定制資源就能夠提供真正的聲明式 API（Declarative API）。
• Operator 模式就是將定制資源與定制控制器相結合的。

3）Operator 介紹

Kubernetes CRD Operator = kubernetes CRD + custom controller

• Operator 是由 CoreOS 開發的，用來擴展 Kubernetes API，特定的應用程序控制器，它用來創建、配置和管理復雜的有狀態應用，如數據庫、緩存和監控系統。
• Operator 基于 Kubernetes 的資源和控制器概念之上構建，但同時又包含了應用程序特定的領域知識。創建Operator 的關鍵是CRD（自定義資源）的設計。
• Operator是 Kubernetes 的擴展軟件， 它利用定制資源管理應用及其組件。Operator 遵循 Kubernetes 的理念，特別是在控制器方面。
• Operator 模式會封裝你編寫的（Kubernetes 本身提供功能以外的）任務自動化代碼。
• Kubernetes 的 Operator 模式概念允許你在不修改 Kubernetes 自身代碼的情況下， 通過為一個或多個自定義資源關聯控制器來擴展集群的能力。
• Operator 是 Kubernetes API 的客戶端。Operator 旨在為其管理的資源提供強大的自動化功能，因此它還需要一些額外的支持性代碼。

1、Operator Framework

Operator Framework 同樣也是 CoreOS 開源的一個用于快速開發 Operator 的工具包，該框架包含兩個主要的部分：

• Operator SDK——無需了解復雜的 Kubernetes API 特性，即可讓你根據你自己的專業知識構建一個 Operator 應用。
• Operator Lifecycle Manager OLM——幫助你安裝、更新和管理跨集群的運行中的所有 Operator（以及他們的相關服務）

2、Operator 安裝

Operator SDK 提供以下工作流來開發一個新的 Operator：

• 使用 SDK 創建一個新的 Operator 項目
• 通過添加自定義資源（CRD）定義新的資源 API
• 指定使用 SDK API 來 watch 的資源
• 定義 Operator 的協調（reconcile）邏輯
• 使用 Operator SDK 構建并生成 Operator 部署清單文件

3、安裝 Operator SDK

下載地址：https://github.com/operator-framework/operator-sdk/releasesoperator sdk 官方文檔：https://sdk.operatorframework.io/docs/installation/

wget https://github.com/operator-framework/operator-sdk/releases/download/v1.23.0/operator-sdk_linux_amd64

# 添加可執行權限
 
chmod +x operator-sdk_linux_amd64
 
# 添加軟鏈
ln -s /opt/k8s/crd/Operator/operator-sdk_linux_amd64 /usr/local/bin/operator-sdk

4、Operator 簡單使用

【示例1】快速簡單使用

operator-sdk init --domain=example.com --repo=github.com/example-inc/memcached-operator
# 步驟二: 創建 API（operator-sdk create api --group cache --version v1 --kind Memcached --resource=true --cnotallow=true）
operator-sdk create api --group cache --version v1 --kind Memcached --resource=true --cnotallow=true
# 步驟三: 構建鏡像-需要本地存在 docker 環境（make docker-build IMG=liumiaocn/memcache:v1）
make docker-build IMG=liumiaocn/memcache:v1
# 步驟四: 運行Operator-需要環境具備 K8s/K3s（make install && make deploy IMG=liumiaocn/memcache:v1）
make install && make deploy IMG=liumiaocn/memcache:v1
# 步驟五：創建自定義資源
kubectl apply -f config/samples/cache_v1_memcached.yaml
# 步驟六：刪除CR和相關資源（kubectl delete -f config/samples/cache_v1_memcached.yaml）
kubectl delete -f config/samples/cache_v1_memcached.yaml

這里只是簡單的安裝部署使用，后面會單獨拿一篇文章來詳細介紹Operator 。

4）Kubernetes API 聚合層

• 使用聚合層（Aggregation Layer），用戶可以通過附加的 API 擴展 Kubernetes， 而不局限于 Kubernetes 核心 API 提供的功能。這里的附加 API 可以是現成的解決方案，比如 metrics server， 或者你自己開發的 API。
• 聚合層不同于 定制資源（Custom Resources）。后者的目的是讓 kube-apiserver 能夠識別新的對象類別（Kind）。
• 聚合層在 kube-apiserver 進程內運行。在擴展資源注冊之前，聚合層不做任何事情。
• 要注冊 API，你可以添加一個 APIService 對象，用它來 “申領” Kubernetes API 中的 URL 路徑。自此以后，聚合層將把發給該 API 路徑的所有內容（例如 /apis/myextension.mycompany.io/v1/…） 轉發到已注冊的 APIService。

5）聲明式 APIs

典型地，在聲明式 API 中：

• 你的 API 包含相對而言為數不多的、尺寸較小的對象（資源）。
• 對象定義了應用或者基礎設施的配置信息。
• 對象更新操作頻率較低。
• 通常需要人來讀取或寫入對象。
• 對象的主要操作是 CRUD 風格的（創建、讀取、更新和刪除）。
• 不需要跨對象的事務支持：API 對象代表的是期望狀態而非確切實際狀態。

命令式 API（Imperative API）與聲明式有所不同。以下跡象表明你的 API 可能不是聲明式的：

• 客戶端發出“做這個操作”的指令，之后在該操作結束時獲得同步響應。
• 客戶端發出“做這個操作”的指令，并獲得一個操作 ID，之后需要檢查一個 Operation（操作） 對象來判斷請求是否成功完成。
• 你會將你的 API 類比為遠程過程調用（Remote Procedure Call，RPCs）。
• 直接存儲大量數據；例如每個對象幾 kB，或者存儲上千個對象。
• 需要較高的訪問帶寬（長期保持每秒數十個請求）。
• 存儲有應用來處理的最終用戶數據（如圖片、個人標識信息（PII）等）或者其他大規模數據。
• 在對象上執行的常規操作并非 CRUD 風格。

6）添加定制資源

Kubernetes 提供了兩種方式供你向集群中添加定制資源：

• CRD 相對簡單，創建 CRD 可以不必編程。
• API 聚合 需要編程，但支持對 API 行為進行更多的控制，例如數據如何存儲以及在不同 API 版本間如何轉換等。

Kubernetes 提供這兩種選項以滿足不同用戶的需求，這樣就既不會犧牲易用性也不會犧牲靈活性。

• 聚合 API指的是一些下位的 API 服務器，運行在主 API 服務器后面；主 API 服務器以代理的方式工作。這種組織形式稱作 API 聚合（API Aggregation，AA） 。對用戶而言，看起來僅僅是 Kubernetes API 被擴展了。
• CRD 允許用戶創建新的資源類別同時又不必添加新的 API 服務器。使用 CRD 時，你并不需要理解 API 聚合。

7）訪問定制資源

Kubernetes 客戶端庫可用來訪問定制資源。并非所有客戶端庫都支持定制資源。Go 和 Python 客戶端庫是支持的。

當你添加了新的定制資源后，可以用如下方式之一訪問它們：

• kubectl
• Kubernetes 動態客戶端（DynamicClient），可以對任意Kubernetes資源進行RESTFful操作，包括CRD自定義資源。
• 你所編寫的 REST 客戶端
• 使用 Kubernetes 客戶端生成工具 所生成的客戶端。生成客戶端的工作有些難度，不過某些項目可能會隨著 CRD 或 聚合 API 一起提供一個客戶端

三、CRD 示例演示

1）創建 CRD （定制資源）

當你創建新的 CustomResourceDefinition（CRD）時，Kubernetes API 服務器會為你所指定的每個版本生成一個新的 RESTful 資源路徑。基于 CRD 對象所創建的自定義資源可以是名字空間作用域的，也可以是集群作用域的， 取決于 CRD 對象 spec.scope 字段的設置。

cat > resourcedefinition.yaml << EOF
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  # 名字必需與下面的 spec 字段匹配，并且格式為 '<名稱的復數形式>.<組名>'
  name: crontabs.stable.example.com
spec:
  # 組名稱，用于 REST API: /apis/<組>/<版本>
  group: stable.example.com
  # 列舉此 CustomResourceDefinition 所支持的版本
  versions:
    - name: v1
      # 每個版本都可以通過 served 標志來獨立啟用或禁止
      served: true
      # 其中一個且只有一個版本必需被標記為存儲版本
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                image:
                  type: string
                replicas:
                  type: integer
  # 可以是 Namespaced 或 Cluster
  scope: Namespaced
  names:
    # 名稱的復數形式，用于 URL：/apis/<組>/<版本>/<名稱的復數形式>
    plural: crontabs
    # 名稱的單數形式，作為命令行使用時和顯示時的別名
    singular: crontab
    # kind 通常是單數形式的駝峰命名（CamelCased）形式。你的資源清單會使用這一形式。
    kind: CronTab
    # shortNames 允許你在命令行使用較短的字符串來匹配資源
    shortNames:
    - ct
EOF

執行創建

kubectl apply -f resourcedefinition.yaml

這樣一個新的受名字空間約束的 RESTful API 端點會被創建在：

/apis/stable.example.com/v1/namespaces/

對象的 kind 將是來自你上面創建時 所用的 spec 中指定的 CronTab。

Kubernetes（k8s）API 的 操作可以參考我之前的文章：Kubernetes（k8s）API Server詳解

kubectl get --raw /apis/stable.example.com/v1/
kubectl get --raw /apis/stable.example.com/v1/|python -m json.tool

2）創建定制對象（定制控制器）

在創建了 CustomResourceDefinition 對象之后，你可以創建定制對象（?Custom Objects）。定制對象可以包含定制字段。這些字段可以包含任意的 JSON 數據。在下面的例子中，在類別為 CronTab 的定制對象中，設置了cronSpec 和 image 定制字段。類別 CronTab 來自你在上面所創建的 CRD 的規約。

cat >my-crontab.yaml<<EOF
apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-awesome-cron-image
EOF

并執行創建命令：

kubectl apply -f my-crontab.yaml

你就可以使用 kubectl 來管理你的 CronTab 對象了。例如：

kubectl get crontab
kubectl get ct -o yaml

3）刪除 CustomResourceDefinition

當你刪除某 CustomResourceDefinition 時，服務器會卸載其 RESTful API 端點，并刪除服務器上存儲的所有定制對象。

kubectl delete -f resourcedefinition.yaml
kubectl get crontabs