Kubernetes API穩(wěn)定性技術(shù)架構(gòu)設(shè)計(jì)

1、 Kubernetes API 穩(wěn)定性技術(shù)架構(gòu)設(shè)計(jì) 【導(dǎo)讀】Kubernetes 是一個(gè)靈活強(qiáng)大的生產(chǎn)級(jí)別的開源容器編排系統(tǒng)，與服務(wù)器，網(wǎng)絡(luò)，存儲(chǔ)等各基礎(chǔ)設(shè)施和認(rèn)證授權(quán)，虛擬化，大數(shù)據(jù)等各種技術(shù)領(lǐng)域有著密切的交互與協(xié)作，同時(shí)也在不斷吸納各種其他領(lǐng)域， 迅速地發(fā)展壯大。如何保證這樣一個(gè)幾乎包羅萬象的系統(tǒng)在不斷增加和擴(kuò)展特性的快速迭代過程中各版本的穩(wěn)定性和兼容性自然是一個(gè)至關(guān)重要的課題。本文僅就 Kubernetes 的 API 相關(guān)內(nèi)容一窺 Kubernetes 的穩(wěn)定性設(shè)計(jì)。Kubernetes API 是 Kubernetes 系統(tǒng)的重要組成部分，組件之間的所有操作和通信以及外部對(duì) Kube

2、r-netes 的調(diào)用都是由 API Server 處理的 REST API 調(diào)用。API 的設(shè)計(jì)對(duì)于產(chǎn)品內(nèi)部通信和外部協(xié)作。1.API 結(jié)構(gòu)與版本Kubernetes API 是通過 HTTP 提供的編程接口，以 REST 風(fēng)格組織并管理資源，支持通過 POST ，PUT ，DELETE ， GET 等標(biāo)準(zhǔn)的 HTTP 方法對(duì)資源進(jìn)行增刪改查等操作。1.1資源Kubernetes 中所有內(nèi)容都被抽象為資源。所有資源都可以使用清單文件(manifest file)進(jìn)行描述，使用Etcd 數(shù)據(jù)庫(kù)進(jìn)行存儲(chǔ)并由 API Server 統(tǒng)一管理。資源分為集群和命名空間兩級(jí)作用域，命名空間級(jí)資源會(huì)在其命

3、名空間刪除時(shí)被刪除。上圖資源類別并不代表其作用域所有資源在其資源對(duì)象模式(清單文件)中都有一個(gè)具體的表示形式，稱為 Kind。同一資源的多個(gè)對(duì)象(實(shí)例)可以組成集合可以通過 kubectl api-resources 命令查看當(dāng)前 Kubernetes 環(huán)境支持的所有資源的名稱，縮寫，api 組，作用域及其對(duì)應(yīng)的 Kind1.2 APIKubernetes API 大多數(shù)情況下遵循標(biāo)準(zhǔn)的 HTTP REST 規(guī)范，JSON 和 Protobuf 是其主要序列化結(jié)構(gòu)，資源通過 API 接口傳入 API Server 最終持久化到 Etcd 數(shù)據(jù)庫(kù)。API 是由 API Server 組件提供服務(wù)

4、，API Server 是 Kubernetes 的管理中心，是唯一能夠與 Etcd 數(shù)據(jù)庫(kù)交互的組件1.2.1 API 群組Kubernetes API 除了提供組織和管理各種資源的接口外，還包括一些系統(tǒng)層面的接口。目前 API 主要分為三種形式:除了系統(tǒng)級(jí) API 外，Kubernetes 基本上是以 API Group(API 群組)的方式組織各種 API 的，核心組 API并未使用/apis/core/v1 路徑是歷史原因(事實(shí)上核心組也成為遺留組)。API 群組是一組相關(guān)的 API 對(duì)象的集合，使用群組概念能夠更方便的管理和擴(kuò)展 API。結(jié)構(gòu)示意如下:1.2.2 API 版本為了在兼

5、容舊版本的同時(shí)不斷升級(jí)新的 API，Kubernetes 支持多種 API 版本，不同的 API 版本代表其處于不同的穩(wěn)定性階段，低穩(wěn)定性的 API 版本在后續(xù)的產(chǎn)品升級(jí)中可能成為高穩(wěn)定性的版本。API 版本規(guī)則是通過基于 API level 選擇版本，而不是基于資源和域級(jí)別選擇，是為了確保 API 能夠描述一個(gè)清晰的連續(xù)的系統(tǒng)資源和行為的視圖，能夠控制訪問的整個(gè)過程和控制實(shí)驗(yàn)性 API 的訪問。API 通過這種三級(jí)漸進(jìn)式版本共存與演化策略，在不斷吸納新的功能特性并給予其足夠的孵化空間的同時(shí)，保證了整體 API 的可用性和穩(wěn)定性。資源定位三元組API Group，API Version 和 R

