天天看點

使用 CRD 擴充您的 Kubernetes API

關注微信公衆号《雲原生CTO》更多雲原生幹貨等你來探索
使用 CRD 擴充您的 Kubernetes API

雲原生CTO

專注于雲原生領域kubernetes、istio、serverless、prometheus、golang、rust核心技術二次開發課程打造及技術經驗分享,為你雲原生之旅保駕護航!

專注于 ​<code>​雲原生技術​</code>​ 分享

提供優質 ​<code>​雲原生開發​</code>​ 視訊技術教育訓練

​<code>​面試技巧​</code>​,及技術疑難問題 ​<code>​解答​</code>​

使用 CRD 擴充您的 Kubernetes API

雲原生技術分享不僅僅局限于​<code>​Go​</code>​、​<code>​Rust​</code>​、​<code>​Python​</code>​、​<code>​Istio​</code>​、​<code>​containerd​</code>​、​<code>​CoreDNS​</code>​、​<code>​Envoy​</code>​、​<code>​etcd​</code>​、​<code>​Fluentd​</code>​、​<code>​Harbor​</code>​、​<code>​Helm​</code>​、​<code>​Jaeger​</code>​、​<code>​Kubernetes​</code>​、​<code>​Open Policy Agent​</code>​、​<code>​Prometheus​</code>​、​<code>​Rook​</code>​、​<code>​TiKV​</code>​、​<code>​TUF​</code>​、​<code>​Vitess​</code>​、​<code>​Argo​</code>​、​<code>​Buildpacks​</code>​、​<code>​CloudEvents​</code>​、​<code>​CNI​</code>​、​<code>​Contour​</code>​、​<code>​Cortex​</code>​、​<code>​CRI-O​</code>​、​<code>​Falco​</code>​、​<code>​Flux​</code>​、​<code>​gRPC​</code>​、​<code>​KubeEdge​</code>​、​<code>​Linkerd​</code>​、​<code>​NATS​</code>​、​<code>​Notary​</code>​、​<code>​OpenTracing​</code>​、​<code>​Operator Framework​</code>​、​<code>​SPIFFE​</code>​、​<code>​SPIRE​</code>​ 和 ​<code>​Thanos​</code>​等

為開發者提供一個平台,自動部署,縮放和整個主機群集應用程式容器的操作後,​<code>​Kubernetes​</code>​确實鞏固了它的方式成為一個事實上的标準

使用 ​<code>​Kubernetes​</code>​,您可以靈活地在任何時間更有效地推出更新,并在需要時将流量轉移到新版本。它為您提供了根據您的要求擴充和縮小應用程式的選項,您可以選擇應用程式與其他應用程式或現實世界的互動方式。 在這篇文章中,我們将看看:

什麼是 CRD

它們是如何工作的

你怎麼能創造一個!

如何删除 CRD

Litmus中使用的真實 CRD 示例

在本文結束時,您将徹底了解什麼是 ​<code>​CR、CRD​</code>​ 的工作原理以及​<code>​Litmus​</code>​如何在日常用例中實作它們。 另外對于​<code>​kubernetes​</code>​二次開發技術棧相當之廣泛,為了更多雲原生愛好者更能深入的了解​<code>​kubernetes​</code>​二次開發能力,我們開展了​<code>​kubernetes operator​</code>​二次開發訓練營進階三的體系課,感興趣的可以直接​​點選這裡​​

通過利用所謂的資源, ​<code>​Kubernetes​</code>​ 可以提供大量這樣的功能。一個資源是​<code>​K8S API​</code>​端點,使您可以存儲任何類型的​<code>​API​</code>​對象。但是,如果開發人員需要根據他們的特定需求定制對象或資源怎麼辦?這是自定義資源出現的地方。

作為 ​<code>​Kubernetes 1.7​</code>​ 版本的一部分,他們引入了自定義資源的概念,通過添加對您的應用程式有用的任何類型的​<code>​API​</code>​對象來擴充功能。自定義資源定義 (​<code>​CRD​</code>​)用于定義自定義資源。這是将 ​<code>​Kubernetes​</code>​ 功能擴充到預設安裝之外的強大方法。

