2019年6月20日，Kubernetes重磅發佈了1.15版本，不管你是Kubernetes用戶，還是IT從業者都不能錯過這個版本。
1.15版本主要圍繞可擴展性展開，北向API接口方面API Machinery SIG致力於催熟CRD以提升API可擴展性，南向插件集成方面，Storage SIG 和Node SIG則分別對CSI和設備監控插件可擴展性進行了優化。另外Kubeadm對HA集羣配置也達到Beta可用，併發優化了證書管理相關功能。
本文我們先從宏觀上了解一下近期版本的變化趨勢，然後再開始1.15版本的重點特性解讀。
Kubernetes持續熱情高漲
在展開解讀1.15的關鍵新特性之前，讓我們先來回顧下社區過去幾個版本的特性發布情況。值得一提的是：無論從新特性數量，還是特性的成熟度分佈來看，Kubernetes依舊保持着相當的活力，社區開發者用實際行動迴應了業界盛傳“Kubernetes已經足夠成熟，項目正在變得無聊(Boring)”的說法。
各版本新特性數量基本持平
從新特性數量上看，Kubernetes過去一個版本發佈的特性數量並無明顯趨勢性變化。由於特性顆粒度的差異，每個版本發佈的新特性數量存在小幅波動，屬於正常現象。
看特性成熟度分佈，Alpha特性比例依舊可觀
對比分析過去幾個版本的特性成熟度，不難發現Alpha新特性的佔比穩定在20%~40%之間。按照社區慣例，當一項全新的功能被添加時，會在特性說明中打上Alpha標記。持續穩定甚至小幅上漲的Alpha特性佔比說明社區仍然在大量開發全新的特性，而不是滿足於既有功能的加固。
Kubernetes重點特性解讀
經過分析Kubernetes近幾個版本的變化，我們發現特性主要集中在Storage、Node、API-Machinery、Network、Scheduling等SIG，而這些SIG大都致力於可護展性增強，以便於下游用戶在享受穩定核心的同時，輕鬆擴展定製自己的插件。
從最新發布的1.15版本來看，以下幾個變化需要重點關注。
API聚焦可擴展性增強
Kubernetes API的擴展能力主要由CRD（Custom Resource Definition）以及Admission Webhook提供。1.15 版本在這兩方面都有重要的更新。
CRD，大步邁向GA
CRD的新開發主題一直都圍繞着數據一致性以及提供更加接近Kubernetes原生API的能力。用戶不應該感知到到底是以CR（Custom Resource）還是以原生的資源對象形式與Kube APIServer進行交互。社區目前正邁着大步，計劃將在接下來的某個版本中將CRD以及Admission Webhook GA（升級爲穩定版本）。
朝着這個方向，社區重新思考了基於OpenAPI的CRD驗證模式，從1.15開始，根據結構模式（Structural Schema）的限制檢查每個字段。這基本保證了能夠像原生的API對象一樣提供完整的CR校驗能力。在v1beta1 API中，非結構模式（non-Structural Schema）仍然保持工作狀態。但是任何嚴格的CRD應用程序都應該在可預見的將來遷移到結構模式。
- CRD多版本之間通過Webhook轉換特性[Beta]
從1.15版本開始，支持運行時不同版本之間的轉換，長期目標是讓用戶像原生API資源一樣使用CRD的多版本。這一特性是CRD在GA道路上一步重大的飛躍。
- CRD OpenAPI發佈特性[Beta]
CRD的OpenAPI發佈特性將會在Kubernetes 1.15中Beta，當然只是針對結構模式的CRD。次特性對於用戶自定義API，提供了與Kubernetes原生API一樣的文檔說明。
- CRD 未知字段裁剪（Prune）[Beta]
CRD未知字段裁剪特性是針對發送到Kube APIServer的對象中未知的字段進行移除，並且不會持久化存儲。用戶可以通過在CRD對象設置spec.preserveUnknownFields: false 使用此未知字段裁剪特性。此特性對於數據一致性及安全都有一定的幫助。
- CRD 默認值設置 [Alpha]
Kubernetes 1.15 結構模式的CRD默認值設置特性作爲Alpha特性可用。用戶可以通過OpenAPI校驗模式的default關鍵詞指定默認值。避免了用戶原來只能通過Admission Webhook方式設置CRD對象的默認值帶來的額外開發消耗。
Admission Webhook重新調用（Reinvocation）與增強
- Mutating 和 Validating Admission Webhook已經成爲擴展API的主流選擇。在1.15以前，所有的webhook只會按照字母表順序調用一次，這樣就會導致一個問題一個更早的webhook不能應對後面的webhook的更新，這可能會導致未知的問題，例如前面的webhook設置某個pod的啓動參數，而隨後的webhook將其更改或者移除了。
1.15 版本引入Reinvocation特性允許用戶通過MutatingWebhook 配置reinvocationPolicy: IfNeeded 指定Mutating Webhook重新調用。
-
Admission Webhook引入了objectSelector來控制通過標籤選擇特定的對象進行准入控制。
-
允許Admission Webhook Server使用任意的端口（不限制只能是443）。
Node SIG提供監控插件框架用於異構硬件監控
新版本很好的解決了異構硬件設備監控難題，現在不需要修改Kubelet代碼就可以實現各種指標（如GPU、顯存利用率等）監控。
新版本通過新的監控插件框架將Kubelet與設備監控處理邏輯解耦，很好的解決了以往Kubelet代碼管理和K8s集羣運維之間的痛點。
由圖可見本框架主要包含Kubelet和Device Monitoring Agent兩大部分：
1、 Kubelet
Kubelet增加了一個GRPC服務，監聽在/var/lib/kubelet/pod-resources/kubelet.sock，提供pod resources的list查詢接口。
2、 Device Monitoring Agent
a. Device Monitoring Agent提供metric接口對外提供設備監控指標查詢功能。
b. Device Monitoring Agent向Kubelet的上述GRPC服務發送List請求，取得所有pod resources(包含節點上所有pod的所有container分配的device類型和device id)。
c. Device Monitoring Agent根據設備類型過濾獲取容器的設備ID，通過設備驅動接口獲取容器使用的設備的監控指標，並把二者關聯到container 、pod上。
新的框架將會帶來諸多便利：
1、 設備監控功能與Kubelet接口解耦
a. Kubelet不需要提供設備的監控指標；
b. 設備的新增監控指標不需要升級Kubelet，而是更新設備監控代理版本即可；
c. 新增設備不需要升級Kubelet，而是增加部署設備監控代理的DaemonSet即可；
d. 未解耦前，Kubelet會檢測所有支持的設備是否存在，即使節點並沒有安裝該設備。
2、 設備供應商負責發佈和維護設備監控代理，設備供應商在如何運行和監控它們方面擁有深厚的專業知識，可以提供權威的設備監控代理。
3、 K8s集羣的管理員只需要安裝需要的設備監控代理即可。
Scheduling SIG發佈Scheduler Framework加強調度器擴展定製能力
Scheduler Framework 終於在1.15迎來了Alpha版本。Scheduler Framework 最早在2018 年初提出，主要是爲了解決日益增加的定製化調度需求。Scheduler Framework在原有的 Priority/Predicates 接口的基礎上增加了 reserve, pre-bind 等十幾個接口用於相應前處理及後處理。在 1.15 中，Scheduler Framework實現 QueueSort, Prebind, Postbind, Reserve, Unreserve和Permit接口，這些接口爲後繼更多的調度策略提供了基礎，比如 gang-scheduling。
然而，出於設計上的延續性考慮，目前 Scheduler Framework 仍以Pod爲單位進行調度，而計算類（離線）任務調度往往需要考慮工作負載中相關的Pod按組進行調度，例如 faire-share。現在的Scheduler Framework還不能有效的解決。所幸針對這一原因，社區已經有相應的項目在Kubernetes上支持計算類（離線）任務，例如 Volcano (http://github.com/volcano-sh/volcano)。
Storage SIG持續改善CSI
在Kubernetes v1.15中，SIG Storage繼續工作，以支持將in-tree插件遷移到CSI（Container Storage Interface，容器存儲接口）。SIG Storage致力於使CSI具有與in-tree功能相同的特性，包括調整大小、內聯卷等功能。SIG Storage在CSI中引入了一些新的Alpha功能，這些功能在Kubernetes存儲子系統中還不存在，如卷克隆（volume cloning）等。
卷克隆允許用戶在提供新卷時將另一個PVC指定爲“數據源（Data Source）”。如果底層存儲系統支持此功能並在其CSI驅動程序中實現“CLONE_VOLUME”功能，則新卷將成爲源卷的克隆。
Kubeadm的HA集羣配置達到Beta可用
作爲社區內置安裝工具的Kubeadm，何時支持部署HA集羣一直是個熱門話題。在本次發佈的1.15版本中，Kubeadm對HA集羣配置的支持終於達到beta——用戶可以直接使用init和join兩個Kubeadm命令來部署HA集羣。樂於折騰的用戶可以參考社區文檔在小範圍生產環境中使用。
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/
Kubeadm的證書管理功能在1.15中也得到了改進，用戶可以在證書失效前通過kubeadm alpha certs renew平滑地刷新它們。
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-certs-renew
Kubeadm的configuration(API)在1.15版本中引入了v1beta2版本，主要是增加了一組證書加解密密鑰的配置字段CertificateKey，便於用戶在使用Kubeadm部署HA控制面時，直接使用被加密保存在集羣Secret中的證書。此外，用戶可以通過 kubeadm alpha certs certificate-key 命令來直接生成這對密鑰。
關於跟多Kubeadm當前相關的Alpha特性，可以查看相關官方文檔：https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-alpha
隨着Kubernetes越來越多地被用在多雲、混合雲部署場景，集羣生命週期管理的標準化一直是衆人期待的一大方向。自v1.13版本GA之後，Kubeadm的改動主要聚焦在優化使用體驗上。而集羣生命週期整體流程的打通，特別是實現跨平臺的集羣管理，配合日漸活躍的ComponentConfig以及Cluster API兩個新項目，相信很快會有實質性的進展。
小結
經過5年的發展，Kubernetes核心的基本功能已相對穩定，具備大規模生產可用水平。但是客戶需求往往是多種多樣的，社區從很早就意識到這個問題，因而提供了各種接口（CRD、CRI、CSI、CNI等），希望在保持Kubernetes獨立的條件下，儘量滿足用戶差異化的需求，這從1.15發佈的主要特性也可以看出來。
華爲雲原生團隊堅定的認爲，Kubernetes社區未來會繼續着重圍繞可擴展性、易用性以及穩定性規劃發展路標，豐富平臺面向各種應用場景的功能接口，以穩定、健壯、高可擴展的平臺推動雲原生應用生態百花齊放。