6、esource(GVR 三元組)就可以唯一確定一個(gè)資源的 API 路徑。如 /apis/r-bac.authorization.k8s.io/v1beta1/clusterroles 。對(duì)于命名空間級(jí)資源則需要額外包含具體命名空間(否則將請(qǐng)求所有命名空間下相應(yīng)資源)，如/apis/apps/v1/namespaces/kube-system/deployments 。對(duì)應(yīng)到資源對(duì)象模式(清單文件)三元組則為 API Group，API Version 和 Kind(GVK)，相應(yīng)字段為apiVersion 和 kind ，如apiVersion: app/v1，kind: Deployment

7、 。Kubernetes 組件默認(rèn)啟用加密通信，并需要請(qǐng)求者提供憑證，為了更方便地請(qǐng)求 API，可以開啟代理訪問。kubectl proxy -port=8888 # 開啟代理訪問curl http:/localhost:8888/api/pods/ # kubectl 代理會(huì)自動(dòng)使用默認(rèn)憑證路徑(/etc/kubernetes/ssl/)下的憑證文件(kube-proxy.xx)可以通過 kubectl api-versions 命令查看當(dāng)前 Kubernetes 環(huán)境啟用的所有 API 群組及其版本。1.3 數(shù)據(jù)持久化與無損轉(zhuǎn)換用戶向 Kubernetes 發(fā)起資源構(gòu)建請(qǐng)求時(shí)只提供了一個(gè)資

8、源清單文件(如 deployment.yaml)，但事實(shí)上Kubernetes 基于可用性和穩(wěn)定性的考慮，卻能夠支持同時(shí)使用不同穩(wěn)定性的 API 版本訪問同一資源，返回不同版本的資源數(shù)據(jù)。這一靈活的特性有賴于 API Server 的資源數(shù)據(jù)無損耗轉(zhuǎn)換機(jī)制。1.3.1 數(shù)據(jù)持久化資源數(shù)據(jù)是持久化到 Etcd 數(shù)據(jù)庫(kù)中的，而從資源清單文件到持久化到 Etcd 數(shù)據(jù)庫(kù)的資源數(shù)據(jù)的大致流程如下:1. 客戶端(kubectl，curl，sdk 等)得到資源清單文件(YAML 或 JSON 格式)2. 部分支持格式轉(zhuǎn)換的客戶端(如 kubectl，sdk 等)會(huì)先將 YAML 格式的資源清單文件轉(zhuǎn)換為

9、JSON 格式化，然后根據(jù)清單字段或相應(yīng)參數(shù)獲取 API Server 請(qǐng)求路徑，發(fā)送到 API Server3. API Server 對(duì)收到的資源清單文件進(jìn)行準(zhǔn)入校驗(yàn)和字段預(yù)處理，生成資源數(shù)據(jù)，對(duì)同資源的多個(gè)版本進(jìn)行無損轉(zhuǎn)換4. API Server 將資源數(shù)據(jù)轉(zhuǎn)換為指定的存儲(chǔ)版本5. API Server 將存儲(chǔ)版本的資源數(shù)據(jù)按照指定編碼(PROTOBUF 或 JSON)進(jìn)行序列化，以 key-value的 方式存儲(chǔ)到 Etcd 中API Server 啟動(dòng)時(shí)可以通過-storage-versions 參數(shù)指定資源數(shù)據(jù)的存儲(chǔ)版本(默認(rèn)是最新穩(wěn)定版，如v1); 通過-storage-med

10、ia-type 參數(shù)指定序列化編碼(默認(rèn)是 application/tobuf)。Etcd 數(shù)據(jù)庫(kù)中的資源數(shù)據(jù)是作為 value 存儲(chǔ)的，而對(duì)應(yīng)的 key 則是按照/registry/#k8s 對(duì)象/#命名空間/#具體實(shí)例名的規(guī)范格式生成的。1.3.2 無損轉(zhuǎn)換Etcd 數(shù)據(jù)庫(kù)中只存儲(chǔ)了資源的一個(gè)指定版本，但客戶端傳入的資源清單文件中指定的資源版本和客戶端向 API Server 請(qǐng)求的資源版本可能并不是 Etcd 數(shù)據(jù)庫(kù)中存儲(chǔ)的版本，API Server 如何在各個(gè)版本之間進(jìn)行無損轉(zhuǎn)換呢?如果一個(gè)資源存在眾多版本，那么編寫各種不同版本之間的轉(zhuǎn)換規(guī)則無疑是非常麻煩的，因此 API Server