如上所述,我們在 ​<code>​Kubernetes​</code>​ 中建立的幾乎所有東西都是一種資源。一個 ​<code>​Pod​</code>​、一個​<code>​service​</code>​、一個​<code>​deploy​</code>​或一個​<code>​secret​</code>​,它們都是一種資源。這些資源通常由負責擷取資源中的資訊并将其轉化為有用資訊的控制器進行監控。

我們以建立 ​<code>​Pod​</code>​ 資源時發生的情況為例。每當您修改 ​<code>​Pod​</code>​ 資源時,即添加、更改或更新資源時,都會有一個控制器收到有關更改的通知。每當控制器看到 ​<code>​Pod​</code>​ 資源被添加或更新時,它就會查找資源中的資訊,然後決定下一步做什麼。對于新​<code>​Pod​</code>​,它會找出負責運作工作負載的節點并将其配置設定給該節點。然後該節點上的另一個控制器接收此配置設定,進而確定啟動所需的容器。

自定義資源是使用自定義資源定義定義的,這就是縮寫 ​<code>​CRD​</code>​而不是 ​<code>​CR​</code>​ 的原因。建立 ​<code>​CRD​</code>​ 後,​<code>​Kubernetes API​</code>​ 伺服器會為 ​<code>​CRD​</code>​中指定的每個版本建立一個 ​<code>​RESTful​</code>​ 路徑。根據​<code>​CRD​</code>​檔案中定義的範圍,該路徑可以被整個叢集全局通路,也可以僅被特定項目通路。​<code>​CR​</code>​ 一旦由 ​<code>​CRD​</code>​ 定義,就會存儲在​<code>​etcd​</code>​叢集中。​<code>​Kubernetes API​</code>​ 伺服器負責資源生命周期和複制。它的作用類似于原生資源,當一個項目被删除時,所有的自定義資源和原生資源也會被删除。

作為先決條件,您需要 ​<code>​Kubernetes 1.7​</code>​ 或更高版本并安裝 ​<code>​kubectl​</code>​ 工具才能建立​<code>​CRD​</code>​。就像 ​<code>​Kubernetes​</code>​ 世界中的許多其他檔案一樣,​<code>​CRD​</code>​ 也可以在 ​<code>​YAML​</code>​檔案的幫助下建立。​<code>​CRD YAML​</code>​ 檔案由幾個字段組成,其中列出了一些重要的字段:

metadata.name:您正在建立的 CRD 的名稱

spec.group:CRD 對象所屬的組的名稱。

spec.versions:它儲存将建立的自定義資源的不同版本。

spec.names:用于定義如何描述您的自定義資源。您可以在此處添加您的 CR 的複數、單數和短名稱,稍後在通過 kubectl 管理它時會很友善。

spec.names.kind:定義可以使用 CRD 建立的 CR 類型。像部署,CronJob,CronTab。

spec.scope:定義 CR 的範圍。它可以設定為“叢集”或“命名空間”。預設情況下,它設定為“命名空間”。

下面的清單顯示了一個示例 ​<code>​CRD ourcrd.yaml​</code>​:

我們可以簡單地使用建立上面的​<code>​CRD​</code>​

通過 ​<code>​kubectl​</code>​建立 ​<code>​CRD​</code>​後,會生成端點 ​<code>​URL​</code>​,可用于建立和管理自定義對象。建立此端點可能需要幾秒鐘。

你可能會有這樣的疑問:“好吧!太酷了,但是我可能會如何/在哪裡使用它?”,好吧,這是一個如何使用它的示例。

讓我們使用我們用​<code>​CRD​</code>​建立的種類來建立一個清單。例如,我們有​<code>​my-kind.yaml​</code>​

這裡我們使用我們在 ​<code>​CRD​</code>​中定義的相同種類,然後我們定義我們希望我們的種類對象具有的字段。就像在這個例子中一樣,我們為我們的應用程式提供了 ​<code>​value1​</code>​ 和 ​<code>​value2​</code>​(如 ​<code>​CRD​</code>​ 中提供的)字段。在實際示例中,這些字段将類似于​<code>​image、URI​</code>​等。

