[[397517]]

最近有點(diǎn)太忙了，所以更新比較慢，然后之前 Go 進(jìn)階訓(xùn)練營更新的有點(diǎn)太久了，準(zhǔn)備換換腦子，雖然我工作上一直和 Kubernetes 打交道但是還一直沒有更新過這一塊的相關(guān)內(nèi)容，所以就有了接下來的這個(gè)系列。

• PS: 對(duì)于這一塊作者本身也是一個(gè)初學(xué)者，有所錯(cuò)漏，在所難免，希望發(fā)現(xiàn)的大佬可以幫助指正，萬分感謝

Kubernetes擴(kuò)展: Operator 這個(gè)系列文章主要面向的是對(duì) Kubernetes 的基本概念已經(jīng)有了一定的了解，想對(duì) Kubernetes 進(jìn)行一些擴(kuò)展開發(fā)或者是對(duì) Kubernetes 的工作模式能夠有更深入了解的同學(xué)(PS：和我差不多)。這個(gè)小系列會(huì)更新 9 - 10 篇文章，這是第一篇 Operator概述: 如何對(duì) Kubernetes 進(jìn)行擴(kuò)展，接下來兩周工作日每天會(huì)更新一篇，想要及時(shí)獲取更新可以移動(dòng)到文章底部關(guān)注微信訂閱號(hào)。

Kubernetes 有哪些擴(kuò)展點(diǎn)?

Kubernetes 是一個(gè)可移植的、可擴(kuò)展的開源平臺(tái)，用于管理容器化的工作負(fù)載和服務(wù)，可促進(jìn)聲明式配置和自動(dòng)化。Kubernetes 擁有一個(gè)龐大且快速增長的生態(tài)系統(tǒng)。Kubernetes 的服務(wù)、支持和工具廣泛可用[^1]。

雖然現(xiàn)在 Kubernetes 已經(jīng)是容器編排的事實(shí)標(biāo)準(zhǔn)，其本身的功能也非常豐富并且靈活，但是也不能滿足所有人的需求，在遇到 Kubernetes 提供的能力無法滿足我們需求的時(shí)候，我們就可以利用其強(qiáng)大的擴(kuò)展能力進(jìn)行定制。

所以問題來了: Kubernetes 有哪些擴(kuò)展點(diǎn)呢?

kubernate 擴(kuò)展

如上圖所示，從客戶端到底層容器運(yùn)行時(shí)，絕大部分地方 Kubernetes 都為我們預(yù)留了擴(kuò)展點(diǎn)，我們從上往下一個(gè)一個(gè)的來看

1. kubectl

kubectl 是我們平時(shí)和 Kubernetes 交互使用的最多的客戶端工具，常見的運(yùn)維操作都會(huì)通過 kubectl 來完成，kubectl 為我們提供了插件機(jī)制來方便擴(kuò)展。

kubectl 插件其實(shí)就是以kubectl-為前綴的任意可執(zhí)行文件 ，執(zhí)行 kubectl 插件的時(shí)候可以通過 kubectl 插件名 參數(shù) 的方式運(yùn)行插件。

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

2. APIServer

聚合層

從 Kubernetes v1.7 版本之后 APIServer 引入了聚合層的功能，這個(gè)功能可以讓每個(gè)開發(fā)者都能夠?qū)崿F(xiàn)聚合 API 服務(wù)暴露它們需要的接口，這個(gè)過程不需要重新編譯 Kubernetes 的任何代碼[^3]。