11、 中維護(hù)著一個(gè) internal 版本，需要作版本轉(zhuǎn)換時(shí)，任意原版本都先轉(zhuǎn)換為 internal 版本，再由 internal 版本轉(zhuǎn)換到指定的目的版本，如此只要每個(gè)版本都可轉(zhuǎn)換為 internal 版本，則可以支持任意版本之間的轉(zhuǎn)換。而保證版本轉(zhuǎn)換過程中不出現(xiàn)數(shù)據(jù)丟失(即無損轉(zhuǎn)換)則是依靠 annotations(注解)實(shí)現(xiàn)。例如從版本 A 轉(zhuǎn)換到版本 B，對(duì)不同字段的處理如下:版本 A 和 B 中均存在的字段可直接轉(zhuǎn)換版本 A 中存在而版本 B 中不存在的字段將寫入注解中版本 A 中不存在而版本 B 中存在的字段，如果存在于版本 A 的注解中則從注解中讀取字段值，否則字段值置空2.API

12、擴(kuò)展Kubernetes 因其平臺(tái)級(jí)基礎(chǔ)設(shè)施的特殊性，與服務(wù)器，網(wǎng)絡(luò)，存儲(chǔ)，虛擬化，身份認(rèn)證等等絕大多數(shù)計(jì)算機(jī)軟硬件技術(shù)領(lǐng)域存在廣泛交集，這需要大量的適配與對(duì)接，此外作為底層容器編排引擎，也需要滿足高度的可擴(kuò)展性以面對(duì)大量的功能特性擴(kuò)展需求。常規(guī)的解決方案是修改 Kubernetes 相關(guān) API 和控制器的源代碼或者定義新的資源類型并作為新的核心資源 API 合并到 Kubernetes 官方社區(qū)代碼中。但這些方無疑會(huì)迅速使得 Kubernetes 核心 API 資源變得臃腫龐雜難以維護(hù)，最終導(dǎo)致 API 過載，這會(huì)為項(xiàng)目本身維護(hù)和產(chǎn)品生產(chǎn)環(huán)境運(yùn)行的穩(wěn)定性帶來巨大挑戰(zhàn)。Kubernetes

13、提供了兩種 API 擴(kuò)展機(jī)制保證核心 API 足夠精簡(jiǎn)的同時(shí)滿足龐雜的適配對(duì)接和特性擴(kuò)展需求:1. 自定義資源類型(CRD): 即 CustomResourceDefinitions。允許用戶通過資源清單的方式定義任意全新的資源對(duì)象類型，并由 API Server 管理自定義資源的整個(gè)生命周期，用戶還可以通過定義相應(yīng)的控制器對(duì)自定義資源及其他相關(guān)資源進(jìn)行監(jiān)視，協(xié)調(diào)和管理。通常將自定義資源和自定義控制器配合工作的方式統(tǒng)稱為 CRD 方式。2. API Server 聚合(AA): 即 API Server Aggregattion。其前身是用戶 API Server(UAS)，UAS 允許用戶設(shè)

14、計(jì)一套自定義的 API Server 與 Kubernetes 主 API Server 并行生效，可以在不影響原 API Server 的前提下實(shí)現(xiàn)更加復(fù)雜和定制化的邏輯和功能，但這種方式對(duì)代碼開發(fā)的要求會(huì)比較高。自定義 API Server 可以選擇與主 API Server 進(jìn)行聚合也可以獨(dú)立存在，但獨(dú)立存在的方式無法與 Kubernetes 很好的集成，因此自定義 API Server 普遍采用 API Server 聚合的方式。2.1 自定義資源類型Kubernetes 原生支持自定義資源的創(chuàng)建和生命周期維護(hù)，自定義資源類型一經(jīng)創(chuàng)建便與 Pod，Job，Secret 等內(nèi)建資源擁有同

15、等地位，可以像內(nèi)建資源一樣創(chuàng)建并運(yùn)行自定義資源類型的實(shí)例對(duì)象。自定義資源配合定制的控制器就可以完成如自動(dòng)化網(wǎng)絡(luò)管理，自動(dòng)化存儲(chǔ)管理，自動(dòng)化證書管理，自動(dòng)化應(yīng)用 集群管理等廣泛的特性需求。2.1.1 自定義資源自定義資源類型的創(chuàng)建每個(gè) API 資源都有相應(yīng)的 Group 群組和資源類型，聲明自定義資源就必須命名一個(gè)與已有群組不重復(fù)的新的 Group 群組，新的群組中可以有任意數(shù)量的自定義資源類型，并且這些資源類型可以與其他群組中的資源類型重名。自定義資源類型的聲明方式與 Kubernetes 的內(nèi)建資源的創(chuàng)建方式相同，都是通過資源清單文件進(jìn)行聲明并應(yīng)用，因?yàn)?CustomResourceDefi

