# 使用自定義資源擴展API > **注意：**TPR已經停止維護，kubernetes 1.7及以上版本請使用CRD。 自定義資源是對Kubernetes API的擴展，kubernetes中的每個資源都是一個API對象的集合，例如我們在YAML文件里定義的那些spec都是對kubernetes中的資源對象的定義，所有的自定義資源可以跟kubernetes中內建的資源一樣使用kubectl操作。 ## 自定義資源 Kubernetes1.6版本中包含一個內建的資源叫做TPR（ThirdPartyResource），可以用它來創建自定義資源，但該資源在kubernetes1.7中版本已被CRD（CustomResourceDefinition）取代。 ## 擴展API 自定義資源實際上是為了擴展kubernetes的API，向kubenetes API中增加新類型，可以使用以下三種方式： - 修改kubenetes的源碼，顯然難度比較高，也不太合適 - 創建自定義API server并聚合到API中 - 1.7以下版本編寫TPR，kubernetes1.7及以上版本用CRD 編寫自定義資源是擴展kubernetes API的最簡單的方式，是否編寫自定義資源來擴展API請參考[Should I add a custom resource to my Kubernetes Cluster?](https://kubernetes.io/docs/concepts/api-extension/custom-resources/)，行動前請先考慮以下幾點： - 你的API是否屬于[聲明式的](https://kubernetes.io/docs/concepts/api-extension/custom-resources/#declarative-apis) - 是否想使用kubectl命令來管理 - 是否要作為kubenretes中的對象類型來管理，同時顯示在kubernetes dashboard上 - 是否可以遵守kubernetes的API規則限制，例如URL和API group、namespace限制 - 是否可以接受該API只能作用于集群或者namespace范圍 - 想要復用kubernetes API的公共功能，比如CRUD、watch、內置的認證和授權等 如果這些都不是你想要的，那么你可以開發一個獨立的API。 ## TPR > **注意：**TPR已經停止維護，kubernetes 1.7及以上版本請使用CRD。 假如我們要創建一個名為`cron-tab.stable.example.com`的TPR，yaml文件定義如下： ```yaml apiVersion: extensions/v1beta1 kind: ThirdPartyResource metadata: name: cron-tab.stable.example.com description: "A specification of a Pod to run on a cron style schedule" versions: - name: v1 ``` 然后使用`kubectl create`命令創建該資源，這樣就可以創建出一個API端點`/apis/stable.example.com/v1/namespaces/<namespace>/crontabs/...`。 下面是在[Linkerd](https://linkerd.io)中的一個實際應用，Linkerd中的一個名為namerd的組件使用了TPR，定義如下： ```yaml --- kind: ThirdPartyResource apiVersion: extensions/v1beta1 metadata: name: d-tab.l5d.io description: stores dtabs used by namerd versions: - name: v1alpha1 ``` ### CRD 參考下面的CRD，resourcedefinition.yaml： ```yaml apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: # 名稱必須符合下面的格式：<plural>.<group> name: crontabs.stable.example.com spec: # REST API使用的組名稱：/apis/<group>/<version> group: stable.example.com # REST API使用的版本號：/apis/<group>/<version> version: v1 # Namespaced或Cluster scope: Namespaced names: # URL中使用的復數名稱: /apis/<group>/<version>/<plural> plural: crontabs # CLI中使用的單數名稱 singular: crontab # CamelCased格式的單數類型。在清單文件中使用 kind: CronTab # CLI中使用的資源簡稱 shortNames: - ct ``` 創建該CRD： ```bash kubectl create -f resourcedefinition.yaml ``` 訪問RESTful API端點如<http://172.20.0.113:8080>將看到如下API端點已創建： ```bash /apis/stable.example.com/v1/namespaces/*/crontabs/... ``` **創建自定義對象** 如下所示： ```yaml apiVersion: "stable.example.com/v1" kind: CronTab metadata: name: my-new-cron-object spec: cronSpec: "* * * * /5" image: my-awesome-cron-image ``` 引用該自定義資源的API創建對象。 **終止器** 可以為自定義對象添加一個終止器，如下所示： ```yaml apiVersion: "stable.example.com/v1" kind: CronTab metadata: finalizers: - finalizer.stable.example.com ``` 刪除自定義對象前，異步執行的鉤子。對于具有終止器的一個對象，刪除請求僅僅是為`metadata.deletionTimestamp`字段設置一個值，而不是刪除它，這將觸發監控該對象的控制器執行他們所能處理的任意終止器。 詳情參考：[Extend the Kubernetes API with CustomResourceDefinitions](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) ## 自定義控制器 單純設置了自定義資源，并沒有什么用，只有跟自定義控制器結合起來，才能將資源對象中的聲明式API翻譯成用戶所期望的狀態。自定義控制器可以用來管理任何資源類型，但是一般是跟自定義資源結合使用。 請參考使用[Operator](https://coreos.com/blog/introducing-operators.html)模式，該模式可以讓開發者將自己的領域知識轉換成特定的kubenretes API擴展。 ## API server聚合 Aggregated（聚合的）API server是為了將原來的API server這個巨石（monolithic）應用給拆分成，為了方便用戶開發自己的API server集成進來，而不用直接修改kubernetes官方倉庫的代碼，這樣一來也能將API server解耦，方便用戶使用實驗特性。這些API server可以跟core API server無縫銜接，使用kubectl也可以管理它們。 詳情參考[Aggregated API Server](aggregated-api-server.md)。 ## 參考 - [Custom Resources](https://kubernetes.io/docs/concepts/api-extension/custom-resources/) - [Extend the Kubernetes API with CustomResourceDefinitions](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) - [Introducing Operators: Putting Operational Knowledge into Software](https://coreos.com/blog/introducing-operators.html)