如果我們將下面這個(gè)資源提交給 Kubernetes 之后，用戶在訪問 API 服務(wù)器的 /apis/metrics.Kubernetes.io/v1beta1 路徑時(shí)，會(huì)被轉(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 

準(zhǔn)入控制

除此之外無論是從 kubectl 還是 client-go 等其他客戶端發(fā)起的請(qǐng)求都會(huì)發(fā)送到 APIServer 經(jīng)過 認(rèn)證 -> 鑒權(quán) -> 準(zhǔn)入控制 的步驟，這其中的每一步我們都可以對(duì)其進(jìn)行擴(kuò)展，而這其中用的最多的就是準(zhǔn)入控制的擴(kuò)展，這一塊后續(xù)會(huì)一篇文章詳細(xì)講到。

準(zhǔn)入控制當(dāng)中又會(huì)先經(jīng)過，變更準(zhǔn)入控制 MutatingAdmissionWebhook，然后再經(jīng)過驗(yàn)證準(zhǔn)入控制 ValidatingAdmissionWebhook，任何一個(gè)準(zhǔn)入控制器返回了錯(cuò)誤這個(gè)請(qǐng)求都會(huì)失敗，例如這兩個(gè)準(zhǔn)入控制器我們可以做很多事情，例如注入 sidecar，驗(yàn)證資源，調(diào)整 pod 的配額等等。

3. Kubernetes 資源

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

4. Controller 控制器

Kubernetes 中資源的狀態(tài)的維護(hù)都是 Controller 來實(shí)現(xiàn)的，Controller 會(huì)不斷的嘗試將一個(gè)資源調(diào)整為我們描述的狀態(tài)，這其實(shí)也就是我們常說的聲明式 api，聲明式 api 背后具體的活都是 Controller 干的。Controller 一般會(huì)配合著 CRD 一起使用。

5. Schedule 調(diào)度器

調(diào)度器是一種特殊的控制器，負(fù)責(zé)監(jiān)視 Pod 變化并將 Pod 分派給節(jié)點(diǎn)，調(diào)度器可以被直接替換掉或者是使用多個(gè)調(diào)度器，除此之外官方默認(rèn)的調(diào)度器也支持 WebHook。[^5]

6. CNI 網(wǎng)絡(luò)插件

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

7. CSI 存儲(chǔ)插件

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

8. CRI 容器運(yùn)行時(shí)

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

Operator

Kubernetes 是一個(gè)高度可擴(kuò)展的系統(tǒng)，雖然它的擴(kuò)展點(diǎn)這么多，但是一般來說我們接觸的比較多的還是 自定義資源，控制器，準(zhǔn)入控制，有些還會(huì)對(duì) kubectl 和 調(diào)度器做一些擴(kuò)展，其他的大部分使用成熟的開源組件就可以了。而我們這個(gè)系列關(guān)注的 Operator 就會(huì)涉及到 自定義資源，控制器和準(zhǔn)入控制。

Operator 遵循 Kubernetes 的理念，它利用自定義資源管理應(yīng)用及其組件， Operator 模式會(huì)封裝你編寫的任務(wù)自動(dòng)化代碼。

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

• 按需部署應(yīng)用
• 獲取/還原應(yīng)用狀態(tài)的備份
• 處理應(yīng)用代碼的升級(jí)以及相關(guān)改動(dòng)。例如，數(shù)據(jù)庫 schema 或額外的配置設(shè)置
• 發(fā)布一個(gè) service，要求不支持 Kubernetes API 的應(yīng)用也能發(fā)現(xiàn)它
• 模擬整個(gè)或部分集群中的故障以測試其穩(wěn)定性
• 在沒有內(nèi)部成員選舉程序的情況下，為分布式應(yīng)用選擇首領(lǐng)角色

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

除了我們自己開發(fā)之外還可以在 https://operatorhub.io/ 上找到別人開發(fā)的現(xiàn)成的 Operator 進(jìn)行使用

總結(jié)

Kubernetes 從 2014 年發(fā)布至今已經(jīng) 7 年了，我從畢業(yè)加入到現(xiàn)在的團(tuán)隊(duì)從事周邊的工作也已經(jīng)快 3 年了，期間雖然對(duì) Kubernetes 已經(jīng)有了基本的了解但是還是一直都沒有對(duì) Kubernetes 本身進(jìn)行過擴(kuò)展的開發(fā)，這篇文章寫完之后算是對(duì) Kubernetes 擴(kuò)展開發(fā)有了一個(gè)基本的了解，希望對(duì)你也能有所幫助。

參考文獻(xiàn)

[^1]: Kubernetes 是什么?

https://kubernetes.io/zh/docs/concepts/overview/what-is-kubernetes/

[^2]: 擴(kuò)展 Kubernetes

https://kubernetes.io/zh/docs/concepts/extend-kubernetes/

[^3]: 你該如何為 Kubernetes 定制特性:

https://draveness.me/cloud-native-kubernetes-extension/

[^4]: kubectl 插件管理工具 krew

https://github.com/kubernetes-sigs/krew

[^5]: Scheduler extender

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md

[^6]: Operator 模式

https://kubernetes.io/zh/docs/concepts/extend-kubernetes/operator/