16、nition 本身就是一種內(nèi)建資源。一個(gè)最簡(jiǎn)單的自定義資源類型的聲明清單示例如下:# apps-crd.yamlapiVersion: apiextensions.k8s.io/v1beta1 kind:CustomResourceDefinitionmetadata:name: apps.foo.bar spec:group: foo.bar version:v1 names:kind: App plural:appsscope: Namespaced各字段解釋如下:apiVersion: CustomResourceDefinition 這一內(nèi)建資源所在的群組及當(dāng)前使用的 api 版本。目

17、前為固定字段kind: 固定字段，表示是在聲明自定義資源類型: 自定義資源類型的全名，它由 spec.group 和 s.plural 字段組合而成spec.group: 自定義資源類型所在群組spec.version: 自定義資源類型的群組版本s.kind: 自定義資源的類型，慣例首字母大寫s.plural: 其值通常為 kind 的全小寫復(fù)數(shù)，關(guān)系到自定義資源在 REST API 中的 HTTP路徑s.scope: 表示自定義資源的作用范圍，Kubernetes 中大部分資源都是命名空間級(jí) (Name-spaced)自定義資源本身是不支持多版本的，但自定義資源的群組支持多版本。也就是說每一

18、個(gè)群組的特定版本里的所有自定義資源都不需要考慮資源版本之間的兼容問題，保證群組內(nèi)各資源的整體一致性。s 中還有許多其他字段，不指定則會(huì)由 API Server 在創(chuàng)建自定義資源類型時(shí)自動(dòng)填充。自定義資源類型聲明完成后就可以通過 kubectl create -f apps-crd.yaml 或 kubectl apply -f appscrd.yaml 命令進(jìn)行創(chuàng)建了，創(chuàng)建完成后可通過 kubectl get crd apps.foo.bar -o yaml 命令進(jìn)行查看。自定義資源類型創(chuàng)建完成后，其 REST API 的 HTTP 訪問路徑為/apis/foo.bar/v1/namespac

19、es/de-fault/apps (以 default 命名空間為例)。自定義資源的創(chuàng)建自定義資源類型創(chuàng)建完成后就可以創(chuàng)建相應(yīng)的自定義資源。一個(gè)簡(jiǎn)單的自定義資源的創(chuàng)建清單如下:# app.yaml apiVersion:foo.bar/v1 kind: Appmetadata: name:demospec:port: 3333path: /app自定義資源聲明完成后就可以通過 kubectl create -f app.yaml 或 kubectl apply -f app.yaml 命令進(jìn)行創(chuàng)建了，創(chuàng)建完成后可通過 kubectl get apps.foo.bar -o yaml 命令進(jìn)行查

20、看。自定義資源創(chuàng)建完成后，其 REST API 的 HTTP 訪問路徑為/apis/foo.bar/v1/namespaces/default/apps/demo (以 default 命名空間為例)。自定義資源 spec 下的字段只有在被特定控制器或應(yīng)用按照約定的規(guī)范讀取解析和處理后才具有實(shí)際意義。終止器自定義資源和內(nèi)建資源一樣都可以支持終止器(finalizer)，終止器允許控制器實(shí)現(xiàn)異步的預(yù)刪除鉤子。對(duì)于具有終止器的資源對(duì)象第一個(gè)刪除請(qǐng)求僅僅是為 metadata.deletionTimestamp 字段設(shè)置一個(gè)值， 而不是刪除它，然后觸發(fā)相應(yīng)控制器執(zhí)行自定義處理并刪除該資源對(duì)象的終止器

21、，最后再一次發(fā)出刪除請(qǐng)求。每個(gè)資源對(duì)象都可以有多個(gè)終止器，刪除資源對(duì)象時(shí)，只有當(dāng)其所有終止器都刪除后才會(huì)真正被刪除。2.1.2 自定義控制器在 Kubernetes 中，工作負(fù)載(workload)類的資源(如 ReplicaSet，Deployment，StatefulSet，CronJob等運(yùn)行容器的內(nèi)建資源)是通過控制器(controller)進(jìn)行管理的，這些控制器相當(dāng)于一個(gè)狀態(tài)機(jī)，用于控制對(duì)應(yīng) Pod 的具體狀態(tài)和行為。對(duì)于自定義資源，同樣可以為其編寫相應(yīng)的控制器，進(jìn)行資源數(shù)據(jù)的分析處理和 Pod 的狀態(tài)行為控制。自定義資源和自定義資制器的配合使用才能創(chuàng)建，配置和管理復(fù)雜的有狀態(tài)應(yīng)用，

22、真正提供聲明式 API 服務(wù)，實(shí)現(xiàn)新特性的添加和 Kubernetes API 的擴(kuò)展。Kubernetes 中控制器的主要工作模式如下:控制器代碼主要包括兩部分:客戶端 SDK: SDK 是 Kubernetes 官方提供的開發(fā)工具包(sdk 是 golang 編寫，又稱為 client-go)，提供諸如 Reflector，Delta FIFO queue，Thread safe Local store，Informer，Indexer， Workqueue 等與API Server 進(jìn)行交互的通用組件控制器特定內(nèi)容: 根據(jù)特定控制器提供的特定功能而編寫的相應(yīng)回調(diào)函數(shù)和處理邏輯。這部分是編