現在,如果我們運作​<code>​kubectl create -f my-kind.yaml​</code>​我們的應用程式可以使用我們使用上面的清單建立的資料。要檢視發生了什麼,我們可以運作​<code>​kubectl get cn -o yaml​</code>,我們可以檢視有關我們剛剛建立的内容的詳細資訊。

​<code>​cn​</code>​ 是我們上面給 ​<code>​CRD​</code>​ 的簡稱

要删除我們建立的 ​<code>​CRD​</code>​和資源,隻需像處理任何其他資源一樣運作 ​<code>​kubectl delete​</code>​。當您删除 ​<code>​CRD​</code>​ 時,伺服器會解除安裝使用 ​<code>​CRD​</code>​ 建立的 ​<code>​RESTful​</code>​端點。随着 ​<code>​CRD​</code>​ 的删除,使用它建立的所有自定義資源也将被删除且無法檢索。

在我們旅程的最後一部分中,讓我們實際看看實際項目如何利用這些概念來擴充其需求并實際實施它們。 我将以 ​<code>​Litmus​</code>​ 為例作為我們将研究其 ​<code>​CRD​</code>​ 的項目。

​<code>​Litmus​</code>​ 是一個在雲原生環境中實踐混沌工程的架構。​<code>​litmus​</code>​提供了一個混沌​<code>​operator​</code>​,它有一大套的混亂實驗中心,詳細的文檔,和友好的社群。​<code>​Litmus​</code>​ 非常易于使用;您還可以設定一個非常快速的示範環境來安裝和運作 ​<code>​Litmus​</code>​ 實驗。

​<code>​Litmus​</code>​ 中幾個重要的 ​<code>​CRD​</code>​ 如下:

混沌引擎(ChaosEngine)

混沌實驗(ChaosExperiment)

混沌結果(ChaosResult)

​<code>​ChaosEngine​</code>​:​<code>​ChaosEngine CR​</code>​ 是為給定的應用程式建立的,并用 ​<code>​appLabel​</code>​ 标記。此 ​<code>​CR​</code>​将一個或多個 ​<code>​ChaosExperiments​</code>​ 與應用程式聯系起來。

​<code>​ChaosResult​</code>​:​<code>​ChaosResult CR​</code>​ 由​<code>​operator​</code>​在實驗運作後建立。每個 ​<code>​ChaosEngine​</code>​ 維護一個 ​<code>​ChaosResult CR​</code>​。​<code>​ChaosResult CR​</code>​ 有助于了解給定的 ​<code>​ChaosExperiment​</code>​。此 ​<code>​CR​</code>​ 用于生成非常有用的混沌分析——例如,當某些元件在混沌實驗之間更新時,需要輕松比較結果

要更廣泛地了解 ​<code>​CR​</code>​,請通路此處。您會找到叢集工作流、​<code>​Cron​</code>​ 工作流等的 ​<code>​CRD​</code>​

https://github.com/litmuschaos/litmus/blob/master/litmus-portal/litmus-portal-crds.yml

瞧,您已經成功地了解了 ​<code>​CRD​</code>​ 的概念以及如何建立它們。您當然可以擴充這些并玩轉以建立自己的東西。

自定義資源定義增加了 ​<code>​Kubernetes​</code>​ 已經為其使用者提供的令人難以置信的功能。​<code>​CRD​</code>​ 有助于擴充 ​<code>​Kubernetes​</code>​ 的功能,使其成為更通用的容器編排工具。您可以使用自定義資源添加自己的資源,以幫助滿足您的特定要求。而且,您可以像使用任何原生 ​<code>​Kubernetes​</code>​服務一樣使用這些資源,并利用 ​<code>​Kubernetes​</code>​ 必須提供的所有功能,例如安全性、​<code>​RBAC​</code>​、​<code>​API​</code>​ 服務和 ​<code>​CLI​</code>​。您還可以使用動态注冊讓自定義資源在叢集運作時出現和消失。