*作者：* *姜洪燁*

KubeVela 外掛（addon）可以方便地擴充套件 KubeVela 的能力。正如我們所知，KubeVela 是一個微核心高度可擴充套件的平臺，使用者可以透過模組定義（Definition） **[** **1]** 擴充套件 KubeVela 的系統能力，而 KubeVela 外掛正是方便將這些**自定義擴充套件**及其**依賴**打包並分發的核心功能。不僅如此，KubeVela 社群的外掛中心也在逐漸壯大，如今已經有超過 50 款外掛，涵蓋可觀測性、微服務、FinOps、雲資源、安全等大量場景功能。

本文將會全方位介紹 KubeVela 外掛的核心機制，教你如何編寫一個自定義外掛。在最後，我們將展示終端使用者使用外掛的體驗，以及外掛將如何融入到 KubeVela 平臺，為使用者提供一致的體驗。

## 為什麼要使用 KubeVela 外掛

使用者使用外掛的一個典型方法是透過 KubeVela 團隊維護的外掛中心（addon catalog） **[** **2]** ，它包含了 KubeVela 團隊與社群開發者精心編寫的系統擴充套件功能，並以外掛的形式釋出於外掛中心，這樣你可以一鍵下載並安裝這些外掛。例如安裝 FluxCD 可以快速給你的 KubeVela Application 提供部署 Helm Chart 的能力。

相較於使用 KubeVela 的外掛功能，如果你自己的內部平臺想要整合一個雲原生的功能，你大概會這麼做：

1.  透過 Helm Chart 或者下載 yaml 檔案手動安裝 FluxCD 或類似的 CRD Operator。
1.  編寫系統整合的程式碼，讓使用者介面可以透過統一的方式使用 FluxCD 等 CRD 的功能，在 KubeVela 系統中就是透過編寫模組定義（OAM Definition）完成。

實際上，在 KubeVela 1.1 版本之前，我們也是透過類似的方式完成的。這會帶來如下問題：

1.  **操作繁瑣**：使用者需要手動查閱文件如何安裝 FluxCD 並處理可能發生的錯誤
1.  **資源分散**：使用者需要下載不同的檔案，既需要安裝 Helm 安裝 FluxCD 還需要下載模組定義等系統擴充套件的整合配置
1.  **難以分發複用**：使用者需要手動下載模組定義就註定了這些資源難以以一個統一的方式分發給使用者，也無法形成社群生態讓不同的使用者可以享受社群便利
1.  **缺少多叢集支援**：KubeVela 將多叢集/交付作為一等公民，而這樣的手動安裝系統擴充套件的方式顯然難以維護多叢集的環境
1.  **無版本管理**：使用者需要手動管理模組定義和 Controller 之間的版本

而 KubeVela 外掛就是為了逐一解決這些問題而誕生的。

## KubeVela 外掛是如何工作的

KubeVela 的外掛主要包含兩部分：

-   一部分是安裝能力的提供者，通常是一個 CRD Operator/Controller。這個**安裝過程實質上就是執行一個 OAM 應用**，addon 交付中所使用的功能與普通應用能力完全等價。
-   另一部分就是擴充套件能力跟 KubeVela 體系的粘合層，也就是模組定義和其他的一些整合配置。OAM 模組定義為使用者提供了外掛擴充套件出的元件、運維特徵以及工作流步驟等功能，也幫助 CRD Operator 提供使用者友好的抽象，使得終端使用者無需理解複雜的 CRD 引數，只需要根據最佳實踐提供必要的引數。

![1.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/73e90ff433ff45f2961329bcc1ebb666~tplv-k3u1fbpfcp-zoom-1.image "1.jpeg")

外掛的工作機制如上圖所示，KubeVela 的應用具備多叢集/交付的能力，所以也能幫助外掛中的 CRD Operator 部署到這些叢集中。模組定義檔案僅需要在控制面被 KubeVela 使用，所以無需部署到被管控的叢集中。

***提示***

*一旦外掛被安裝，就會建立一個 KubeVela 應用，包含所有的相關資源和配置，這些配置都會設定 KubeVela 應用對外作為 OwnerReference（父節點）。當我們想要解除安裝一個外掛時，只需要刪除這個應用，Kubernetes 提供的資源回收機制會自動將標記了 OwnerReference 的資源一併刪除。*