23、寫自定義控制器的主要內(nèi)容控制器的完整工作流如下:1. Reflector 反射器通過 List&Watch 機(jī)制從 API Server 獲取資源(包括內(nèi)建資源和自定義資源)變化2. Reflector 將獲取到的資源添加到 Delta FIFO 隊(duì)列中3. Informer 通知器從 Delta FIFO 隊(duì)列中彈出資源對(duì)象4. Informer 將得到的資源對(duì)象傳遞到 Indexer(索引器)5. Indexer 為資源對(duì)象構(gòu)建索引，以線程安全的方式將資源數(shù)據(jù)存儲(chǔ)到線程安全的 Key-Value 本地存儲(chǔ)中6. Informer 通過 Dispatch Event Handler 事件分發(fā)

24、處理函數(shù)將資源對(duì)象的 key 發(fā)送到自定義控制器7. 自定義控制器通過 Resource Event Handler 資源事件處理函數(shù)將資源對(duì)象 key 發(fā)送到 Workqueue 工作隊(duì)列8. Process Item 任務(wù)處理函數(shù)從工作隊(duì)列獲取資源對(duì)象 key 并將其傳遞給 Object Handler 資源對(duì)象處理函數(shù)9. 資源對(duì)象處理函數(shù)通過 Indexer 的引用從 Key-Value 本地存儲(chǔ)中獲取資源對(duì)象本身并進(jìn)行處理2.1.3 Operator 和 Kubebuilder聲明自定義資源并編寫自定義控制器進(jìn)行 Kubenetes API 擴(kuò)展的方式對(duì)于代碼開發(fā)有一定的要求。主要的

25、工作內(nèi)容如下:初始化項(xiàng)目結(jié)構(gòu)定義自定義資源編寫自定義資源相關(guān)代碼初始化自定義控制器編寫自定義控制器相關(guān)代碼(即業(yè)務(wù)邏輯)這其中除了定義自定義資源和編寫業(yè)務(wù)邏輯是需要針對(duì)具體需求單獨(dú)開發(fā)外，其他內(nèi)容都是通用的，可以自動(dòng)化完成，因此社會(huì)和官方提供了一些 CRD 開發(fā)腳手架以幫助開發(fā)者無需了解復(fù)雜的 Kubernetes API 特性的情況下迅速構(gòu)建 Kubernetes 擴(kuò)展應(yīng)用。目前比較流行的有兩個(gè):Operator Framework: CoreOS 公司(目前屬 redhat 旗下)開發(fā)和維護(hù) CRD 快速開發(fā)框架。它包括 Operator SDK 和 Operator Lifecycle

26、Manager 兩部分，前者是 Operator 核心開發(fā)工具包，后者對(duì) Operator 提供從安裝，更新到運(yùn)維的全生命周期管理Kubebuilder: Kubenetes 社區(qū)興趣小組開發(fā)和維護(hù)的 CRD 快速開發(fā)框架。提供與 Operator 類似的功能，但不支持 Operator 生命周期管理Operator 和 Kubebuilder 的實(shí)現(xiàn)原理和主要功能類似，二者均使用控制器工具和控制器運(yùn)行時(shí)，封裝結(jié)構(gòu)類似，使用難易度相當(dāng)，其主要區(qū)別如下:Operator SDK 原生支持 Ansible 和 Helm Operator; Kubebuilder 不支持Operator SDK 集

27、成 Operator Lifecycle Manager(OLM)，提供 Operator 全生命周期管理;Kubebuilder 不支持Kubebuilder 使用 Makefile 幫助用戶完成操作員的任務(wù)(構(gòu)建，測(cè)試，運(yùn)行，代碼生成等); OperatorSDK 當(dāng)前使用內(nèi)置子命令。Operator SDK 團(tuán)隊(duì)將來可能會(huì)遷移到基于 Makefile 的方法Kubebuilder 使用 Kustomize 來構(gòu)建部署清單; Operator SDK 使用帶有占位符的靜態(tài)文件Kubebuilder 改善了對(duì) admission 準(zhǔn)入和 CRD 轉(zhuǎn)換 webhooks 的支持; Operat

28、or SDK 尚未支持Kubebuilder 提供了更為完善的官方文檔鑒于 Operator Framework 的影響力 ，習(xí)慣性將基于 CRD 構(gòu)建的 Kubernetes 應(yīng)用稱為 Operator。相對(duì)于通過 Helm Charts 打包和部署 Kubenetes 應(yīng)用的方式，Operator 的自動(dòng)化程度更高，更加符合云原生理念，因此越來越流行，目前越來越多的常用應(yīng)用推出了自己的 Operator，Kubernetes 社區(qū)推出了 OperatorHub 以供用戶進(jìn)行 Operator 的發(fā)布的使用。Operator 是打包，運(yùn)行和維護(hù) Kubernetes 應(yīng)用程序的一種方式。一種

