Operator中怎么對Kubernetes進行擴展

小編給大家分享一下Operator中怎么對Kubernetes進行擴展，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

Kubernetes 有哪些擴展點?

Kubernetes  是一個可移植的、可擴展的開源平臺，用于管理容器化的工作負載和服務，可促進聲明式配置和自動化。Kubernetes  擁有一個龐大且快速增長的生態系統。Kubernetes 的服務、支持和工具廣泛可用[^1]。

雖然現在 Kubernetes 已經是容器編排的事實標準，其本身的功能也非常豐富并且靈活，但是也不能滿足所有人的需求，在遇到 Kubernetes  提供的能力無法滿足我們需求的時候，我們就可以利用其強大的擴展能力進行定制。

所以問題來了: Kubernetes 有哪些擴展點呢?

kubernate 擴展

如上圖所示，從客戶端到底層容器運行時，絕大部分地方 Kubernetes 都為我們預留了擴展點，我們從上往下一個一個的來看

1. kubectl

kubectl 是我們平時和 Kubernetes 交互使用的最多的客戶端工具，常見的運維操作都會通過 kubectl 來完成，kubectl  為我們提供了插件機制來方便擴展。

kubectl 插件其實就是以kubectl-為前綴的任意可執行文件 ，執行 kubectl 插件的時候可以通過 kubectl 插件名 參數  的方式運行插件。

就像 Ubuntu 使用 apt 管理軟件，mac 可以使用 brew 一樣，kubectl 也有類似的插件管理工具 krew [^4] ，同時我們可以從  https://krew.sigs.Kubernetes.io/plugins/ 查找是否已經存在我們需要的插件

2. APIServer

聚合層

從 Kubernetes v1.7 版本之后 APIServer 引入了聚合層的功能，這個功能可以讓每個開發者都能夠實現聚合 API  服務暴露它們需要的接口，這個過程不需要重新編譯 Kubernetes 的任何代碼[^3]。

如果我們將下面這個資源提交給 Kubernetes 之后，用戶在訪問 API 服務器的  /apis/metrics.Kubernetes.io/v1beta1 路徑時，會被轉發到集群中的  metrics-server.kube-system.svc服務上

apiVersion: apiregistration.Kubernetes.io/v1 kind: APIService metadata:   name: v1beta1.metrics.Kubernetes.io spec:   service:     name: metrics-server     namespace: kube-system   group: metrics.Kubernetes.io   version: v1beta1   insecureSkipTLSVerify: true   groupPriorityMinimum: 100   versionPriority: 100

準入控制

除此之外無論是從 kubectl 還是 client-go 等其他客戶端發起的請求都會發送到 APIServer 經過 認證 -> 鑒權 ->  準入控制 的步驟，這其中的每一步我們都可以對其進行擴展，而這其中用的最多的就是準入控制的擴展，這一塊后續會一篇文章詳細講到。

準入控制當中又會先經過，變更準入控制 MutatingAdmissionWebhook，然后再經過驗證準入控制  ValidatingAdmissionWebhook，任何一個準入控制器返回了錯誤這個請求都會失敗，例如這兩個準入控制器我們可以做很多事情，例如注入  sidecar，驗證資源，調整 pod 的配額等等。

3. Kubernetes 資源

我們常用的 Deployment、Pod、Node 等都是 Kubernetes  官方提供的內置資源，但是有的時候內置的資源無法滿足我們的需求的時候，就可以使用 CustomResource 也就是自定義資源。自定義資源常常會和  Controller 一起配合使用，不過需要注意的是使用自定義資源的時候需要思考一下如果只是一些配置可能 ConfigMap  會更加適合，不要濫用這個特性。

4. Controller 控制器

Kubernetes 中資源的狀態的維護都是 Controller 來實現的，Controller  會不斷的嘗試將一個資源調整為我們描述的狀態，這其實也就是我們常說的聲明式 api，聲明式 api 背后具體的活都是 Controller  干的。Controller 一般會配合著 CRD 一起使用。

5. Schedule 調度器

調度器是一種特殊的控制器，負責監視 Pod 變化并將 Pod 分派給節點，調度器可以被直接替換掉或者是使用多個調度器，除此之外官方默認的調度器也支持  WebHook。[^5]

6. CNI 網絡插件

CNI 網絡插件，全稱 Container Network Interface(容器網絡接口)包含一組用于開發插件去配置 Linux  容器中網卡的接口和框架。一般我們不會去對網絡插件做定制開發，而是采用開源的組件，例如 Flannel、Cilium，如果使用云服務的 Kubernetes  還會遇到一些定制的網絡插件， 例如阿里云有 Terway。

7. CSI 存儲插件

CSI 存儲插件，全稱 Container Storage Interface，可以通過 CSI 接口支持不同的存儲類型

8. CRI 容器運行時

CRI 容器運行時，全稱 Container Runtime Interface，是一組用于管理容器運行時和鏡像的 gRPC 接口，利用這個接口可以支持  docker、containerd 等不同的容器運行時

Operator

Kubernetes 是一個高度可擴展的系統，雖然它的擴展點這么多，但是一般來說我們接觸的比較多的還是  自定義資源，控制器，準入控制，有些還會對 kubectl 和 調度器做一些擴展，其他的大部分使用成熟的開源組件就可以了。而我們這個系列關注的 Operator  就會涉及到 自定義資源，控制器和準入控制。

Operator 遵循 Kubernetes 的理念，它利用自定義資源管理應用及其組件， Operator 模式會封裝你編寫的任務自動化代碼。

Operator 常見使用范圍包括[^6]:

• 按需部署應用

• 獲取/還原應用狀態的備份

• 處理應用代碼的升級以及相關改動。例如，數據庫 schema 或額外的配置設置

• 發布一個 service，要求不支持 Kubernetes API 的應用也能發現它

• 模擬整個或部分集群中的故障以測試其穩定性

• 在沒有內部成員選舉程序的情況下，為分布式應用選擇首領角色

從 Operator 理念的提出到現在已經有了很多工具可以幫助我們快速低成本的開發，其中最常用的就是 CoreOS 開源的 operator-sdk 和  k8s sig 小組維護的 kubebuilder，我們這個系列選用 kubebuilder。

除了我們自己開發之外還可以在 https://operatorhub.io/ 上找到別人開發的現成的 Operator 進行使用

以上是“Operator中怎么對Kubernetes進行擴展”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！