例如一個 Redis 外掛，它能讓使用者在自己的應用中使用 Redis 叢集型別的元件（Component），這樣可以快速建立 Redis 叢集。那麼這個外掛至少會包括一個 Redis Operator 來提供建立 Redis 叢集的能力（透過 Application 描述），還有一個元件的模組定義 （ComponentDefinition） 來提供 Redis 叢集的元件型別。

所有整個外掛的安裝過程會將 Redis Operator 放在一個 KubeVela 應用中下發到多叢集，而元件定義和 UI 擴充套件等配置檔案則只部署到控制面叢集並設定應用物件為 OwnerReference。

## 建立自己的外掛

***提示***

*為保證以下內容功能全部可用，請確保你的 KubeVela 版本 為 v1.5+。*

我們將以 Redis 外掛為例，講解如何從頭建立一個 KubeVela 外掛的實際過程。本次完整的 Redis 外掛程式碼見文末參考 **[** **3]** 。

***提示***

*在這裡我們會盡可能全面的介紹製作外掛中涉及的核心知識，但是作為一個介紹性部落格，我們會盡量避免討論過深的細節以免篇幅過於膨脹，瞭解完整的功能及細節可以參考自定義外掛文件* ***[** **4]** 。*

**首先我們需要思考我們要建立的外掛有什麼作用？** 例如我們假設 Redis 外掛可以提供 redis-failover 型別的 Component，這樣使用者只需在 Application 中定義一個redis-failover  Component 即可快速建立 Redis 叢集。

**然後考慮如何達到這個目的**？要提供 redis-failover 型別的 Component 我們需要定義一個 ComponentDefinition ；要提供建立 Redis 叢集的能力支援，我們可以使用 Redis Operator **[** **5]** 。那至此我們的大目標就明確了：

-   編寫外掛的應用描述檔案（OAM Application），這將會用於安裝 Redis Operator （完整程式碼可以到外掛中心的 template.cue **[** **6]** 及resources/目錄 **[** **7]** 檢視。）
-   編寫 redis-failover 型別的 ComponentDefinition **[8** **]** （完整程式碼請檢視 definitions/目錄 **[9** **]** ）

不過在開始編寫之前，我們首先需要了解一個 KubeVela 外掛的目錄結構。後續我們會在編寫的過程中詳細說明每個檔案的作用，在這裡只需大致瞭解有哪些檔案即可。

***提示***

*命令列工具 vela addon init 可以幫助你建立目錄結構的初始化腳手架。*

```
redis-operator/          
├── definitions           
│   └── redis-failover.cue 
├── resources              
│   ├── crd.yaml           
│   ├── redis-operator.cue
│   └── topology.cue       
├── metadata.yaml         
├── parameter.cue         
├── README.md             
└── template.cue
```

讓我們逐一來解釋它們：

1. redis-operator/ 是目錄名，同時也是外掛名稱，請保持一致。

2. definitions/ 用於存放模組定義, 例如 TraitDefinition 和 ComponentDefinition。

3. redis-failover.cue 定義我們編寫的 redis-failover 元件型別，包含了使用者如何使用這個元件的引數以及這個元件與底層資源互動的細節。

4. resources/ 用於存放資原始檔, 之後會在 template.cue 中使用他們共同組成一個 KubeVela 應用來部署外掛。

5. crd.yaml 是 Redis Operator 的 Kubernetes 自定義資源定義，在 resources/ 資料夾中的 YAML 檔案會被直接部署到叢集中。

6. redis-operator.cue 一個 web-service 型別的 Component ，用於安裝 Redis Operator。

7. topology.cue 是可選的，幫助 KubeVela 建立應用所納管資源的拓撲關係。

8. metadata.yaml 是外掛的後設資料，包含外掛名稱、版本、維護人等，為外掛中心提供了概覽資訊。

9. parameter.cue 外掛引數定義，使用者可以利用這些引數在外掛安裝時做輕量級自定義。

10. README.md 提供給終端使用者閱讀，包含外掛使用指南等。

11. template.cue 定義外掛最終部署時的完整應用形態，包含一個 OAM 應用模板以及對其他資源物件的引用。

***提示***

*在外掛中製作中我們會廣泛使用 CUE 語言來編排配置，如果對 CUE 不熟悉，可以花 10 分鐘快速查閱入門指南有一個基本瞭解。*

### parameter.cue

```
parameter: {
    //+usage=Redis Operator image.
    image: *"quay.io/spotahome/redis-operator:v1.1.0" | string
    // 其餘省略
}
```