29、 Kubernetes 應(yīng)用程序不僅部署在 Kubernetes 上，還旨在使用和與 Kubernetes 的設(shè)施和工具協(xié)同工作。開發(fā)團(tuán)隊(duì)以 Kubernetes 抽象為基礎(chǔ)，以實(shí)現(xiàn)自動(dòng)化的整個(gè)生命周期。它管理的軟件。由于它們擴(kuò)展了 Kubernetes，因此操作員可以使用大型且不斷增長(zhǎng)的社區(qū)熟悉的術(shù)語來提供特定于應(yīng)用程序的 自動(dòng)化。適用于程序員，運(yùn)維人員可以更輕松地部署和運(yùn)行基礎(chǔ)應(yīng)用程序所依賴的服務(wù)。對(duì)于 基礎(chǔ)架構(gòu)工程師和供應(yīng)商，Operator 提供了一種在Kubernetes 集群上分發(fā)軟件的一致方法，并且通過在發(fā)現(xiàn)和糾正應(yīng)用程序問題之前減少支持負(fù)擔(dān)和異常出現(xiàn)的機(jī)會(huì)。Operator 最

30、初由 coreOS 公司（已被 RedHat 收購(gòu)）開發(fā)，逐步成為流行的一種打包，部署和管理Kubernetes/OpenShift 應(yīng)用的方法。Kubernetes/OpenShift 應(yīng)用是一個(gè)部署在集群上并使用 Kubernetes/OpenShift API 和 kubectl/oc 工具進(jìn)行管理的應(yīng)用程序。Operator 類似 于 Helm 和 Template，但是比它們都更加靈活，更加強(qiáng)大，更加方便。Operator 本質(zhì)上是一個(gè)自定義的控制器。它會(huì)在集群中運(yùn)行一個(gè) Pod 與 Kubernetes/OpenShift API Server 交互，并通過 CRD 引入新的資源類

31、型，這些新創(chuàng)建的資源 類型與集群上的資源類型如 Pod 等交互方式是一樣的。同時(shí) Operator 會(huì)監(jiān)聽自定義的資源類 型對(duì)象的創(chuàng)建與變化，并開始循環(huán)執(zhí)行，保證應(yīng)用處于被定義的狀態(tài)。一直以來，部署和管理 Kubernetes 應(yīng)用的方法有多種，這里列舉較流行的三個(gè)：一、Template 模板是 OpenShift 特有的應(yīng)用打包方式，它描述了一組對(duì)象，同時(shí)對(duì)這些對(duì) 象的配置可以進(jìn)行參數(shù)化處理，生成 OpenShift 容器平臺(tái)創(chuàng)建的對(duì)象列表。在模板中可以設(shè) 置所有在項(xiàng)目中有權(quán)限創(chuàng)建的任何資源。不足之處：無法保證線上資源狀態(tài)始終與參數(shù)設(shè)定的結(jié)果一致，如手動(dòng)增加 rc 的副本數(shù)時(shí)，不會(huì)自動(dòng)恢復(fù)到

32、與參數(shù)設(shè)定的副本數(shù)。在創(chuàng)建的時(shí)候設(shè)置參數(shù)，如果在應(yīng)用運(yùn)行時(shí)對(duì)參數(shù)動(dòng)態(tài)更新的話，則需要使用腳本命令使用所有的參數(shù)，重新生成資源列表。參數(shù)需要額外管理，不可靠。如果應(yīng)用有創(chuàng)建的順序有依賴，則無法滿足。無法根據(jù)參數(shù)的不同對(duì)資源進(jìn)行條件控制。二、對(duì)于 Kubernetes 熟悉的運(yùn)維開發(fā)人員，常會(huì)使用 Helm 來實(shí)現(xiàn)。Helm 是 Kubernetes 生態(tài)系統(tǒng)中的一個(gè)軟件包管理工具，與 Template 類似。不足之處：需要額外部署 Helm 客戶端及 Tiller。需要額外管理 helm 中的 charts 資源。無法保證線上資源狀態(tài)始終與參數(shù)設(shè)定的結(jié)果一致。如果應(yīng)用有創(chuàng)建的順序有依賴，則無法滿

