Kubernetes 年度關鍵進展回顧

叢集規模： 3000節點 -> 5000節點

在Kubernetes 1.6版本中，單叢集的規模終於達到5千節點15萬Pod的水平，而出於諸多因素的影響及考慮，社群沒有急於在數值上繼續突破。實際上5千節點的規模，已經可以滿足大部分的使用場景，畢竟這還只是純軟體最佳化下的效能，並沒有使用過多的最佳化手段。要知道在規模過大的叢集中，整體的狀態監控、升級等維護工作都會變得十分複雜，Kubernetes的規模上去了，周邊系統卻未必跟得上。而在現有能力的基礎上，最簡單地，使用者可以透過Kubernetes直接管理物理節點的方式來達到強悍的單叢集效能，或者使用多叢集聯邦將整個資料中心鋪滿Kubernetes。

排程能力大增強

親和/反親和性排程特性的整體成熟度孵化到Beta，節點親和性（nodeAffinity）是nodeselector的進階，支援用in，not in等運運算元來指定Pod排程到或者避開一類節點；而Pod間親和性（podAffinity）則是為了複雜應用的排程需求而引入的高階特性，透過labelselector過濾出標的Pod之後，再借助topologyKey對Node按label進行動態分組，從而決定Pod是否要和標的Pod部署在同一組Node中。值得強調的是，Affinity相關定義已被移到Podspec中，使用者終於不必在annotation嵌入JSON字串來定義親和性規則，而早期版本中的演演算法效能問題也在後續的最佳化中得到了良好的解決，並且Beta之後的API基本不會再有改動，大家可以放心使用。

同樣是孵化到Beta的排程特性，taints tolerations的定義也分別被移到了NodeSpec和PodSpec中，在此期間，toleration還引入了超時時間定義（tolerationSeconds），用於細粒度控制節點故障時Pod的遷移觸發時間。過去，當叢集中某一節點發生故障時，node controller會在全域性統一的超時時間後驅逐節點上所有的Pod；而在基於taints tolerations的驅逐樣式下，每個Pod都可以獨立設定超時時間，甚至可以指定節點故障後不遷移。

作為提高叢集資源利用率的殺手級特性，Pod優先順序與搶佔終於在1.8版本被引入實現，併在1.9版本中進行了初步的修補和改進，但目前仍是alpha，可以考慮在非生產環境開啟試用。在1.8之前，Kubernetes已經透過Pod QoS方式實現了節點及的“優先順序”——節點記憶體不足時，OS核心會根據kubelet預製的OOM引數殺掉低QoS的pod，從而保證重要的Pod可以持續執行。Pod優先順序與搶佔的實現則是將這種資源分配動態可調的能力擴大到了叢集級別——當叢集資源不足而存在高優先順序的pod需要排程時，排程器可以在整個叢集內找到合適的pod進行驅逐釋放資源，來保證高優先順序的pod可被排程執行。

儲存增強

自動化配置，最佳化使用體驗：StorageClass和動態儲存分配已經GA，內建的預設配置大大簡化了儲存捲的生命週期管理，大大減輕了叢集管理員的壓力，也讓應用開發者能有更多的精力關註自身應用的開發和維護。

原生供豐富的儲存型別，並支援透過外掛擴充套件自定義儲存：Kubenretes內建支援的儲存型別目前已經超過20種。此外使用者還可以基於flexVolume、CSI框架對接自有儲存。FlexVolume目前已經GA，是擴充套件Kubenretes儲存能力的首選方式。CSI則是1.9版本新引入的alpha版本，未來更深度的儲存框架能力將基於CSI實現，值得長期關註。

安全性增強

Kubernetes這一年中在安全性上的增強可謂是進展巨大：1.6版本引入的RBAC（基於角色的訪問控制）目前已經GA，並且支援動態角色許可權配置，大幅簡化了許可權管理。Secret等資源如今可以被加密，並且支援對接外部KMS系統來儲存加密金鑰。引入高階審計日誌功能，支援對特定資源及其子資源的過濾輸出。kubelet證書支援自動動態掃清，大大減少了節點維護的工作量。

叢集部署與生命週期管理

然而Kubernetes依賴的基礎設施建立、狀態管理、叢集升級進度管控等，仍然缺少統一權威的方案。Cluster API的提出正是為瞭解決這些問題：按照Kubernetes的風格定義宣告式的基礎設施API，給出環境無關的叢集狀態定義，針對環境相關的叢集狀態給出通用的表述機制。其好處顯而易見：1）使用者可以使用一致的yaml檔案定義並建立Kubernetes叢集，2）透過宣告式的API定義Kubernetes控制面及kubelet升級過程，3）使用宣告式的API操作節點OS映象升級，4）在不同叢集、雲平臺上獲得一致的維護體驗，5）Kubernetes在雲平臺之前接入、遷移、釋放變得更簡單。

打破煙囪，更好的可擴充套件性，更合理的專案結構

由於借鑒了Google在Borg和Omega設計實踐中的大量經驗，Kubernetes天生擁有十分易於擴充套件的松耦合架構。而實際上，對於早些版本的Kubernetes的要實現低成本的改造確並不輕鬆。比如第三方的雲平臺Cloud Provider整合，第三方儲存引擎對接，定製底層硬體裝置等等往往無法避免侵入式的修改。而在Kubernetes處於快速生長期，專案程式碼頻繁重構，下游的私有patch往往維護十分困難。

經過2017這一整年的發展，我們可以欣喜地看到社群在可擴充套件性上作出的諸多改進：針對自定義API，TPR的進階版本CRD擁有更強的功能，在此之上，使用者還可以透過API Aggregator來實現高度定製的API；CRI的持續完善能夠更好地支援可插拔的容器執行時；Device Plugin框架的引入降低了GPU、FPGA等特性實現的侵入性；FlexVolume的GA和CSI的引入為擴充套件儲存提供了極大的便利。

相關連結：

1. https://github.com/kubernetes/kubernetes/issues/44063

基於Kubernetes的容器雲平臺實踐培訓