在 parameter.cue 中定義的引數都是使用者可以自定義的（類似於 Helm Values），後續在 template.cue 或者 resources 中可以透過 parameter.<parameter-name> 訪問引數。在我們的例子中，使用者可以自定義 image ，這樣後續我們建立 Redis Operator (redis-operator.cue) 的時候可以透過 parameter.image 使用使用者指定的容器映象。

引數不僅可以給使用者預留安裝時的自定義輸入，還可以作為安裝時的條件進行部分安裝。比如fluxcd 外掛有一個引數叫 onlyHelmComponents **[10** **]** ，它的作用就是可以幫助使用者只部署用於安裝 Helm Chart 的元件能力，而其他控制器就可以不安裝。如果你對於實現細節感興趣，可以參考fluxcd 外掛的部分配置 **[11** **]** 。

在設計提供什麼引數供使用者自定義外掛安裝時，我們也應該遵循一下這些最佳實踐來為使用者提供更好的使用體驗。

***最佳實踐***

-   *不要在 parameter.cue 中提供大量的細節引數，將大量細節抽象出少量引數供使用者調節是一個更好的做法*

-   *為引數提供預設值（如樣例中的 image 引數）或將引數標記為可選（如樣例的 clusters 引數），確保使用者僅使用預設值可以得到一個可用的配置*

-   *為引數提供使用說明（透過註釋標記實現，見樣例）*

-   *儘量保持外掛不同版本間的引數一致，防止因為升級導致不相容*

### template.cue 和 resources/ 目錄

這是存放我們應用描述檔案的地方，即一個 OAM Application 。這描述了實際的外掛安裝過程。我們主要會在這裡包含 Redis Operator ，給叢集提供管理 Redis 叢集的能力。

template.cue 和 resources/ 目錄本質上是相同的，都是構成 KubeVela 應用的組成部分，且都是在同一個 package 下的 CUE 檔案。

那為什麼需要 resources 目錄呢？除去歷史原因，這主要是為了可讀性的考慮，在 Application 中包含大量資源的時候 template.cue 可能變得很長，這時我們可以把資源放置在 resource 中增加可讀性。一般來說，我們將 Application 的框架放在 template.cue 中，將 Application 內部的 Components、Traits 等資訊放在 resource 目錄中。

-   **template.cue**

template.cue 定義了應用的框架，絕大多數內容都是固定寫法，具體的作用可以參考程式碼塊中的註釋。

```
// template.cue 應用描述檔案

// package 名稱需要與 resources 目錄中 cue 的 package 一致，方便引用 resources 目錄中的內容
package main

// Application 模板中多數字段均為固定寫法，你需要注意的只有 spec.components

output: {
    // 這是一個經典的 OAM Application
    apiVersion: "core.oam.dev/v1beta1"
    kind:       "Application"
    // 不需要 metadata
    spec: {
        components: [
            // 建立 Redis Operator
            redisOperator // 定義於 resources/redis-operator.cue 中
        ]
        policies: [
        // 這裡會指定安裝外掛的 namespace ，是否安裝至子叢集等
        // 多為固定寫法，無需記憶，可查閱本次樣例的完整程式碼
        // https://github.com/kubevela/catalog/blob/master/experimental/addons/redis-operator/template.cue
        // 文件可參照 https://kubevela.net/zh/docs/end-user/policies/references
        ]
    }
}
// 定義資源關聯規則，用於將資源粘合在一起。後續會著重介紹
// Documentation: https://kubevela.net/zh/docs/reference/topology-rule
outputs: topology: resourceTopology // 定義於 resources/topology.cue 中
```

在外掛安裝時，系統主要關注兩個關鍵字：

-   一是 output 欄位，定義了外掛對應的應用，在應用內部 spec.components 定義了部署的元件，在我們的例子中引用了存放在 resources/ 目錄中的 redisOperator 元件。output 中的 Application 物件不是嚴格的 Kubernetes 物件，其中 metadata 裡的內容（主要是外掛名稱）會被外掛安裝的過程自動注入。

-   另一個是 outputs 欄位，定義了除了常規應用之外的配置，任何你想要跟外掛一同部署的額外 Kubernetes 物件都可以定義在這裡。請注意 outputs 中的這些物件必須遵循 Kubernetes API。

-   **resources/ 資原始檔**

我們這裡使用一個webservice型別的 Component 來安裝 Redis Operator。當然，如果你可以接受依賴 FluxCD 的話，你也可以使用 helm 型別的 Component 直接安裝一個 Helm Chart（因為 helm 型別的 Component 主要由 FluxCD 外掛提供）。不過編寫 addon 的一個原則是儘量減少外部依賴，所以我們這裡使用 KubeVela 內建的 webservice 型別，而不是 helm。