33、足。三、對(duì)于熟悉各種自動(dòng)化工具的運(yùn)維開發(fā)，會(huì)使用自動(dòng)化配置管理工具來完成工作，如 Ansible。利用Ansible 的 k8s 模塊，創(chuàng)建各種資源，而且可以充分發(fā)揮 Ansible 強(qiáng)大的控制功能。不足之處：需要額外部署 Ansible，及對(duì) ansible 訪問集群的訪問認(rèn)證。需要額外管理 ansible 的 playbook 文件。無法保證線上資源狀態(tài)始終與參數(shù)設(shè)定的結(jié)果一致。參數(shù)更新時(shí)，需要手動(dòng)執(zhí)行 ansible playbook 腳本參數(shù)更新時(shí)，需要手動(dòng)執(zhí)行 helm 腳本為什么說 Operator 能夠更好地解決這類方法不足問題呢？因?yàn)樗粌H能夠很好地滿足自 定義打包的需求，同時(shí)

34、也彌補(bǔ)了以上三種方式的不足。使用 Operator-sdk 能夠非常方便地創(chuàng) 建自定義的 Operator，它支持三種類型：go、ansible、helm。go 類型，它的實(shí)現(xiàn)更加靈活，可以隨心所欲，擴(kuò)展性也最強(qiáng)，構(gòu)建出的 operator 鏡像也不大，但是它對(duì)于編程能力要求高，同時(shí)沒有 ansible 和 helm 類型拿來即用，可讀性也不及 ansible 與 helm 類型。ansible 類型，它使用 ansible 的 playbook 方式來定義應(yīng)用的構(gòu)建與保證應(yīng)用的狀態(tài)，它的實(shí)現(xiàn)也很靈活，依賴于 ansible 的模塊，但是這使得構(gòu)建出的 operator 鏡像較大，一般為 60

35、0 多 M，因?yàn)樗薬nsible 應(yīng)用及默認(rèn)的各個(gè)模塊。helm 類型，它使用 helm 的 charts 方式來定義應(yīng)用的構(gòu)建與保證應(yīng)用的狀態(tài)，它的鏡像一般為 200 多M，但是它的靈活度不及另外兩種類型。當(dāng)然從上圖可以看到，不同類型的實(shí)現(xiàn)，對(duì)應(yīng)用的管理深度會(huì)有所不一樣。那么從日常自有應(yīng)用的開發(fā)管理來說，Ansible 是一個(gè)不錯(cuò)的選擇， 同時(shí)對(duì)于開發(fā)運(yùn)維團(tuán)隊(duì)的技術(shù)要求也不會(huì)有新增的壓力。2.2 API Server 聚合API 聚合機(jī)制是 Kubernetes 1.7 版本引入的特性，能夠?qū)⒂脩魯U(kuò)展的 API 注冊(cè)到 kube-apiserver（即Kubernetes 核心 API

36、 Server）上，仍然通過 API Server 的 HTTP URL 對(duì)新的 API 進(jìn)行訪問和操作。API 聚合機(jī)制的目標(biāo)是提供集中的 API 發(fā)現(xiàn)機(jī)制和安全的代理功能，將開發(fā)人員的新 API 動(dòng)態(tài)地、無縫地注冊(cè)到 Kubernetes API Server 中進(jìn)行測(cè)試和使用。為了實(shí)現(xiàn)這個(gè)機(jī)制，Kubernetes 在 kube-apiserver 服務(wù)中引入了一個(gè) API 聚合層（API Aggregation Layer），用于將擴(kuò)展 API 的訪問請(qǐng)求轉(zhuǎn)發(fā)到用戶服務(wù)的功能。2.2.1 聚合層API 聚合層（API Aggregation Layer）在 kube-apiserver

37、 進(jìn)程內(nèi)運(yùn)行。在擴(kuò)展 API 注冊(cè)之前，聚合層不做任何事情。要注冊(cè) API，用戶必須添加一個(gè) APIService 資源對(duì)象，用它來申領(lǐng) Kubernetes API 中 的URL 路徑。自此以后，聚合層將會(huì)把發(fā)給該 API 路徑的所有內(nèi)容（例如 /apis/myextension.mycompany.io/v1/）代理到已注冊(cè)的 APIService。正常情況下，APIService 會(huì)實(shí)現(xiàn)為運(yùn)行于集群中某 Pod 內(nèi)的擴(kuò)展 API Server。如果需要對(duì)增加的資源進(jìn)行動(dòng)態(tài)管理，擴(kuò)展 API Server 經(jīng)常需要和一個(gè)或多個(gè)控制器一起使用。聚合層支持多個(gè)自定義 API Server 對(duì)

38、Kubernetes 的 API 進(jìn)行橫向擴(kuò)展。擴(kuò)展 API Server 與 kube-apiserver 之間的連接應(yīng)具有低延遲。發(fā)現(xiàn)請(qǐng)求應(yīng)當(dāng)在五秒鐘或更短的時(shí)間內(nèi)從kube-apiserver 往返?？梢栽?kube-apiserver 上設(shè)置 EnableAggregatedDiscoveryTimeout=false 功能開關(guān)將禁用超時(shí)限制，但此開關(guān)將在將來的版本中被刪除。API 聚合功能需要通過配置 kube-apiserver 服務(wù)的以下啟動(dòng)參數(shù)進(jìn)行啟用：-requestheader-client-ca-file=/etc/kubernetes/ssl_keys/ca.crt：客

