歡迎光臨
每天分享高質量文章

Kubernetes 年度關鍵進展回顧

2017年已經接近尾聲,Kubernetes保持者每季度一個大版本的節奏快速發展,1.6至1.9版本共計完成了近150項特新更新,在集群規模、調度能力、可擴展性、安全性等方面都有明顯提升。以下,筆者將帶你回顧社區的幾項關鍵技術進展。


回顧

集群規模: 3000節點 -> 5000節點

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

網絡方面,得益於kube-proxy IPVS mode[1]的引入,Kubernetes對Service的管理規模從原來的千級別提升到了萬級別,大幅提升了Kubernetes在大規模場景下對Service的操作響應速度。

調度能力大增強

親和/反親和性調度特性的整體成熟度孵化到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的部署一直是個飽受詬病的話題,業界充斥了各種各樣的集群部署專案,功能實現大不相同,多數人甚至不知道該選擇哪一個。Kubeadm作為親兒子,很大程度上解決了Kubernetes組件安裝的易用性問題。截止1.9版本,除了最基本的組件安裝配置之外,kubeadm還提供了自舉樣式,集群升級,安裝進度查詢控制,健康檢查,kubelet動態配置等高級功能。目前業界的部署方案中,kubeadm已經成為作為節點安裝工具的首選。

然而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的引入為擴展儲存提供了極大的便利。

專案結構方面,單倉庫的樣式很好地支持Kubenretes前期的快速發展,而隨著專案的發展,合理的代碼庫拆分更有利於有針對性地維護不同成熟度的代碼,優化他們的依賴關係、測試構建、發佈節奏等。在2017的幾個版本開發期間,社區完成了client-go,API,apimachinery等倉庫的拆分,federation也在1.9期間成為了獨立子專案,目前進行中的還有kubectl,相信在未來的一年裡,社區會持續優化其專案結構,打破煙囪,更好地適應專案發展需要。

相關鏈接:

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

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

本次培訓包含:Kubernetes核心概念;Kubernetes集群的安裝配置、運維管理、架構規劃;Kubernetes組件、監控、網絡;針對於Kubernetes API接口的二次開發;DevOps基本理念;Docker的企業級應用與運維等,點擊識別下方二維碼加微信好友瞭解具體培訓內容

點擊閱讀原文鏈接即可報名。
赞(0)

分享創造快樂