```
// resources/redis-operator.cue

// package 名稱與 template.cue 一致，方便在 template.cue 中引用以下的 redisOperator
package main

redisOperator: {
    // 這是 OAM Application 中的 Component ，它將會建立一個 Redis Operator
    // https://kubevela.net/zh/docs/end-user/components/references
    name: "redis-operator"
    type: "webservice"
    properties: {
        // Redis Operator 映象名稱，parameter.image 即在 parameter.cue 中使用者可自定義的引數
        image:           parameter.image
        imagePullPolicy: "IfNotPresent"
    }
    traits: [
        // 略
    ]
}
```

你可以閱讀程式碼塊中的註釋瞭解欄位的具體作用。

-   **KubeVela 提供的資源粘合能力**

值得注意的一個功能是資源關聯規則 (Resource Topology) **[** **12]** 。雖然它不是必須的，但是它能幫助 KubeVela 建立應用所納管資源的拓撲關係。這就是 KubeVela 如何將各種各樣的資源粘合成 Application 的。這在我們使用 Kubernetes 自定義資源（CR）的時候特別有用。

```
// resources/topology.cue

package main

import "encoding/json"

resourceTopology: {
    apiVersion: "v1"
    kind:       "ConfigMap"
    metadata: {
        name:      "redis-operator-topology"
        namespace: "vela-system"
        labels: {
            "rules.oam.dev/resources":       "true"
            "rules.oam.dev/resource-format": "json"
        }
    }
    data: rules: json.Marshal([{
        parentResourceType: {
            group: "databases.spotahome.com"
            kind:  "RedisFailover"
        }
        // RedisFailover CR 會建立以下三類資源
        childrenResourceType: [
            {
                apiVersion: "apps/v1"
                kind:  "StatefulSet"
            },
            // KubeVela 內建 Deployment 等資源的拓撲，因此無需繼續向下編寫
            {
                apiVersion: "apps/v1"
                kind:  "Deployment"
            },
            {
                apiVersion: "v1"
                kind:  "Service"
            },
        ]
    }])
}
```

在本例中，redis-failover 型別的 Component 會建立一個 CR ，名為 RedisFailover 。但是在沒有資源關聯規則的情況下，假設在你的 Application 中使用了 RedisFailover ，雖然我們知道 RedisFailover 管控了數個 Redis Deployment ，但是 KubeVela 並不知道 RedisFailover 之下有 Deployment 。這時我們可以透過 資源關聯規則 將我們對於 RedisFailover 的瞭解告訴 KubeVela，這樣 KubeVela 可以幫助我們建立起整個應用下面納管資源的拓撲層級關係。此時你將獲得 KubeVela 提供的許多有用功能，效果見執行外掛 **[** **13]** 。

***提示***

*資源的拓撲關聯功能給我們帶來了許多有用的功能，最重要的是為 KubeVela 終端使用者使用擴充套件能力提供了統一體驗：*

-   *VelaUX 資源拓撲檢視，從應用到底層資源 Pod 的關聯關係一應俱全，包括多叢集*

-   *統一的 vela exec 命令可以在不同應用元件型別關聯的底層容器中執行命令，包括多叢集*

-   *統一的 vela port-forward 轉發不同型別應用元件關聯的底層容器埠，包括多叢集*

-   *統一的 vela log 檢視不同型別應用元件關聯的底層容器日誌，包括多叢集*

-   *統一的 vela status --pod/--endpoint 檢視不同型別應用元件關聯的底層容器日誌，獲得可供訪問的地址等，包括多叢集*

### definitions/ 目錄

Definitions 目錄存放 KubeVela 模組定義（Definition） **[** **14]** ，包括元件定義（ComponentDefinition）、策略定義（TraitDefinition）等。**這是外掛中最重要的部分，因為它包含了終端使用者安裝這個外掛以後可以獲得哪些功能。** 有了這裡定義的元件、運維特徵、工作流等型別，終端使用者就可以在應用中使用他們了。

在外掛中編寫模組定義跟常規的編寫流程一致，這是一個很大的話題，在這裡我們就不詳細展開了。你可以透過閱讀模組定義對應的文件瞭解其中的細節：

-   自定義元件 Component Definition **[** **15]**
-   自定義運維特徵 Trait Definition **[** **16]**
-   自定義策略 Policy Definition **[** **17]**
-   自定義工作流步驟 Workflow Step Definition。 **[** **18]**