39、戶端 CA 證書。-requestheader-allowed-names=：允許訪問的客戶端 common names 列表，通過 header 中-requestheader-username-headers 參數(shù)指定的字段獲取?？蛻舳?common names 的名稱需要在 clientca-file 中進(jìn)行設(shè)置，將其設(shè)置為空值時(shí)，表示任意客戶端都可訪問。-requestheader-extra-headers-prefix=X-Remote-Extra-：請(qǐng)求頭中需要檢查的前綴名。-requestheader-group-headers=X-Remote-Group：請(qǐng)求頭中需要檢查的

40、組名。-requestheader-username-headers=X-Remote-User：請(qǐng)求頭中需要檢查的用戶名。-proxy-client-cert-file=/etc/kubernetes/ssl_keys/kubelet_client.crt：在請(qǐng)求期間驗(yàn)證 Aggregator 的客戶端 CA 證書。-proxy-client-key-file=/etc/kubernetes/ssl_keys/kubelet_client.key：在請(qǐng)求期間 驗(yàn)證 Aggregator 的客戶端私鑰。如果 kube-apiserver 所在的主機(jī)上沒有運(yùn)行 kube-proxy，即無法通過服

41、務(wù)的 ClusterIP 進(jìn)行訪問，那么還需要設(shè)置-enable-aggregator-routing=true 。2.2.2 擴(kuò)展 API ServerAPI 聚合層提供了擴(kuò)展 API Server 的動(dòng)態(tài)注冊(cè)、發(fā)現(xiàn)匯總、和安全代理，但是擴(kuò)展 API Server 本身需要自行開發(fā)，并且需要遵循 Kubernetes 的開發(fā)規(guī)范。擴(kuò)展 API Server 是以 Kubernetes 中的 Pod 的形式存在的，通常需要與一個(gè)或多個(gè)控制器一起使用。官方提供了擴(kuò)展 API Server 開發(fā)樣例 sample-apiserver（/kubernetes/sample-apiserver），可以

42、此為模板進(jìn)行開發(fā)，但開發(fā)和部署步驟 是非常繁瑣的。好在可以使用第三方提供的開發(fā)框架如 apiserver-builder（/kubernetes-incubator/apiserver-builder/blob/master/README.md） 和 service-catalog（/kubernetes-incubator/service-catalog/blob/-master/README.md），它們都同時(shí) 提供了用于管理新資源的 API 框架和控制器框架，提供了一定的自動(dòng)化支持。如使用 apiserver-builder 開發(fā)擴(kuò)展 API Server 的關(guān)鍵步驟如下：# 創(chuàng)建項(xiàng)目目

43、錄mkdir $GOPATH/src/example/demo-apiserver# 在項(xiàng)目目錄下新建一個(gè)名為 boilerplate.go.txt，里面是代碼的頭部版權(quán)聲明cd $GOPATH/src/example/demo-apiserver curl -oboilerplate.go.txt/kubernetes/kubernetes/blob/master/hack/boilerplate/boilerplat e.go.txt# 初始化項(xiàng)目apiserver-boot init repo -domain # 創(chuàng)建一個(gè)非命名空間范圍的 api-resourceapiserver-bo

44、ot create group version resource -group demo -version v1beta1 - non-namespaced=true-kind Foo# 創(chuàng)建 Foo 這個(gè) api-resource 的子資源apiserver-boot create subresource -subresource bar -group demo -version v1beta1 -kind Foo# 生成上述創(chuàng)建的 api-resource 類型的相關(guān)代碼，包括 deepcopy 接口實(shí)現(xiàn)代碼、 versioned/unversioned 類型轉(zhuǎn)換代碼、api-resour

45、ce 類型注冊(cè)代碼、api-resource 類型的 Controller 代 碼、api-resource 類型的 AdmissionController 代碼apiserver-boot build generated# 直接在本地將 etcd，apiserver，controller 運(yùn)行起來apiserver-boot run local2.2.3 APIService 注冊(cè)擴(kuò)展 API Server 是作為 APIService 注冊(cè)到 Kubernetes 的核心 API Server 上的，啟用 API Server 的聚合功能后就可以通過 APIService 資源對(duì)象注冊(cè) API 了。APIService 資源清單文件如下：apiVersion: apiregistration.k8s.io/v1beta1 kind:APIServicemetadata:name: v1beta1.customapi.k8s.io spec:service:name: customapi namespace:customgroup: customapi.k8s.io v