小編給大家分享一下Operator中怎么對Kubernetes進行擴展，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！
創(chuàng)新互聯(lián)是一家專業(yè)提供黃石企業(yè)網(wǎng)站建設(shè),專注與網(wǎng)站設(shè)計制作、網(wǎng)站建設(shè)、H5網(wǎng)站設(shè)計、小程序制作等業(yè)務(wù)。10年已為黃石眾多企業(yè)、政府機構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站設(shè)計公司優(yōu)惠進行中。
Kubernetes 是一個可移植的、可擴展的開源平臺，用于管理容器化的工作負載和服務(wù)，可促進聲明式配置和自動化。Kubernetes 擁有一個龐大且快速增長的生態(tài)系統(tǒng)。Kubernetes 的服務(wù)、支持和工具廣泛可用[^1]。
雖然現(xiàn)在 Kubernetes 已經(jīng)是容器編排的事實標(biāo)準(zhǔn)，其本身的功能也非常豐富并且靈活，但是也不能滿足所有人的需求，在遇到 Kubernetes 提供的能力無法滿足我們需求的時候，我們就可以利用其強大的擴展能力進行定制。
所以問題來了: Kubernetes 有哪些擴展點呢?
kubernate 擴展
如上圖所示，從客戶端到底層容器運行時，絕大部分地方 Kubernetes 都為我們預(yù)留了擴展點，我們從上往下一個一個的來看
kubectl 是我們平時和 Kubernetes 交互使用的最多的客戶端工具，常見的運維操作都會通過 kubectl 來完成，kubectl 為我們提供了插件機制來方便擴展。
kubectl 插件其實就是以kubectl-為前綴的任意可執(zhí)行文件 ，執(zhí)行 kubectl 插件的時候可以通過 kubectl 插件名 參數(shù) 的方式運行插件。
就像 Ubuntu 使用 apt 管理軟件，mac 可以使用 brew 一樣，kubectl 也有類似的插件管理工具 krew [^4] ，同時我們可以從 https://krew.sigs.Kubernetes.io/plugins/ 查找是否已經(jīng)存在我們需要的插件
從 Kubernetes v1.7 版本之后 APIServer 引入了聚合層的功能，這個功能可以讓每個開發(fā)者都能夠?qū)崿F(xiàn)聚合 API 服務(wù)暴露它們需要的接口，這個過程不需要重新編譯 Kubernetes 的任何代碼[^3]。
如果我們將下面這個資源提交給 Kubernetes 之后，用戶在訪問 API 服務(wù)器的 /apis/metrics.Kubernetes.io/v1beta1 路徑時，會被轉(zhuǎn)發(fā)到集群中的 metrics-server.kube-system.svc服務(wù)上
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 等其他客戶端發(fā)起的請求都會發(fā)送到 APIServer 經(jīng)過 認(rèn)證 -> 鑒權(quán) -> 準(zhǔn)入控制 的步驟，這其中的每一步我們都可以對其進行擴展，而這其中用的最多的就是準(zhǔn)入控制的擴展，這一塊后續(xù)會一篇文章詳細講到。
準(zhǔn)入控制當(dāng)中又會先經(jīng)過，變更準(zhǔn)入控制 MutatingAdmissionWebhook，然后再經(jīng)過驗證準(zhǔn)入控制 ValidatingAdmissionWebhook，任何一個準(zhǔn)入控制器返回了錯誤這個請求都會失敗，例如這兩個準(zhǔn)入控制器我們可以做很多事情，例如注入 sidecar，驗證資源，調(diào)整 pod 的配額等等。
我們常用的 Deployment、Pod、Node 等都是 Kubernetes 官方提供的內(nèi)置資源，但是有的時候內(nèi)置的資源無法滿足我們的需求的時候，就可以使用 CustomResource 也就是自定義資源。自定義資源常常會和 Controller 一起配合使用，不過需要注意的是使用自定義資源的時候需要思考一下如果只是一些配置可能 ConfigMap 會更加適合，不要濫用這個特性。
Kubernetes 中資源的狀態(tài)的維護都是 Controller 來實現(xiàn)的，Controller 會不斷的嘗試將一個資源調(diào)整為我們描述的狀態(tài)，這其實也就是我們常說的聲明式 api，聲明式 api 背后具體的活都是 Controller 干的。Controller 一般會配合著 CRD 一起使用。
調(diào)度器是一種特殊的控制器，負責(zé)監(jiān)視 Pod 變化并將 Pod 分派給節(jié)點，調(diào)度器可以被直接替換掉或者是使用多個調(diào)度器，除此之外官方默認(rèn)的調(diào)度器也支持 WebHook。[^5]
CNI 網(wǎng)絡(luò)插件，全稱 Container Network Interface(容器網(wǎng)絡(luò)接口)包含一組用于開發(fā)插件去配置 Linux 容器中網(wǎng)卡的接口和框架。一般我們不會去對網(wǎng)絡(luò)插件做定制開發(fā)，而是采用開源的組件，例如 Flannel、Cilium，如果使用云服務(wù)的 Kubernetes 還會遇到一些定制的網(wǎng)絡(luò)插件， 例如阿里云有 Terway。
CSI 存儲插件，全稱 Container Storage Interface，可以通過 CSI 接口支持不同的存儲類型
CRI 容器運行時，全稱 Container Runtime Interface，是一組用于管理容器運行時和鏡像的 gRPC 接口，利用這個接口可以支持 docker、containerd 等不同的容器運行時
Kubernetes 是一個高度可擴展的系統(tǒng)，雖然它的擴展點這么多，但是一般來說我們接觸的比較多的還是 自定義資源，控制器，準(zhǔn)入控制，有些還會對 kubectl 和 調(diào)度器做一些擴展，其他的大部分使用成熟的開源組件就可以了。而我們這個系列關(guān)注的 Operator 就會涉及到 自定義資源，控制器和準(zhǔn)入控制。
Operator 遵循 Kubernetes 的理念，它利用自定義資源管理應(yīng)用及其組件， Operator 模式會封裝你編寫的任務(wù)自動化代碼。
Operator 常見使用范圍包括[^6]:
按需部署應(yīng)用
獲取/還原應(yīng)用狀態(tài)的備份
處理應(yīng)用代碼的升級以及相關(guān)改動。例如，數(shù)據(jù)庫 schema 或額外的配置設(shè)置
發(fā)布一個 service，要求不支持 Kubernetes API 的應(yīng)用也能發(fā)現(xiàn)它
模擬整個或部分集群中的故障以測試其穩(wěn)定性
在沒有內(nèi)部成員選舉程序的情況下，為分布式應(yīng)用選擇首領(lǐng)角色
從 Operator 理念的提出到現(xiàn)在已經(jīng)有了很多工具可以幫助我們快速低成本的開發(fā)，其中最常用的就是 CoreOS 開源的 operator-sdk 和 k8s sig 小組維護的 kubebuilder，我們這個系列選用 kubebuilder。
除了我們自己開發(fā)之外還可以在 https://operatorhub.io/ 上找到別人開發(fā)的現(xiàn)成的 Operator 進行使用
以上是“Operator中怎么對Kubernetes進行擴展”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！
重慶分公司
重慶分公司