在本例中，我們編寫 Redis 元件型別主要參照自定義元件 **[** **19]** 與 Redis Operator 使用文件 **[** **20]** ，我們將元件型別命名為 redis-failover，它會建立一個 RedisFailover 的 CR ，這樣剛剛新增的 Redis Operator 就可以幫助建立 Redis 叢集，見文末完整程式碼 **[** **21]** 。

### metadata.yaml

這裡包含了外掛的後設資料，即外掛的名稱、版本、系統要求等，可以參考文末文件 **[** **22]** 。需要注意的是，本次介紹的為 KubeVela v1.5 之後的新寫法，因此需要避免使用某些不相容的後設資料欄位，以下樣例中包含了所有的可用後設資料。

***提示***

*例如傳統的 deployTo.runtimeCluster （安裝至子叢集）等後設資料在新寫法中已有代替（使用 topology Policy），應當使用新寫法。可見完整程式碼中的 template.cue* ***[** **23]***

```
# 外掛名稱，與目錄名一致
name: redis-operator
# 外掛描述
description: Redis Operator creates/configures/manages high availability redis with sentinel automatic failover atop Kubernetes.
# 展示用標籤
tags:
- redis
# 外掛版本
version: 0.0.1
# 展示用圖示
icon: https://xxx.com
# 外掛所包含專案的官網地址
url: https://github.com/spotahome/redis-operator
# 可能依賴的其他外掛，例如 fluxcd
dependencies: []

# 系統版本要求
system:
  vela: ">=v1.5.0"
  kubernetes: ">=1.19"
```

## 執行外掛

至此我們已經將外掛的主要部分編寫完成，下載文末完整程式碼 **[** **24]** 補全部分細節後，即可嘗試執行。

下載得到 redis-operator 目錄後，我們可以透過 vela addon enable redis-operator 安裝本地的 redis-operator 外掛，這種本地安裝外掛的方式也可以方便你再製作時做一些除錯。安裝完成後就可以參考外掛的 README **[** **25]** 試用我們的 Redis 外掛了！

***提示***

*這裡也體現出外掛的 README 的重要性，其中需要包括外掛的作用、詳細使用指南等，確保使用者可以快速上手。*

在使用者使用你編寫的外掛時，只需如下 **4** 行 yaml 即可在 Application 中建立包含 3 個 Node 的高可用 Redis 叢集！相比於手動安裝 Redis Operator 並建立 CR ，甚至逐一手動配置 Redis 叢集，外掛的方式極大地方便了使用者。

```
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: redis-operator-sample
spec:
  components:
    # This component is provided by redis-operator addon.
    # In this example, 2 redis instance and 2 sentinel instance
    # will be created.
    - type: redis-failover
      name: ha-redis
      properties:
        # You can increase/decrease this later to add/remove instances.
        replicas: 3
```

只需 apply 僅僅數行的 yaml 檔案，我們就輕鬆建立瞭如下圖所示的整個複雜的資源。並且由於我們編寫了資源關聯規則 (Resource Topology) ，使用者可以透過 VelaUX 輕鬆獲得剛剛建立的 Redis 叢集的資源拓撲狀態，瞭解 Application 底層資源的執行狀況，不再受限於 Application Component 級別的可觀測性。如圖我們能直接觀測到整個 Application 的拓撲，直至每個 Redis Pod ，可見圖中部分 Pod 仍在準備中：

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7addfdfb5fb148dcafffb37f1df3d3a7~tplv-k3u1fbpfcp-zoom-1.image "2.png")

在執行 vela exec/log/port-forward 等命令時也可以精確地看到 Application 底層包含的資源（即支撐 Redis 叢集的 3 個 Redis Pod 和 3 個 Sentinel Pod）。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/310144f980854ec6aa4f4dac26a2726b~tplv-k3u1fbpfcp-zoom-1.image "3.png")

> 如果你在使用單叢集，乍一看你可能不會覺得 exec 進一個 Pod 是很特殊的功能。但是一旦考慮到多叢集，能夠在橫跨多個叢集的資源中跟單叢集一樣以統一的方式進行選擇檢視能夠極大的節省時間。

使用 vela status 命令能獲取這個 Application 的執行狀態，有了資源關聯規則後可以更進一步，直接透過 vela 尋找出 Redis Sentinel 的 Endpoint 來訪問 Redis 叢集：

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d47667e5750c4538b5d2b4c60d9469a2~tplv-k3u1fbpfcp-zoom-1.image "4.png")

## 結語

透過本文，相信你已經瞭解外掛的作用及製作外掛的要點。透過外掛體系，我們將獲得如下優勢：

1.  將平臺的能力打包成一個易於安裝、便於分發複用、且可以形成社群生態的外掛市場。
1.  充分複用 CUE 和 KubeVela 應用透過的強大能力，將基礎設施資源靈活定義並進行多叢集分發。
1.  無論擴充套件的資源型別是什麼，均可以接入應用體系，為終端使用者提供一致的體驗。

最後，如果你成功製作了屬於自己的外掛，KubeVela 社群非常歡迎開發者貢獻外掛至外掛中心 **[** **26]** ，這樣你的外掛還能夠被其他 KubeVela 社群使用者發現並使用！  
  
您可以透過如下材料瞭解更多關於 KubeVela 以及 OAM 專案的細節：

-   專案程式碼庫：github.com/oam-dev/kubevela 歡迎 Star/Watch/Fork！
-   專案官方主頁與文件：kubevela.io ，從 1.1 版本開始，已提供中文、英文文件，更多語言文件歡迎開發者進行翻譯。
-   專案釘釘群：23310022；Slack：CNCF #kubevela Channel
-   加入微信群：請先新增以下 maintainer 微訊號，表明進入KubeVela使用者群：

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/30b2114f1b2f4fd0aac62b25d4eaee65~tplv-k3u1fbpfcp-zoom-1.image "5.png")

戳[此處](https://kubevela.io/)：檢視 KubeVela 專案官網！！

***相關連結***

*[1] 模組定義（Definition）*

*<https:>*

**[2]* 外掛中心（addon catalog）*

*<https:>*

**[3]* catalog/redis-operator*

*<https:>*

**[4]* 自定義外掛文件*

*<https:>*

**[5]* Redis Operator*

*<https:>*

**[6]* template.cue*

*<https:>*

**[7]* resources/*

*<https:>*

**[8]* ComponentDefinition*

*<https:>*

**  
**

**[9]* definitions/目錄*

*<https:>*

**[10]* onlyHelmComponents*

*<https:>*

**[11]* fluxcd 外掛部分配置*

*<https:>*

**[12]* 資源關聯規則 (Resource Topology)*

*<https:>*

**[13]* 執行外掛*

*[https://kubevela.io/zh/blog/2022/10/18/building-addon-introduction#%E8%BF%90%E8%A1%8C%E6%8F%92%E4%BB%B6](https://kubevela.io/zh/blog/2022/10/18/building-addon-introduction#%25E8%25BF%2590%25E8%25A1%258C%25E6%258F%2592%25E4%25BB%25B6)*

**[14]* 模組定義（Definition）*

*<https:>*

**[15]* 自定義元件 Component Definition*

*<https:>*

**[16]* 自定義運維特徵 Trait Definition*

*<https:>*

**[17]* 自定義策略 Policy Definition*

*<https:>*

**[18]* 自定義工作流步驟 Workflow Step Definition*

*<https:>*

**[19]* 自定義元件*

*<https:>*

**[20]* Redis Operator 使用文件*

*<https:>*

**[21]* 完整程式碼*

*<https:>*

**[22]* 文件*

*[https://kubevela.net/zh/docs/platform-engineers/addon/intro#%E6%8F%92%E4%BB%B6%E7%9A%84%E5%9F%BA%E6%9C%AC%E4%BF%A1%E6%81%AF%E6%96%87%E4%BB%B6](https://kubevela.net/zh/docs/platform-engineers/addon/intro#%25E6%258F%2592%25E4%25BB%25B6%25E7%259A%2584%25E5%259F%25BA%25E6%259C%25AC%25E4%25BF%25A1%25E6%2581%25AF%25E6%2596%2587%25E4%25BB%25B6)*

**[23]* template.cue*

*<https:>*

**[24]* 完整程式碼*

*<https:>*

**[25]* README*

*<https:>*

**[26]* 外掛中心*

*<https:>*

* * *

**11 月 5 日**

**杭州雲棲小鎮-雲原生峰會**

阿里雲將聯手識貨、傳音、禾連健康、新東方、心動網路、小紅書等實戰企業技術負責人

向你發出邀請

**掃碼即刻參會！**

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/830bf118906a4f628993116d0473fcd8~tplv-k3u1fbpfcp-zoom-1.image "6.png")</https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></parameter-name>

KubeVela 外掛指南：輕鬆擴充套件你的平臺專屬能力

相關文章