OpenKruise - 雲原生應用自動化引擎正式開源

在本次 KubeCon 上，阿里雲將爲全球用戶分享阿里巴巴超大規模雲原生落地實踐、雲原生前沿技術與應用包括OpenKruise 開源項目、開放雲原生應用中心（Cloud Native App Hub），同時將重磅發佈邊緣容器、雲原生應用管理與交付體系等產品和服務。

OpenKruise Github 地址： https://github.com/openkruise/kruise

「雲原生應用自動化引擎」加持下的阿里「雲原生」

隨着雲原生概念的興起，愈來愈多的應用開始嘗試在雲原生的土壤上耕耘。那麼什麼是雲原生，簡而言之，雲原生就是一套可以充分利用「雲」的能力，高效構建與交付應用的方法論集合，使得應用容器化的用戶能夠充分的利用雲的彈性、「不可變基礎設施」等優點專一於自身核心業務價值。

當前，阿里巴巴基礎設施的雲原生演進與升級也正在如火如荼的進行。而在阿里巴巴上雲的過程當中，阿里內部在超大規模的互聯網場景中，已經開始進行大量的雲原生的理念落地實踐，好比輕量級容器化，阿里巴巴經濟體正在大規模推動應用的輕量級容器化，從而達成利用容器的敏捷、一致等特性快速構建符合雲原生理念的電商站點交付的能力，適應相似「雙十一」大促的嚴苛技術需求；再好比說雲原生應用管理, 阿里巴巴經濟體正在將 Kubernetes 等項目的應用編排與自動化能力，穿透到上層運維框架當中，驅動電商應用按照雲原生的技術理念進行編排、交付和運行。

在阿里巴巴經濟體的總體雲原生化過程中，阿里的技術團隊逐漸沉澱出了一套緊貼上游社區標準、適應互聯網規模化場景的技術理念與最佳實踐。這其中，最重要的無疑是如何對應用進行自動化的發佈、運行和管理。

OpenKruise：來自阿里經濟體雲原生化歷程的寶貴經驗與最佳實踐

在 KubeCon 上海，阿里雲容器平臺團隊正式宣佈了重量級項目 - OpenKruise（如下簡稱Kruise）的開源。

Kruise 是 cruise的諧音，'k' for Kubernetes. 字面意義巡航，豪華遊艇。寓意Kubernetes上應用的自動巡航，滿載阿里巴巴多年應用部署管理經驗。

Kruise 的目標是automate everything on Kubernetes ! Kruise 項目源自於阿里巴巴經濟體應用過去多年的大規模應用部署、發佈與管理的最佳實踐，源於容器平臺團隊對集團應用規模化運維，規模化建站的能力，源於阿里雲Kubernetes服務數千客戶的需求沉澱。Kruise 借力於雲原生社區，集成阿里巴巴雲原生實踐之精華，反哺社區，指引業界雲原生化最佳實踐，少走彎路。

Kruise 核心在於自動化，咱們將從不一樣維度解決 Kubernetes之上應用的自動化，包括，部署，升級，彈性擴縮容，Qos調節，健康檢查，遷移修復等等。這次Kruise開源的內容主要在應用部署，升級方面，即一套加強版controller組件用於應用的部署和級和運維。後續，Kruise會依次開源智能化的彈性擴縮容組件，以及應用Qos自調節能力的組件等。

Kruise Controllers：將 Kubernetes 的「控制器模式」進行到底

如下內容主要介紹 Kruise Controllers - 一套用於 Kubernetes 之上應用自動化部署管理的 controller 組件。衆所周知，Kubernetes 項目的核心原理，就是「控制器模式」。目前，Kubernetes 項目默認已經提供了一套 Controller 組件，例如 Deployment, Statefulset, DaemonSet 等，這些 Controller 提供了比較豐富的應用部署和管理功能。可是，隨着 Kubernetes 的使用範圍愈來愈廣，真實的企業與規模性場景中的業務訴求與上游 Controller 功能不匹配的狀況也愈來愈常見。以阿里巴巴爲例：阿里巴巴內部的 Kubernetes 集羣須要服務涵蓋50幾個 BU，上萬種應用。這個體量很是龐大，對規模性和高可用性帶來了巨大的挑戰。與此同時，阿里雲上的 Kubernetes 服務也接入了上千家企業客戶，收集並支撐了各類各樣的客戶需求。這些訴求與最後阿里經濟體的實踐經驗，最終促成了 Kruise 開源項目的誕生。

Kruise 第一期開源主要包含如下 Controller，後續會加入更多。

Advanced StatefulSet - 具有豐富發佈策略、支持原地升級的 StatefulSet

Advanced StatefulSet 擴展了原生的 StatefulSet，加入了兩個新的特性。

1）原地升級 （In-place update strategy）原生的 StatefulSet 在作 rolling update 的時候會銷燬而且重建 pods. 這在阿里巴巴規模體量的場景下，代價巨大。

a) 首先，全部被刪除的應用的Pods須要被從新調度一遍，因爲pod數量大，這對調度帶來了沒必要要的開銷，更糟的是，從新調度的pod沒法正常被調度，因爲資源被佔用，親和特性等其餘緣由。Pod被從新調度到新的node上，損失了原來的本地 state, 雖然一般能夠被重建，可是仍是帶來額外開銷。
b) 重調度後的 pods 頗有可能分佈在不一樣的機器上，因爲網絡拓撲結構的改變，須要從新申請IP, 有些依賴IP保持的應用沒法正常工做，此外，對網絡流量的傳輸帶來了不肯定性。
c) 針對多容器的 Pod, 升級 sidecar 容器而致使主容器重建，一般是不可接受的。

Advanced StatefulSet 引入了原地升級功能，容許在不銷燬pod的狀況下，更新容器 image。這樣帶來的好處是，效率和穩定性。效率很明顯，pod 不須要被從新調度了，仍是跑在原來的node,一些本地存儲state仍是能夠保留。穩定性體如今 IP 保持，網絡拓撲以及流量結構基本不變，穩定性在阿里巴巴及阿里雲經濟體中一直以來是一個極其重要的指標。

2）容許最大不可用實例的配置(Max Unavailable)

社區原生的 StatefulSet 在升級的過程當中是不容許同時升級多個實例的，這主要是爲了某些有狀態應用須要依次按序升級的需求。可是，從阿里巴巴場景，以及阿里雲容器平臺之上的客戶瞭解到，許多應用不須要依次按序升級的語義，這樣帶來的問題是效率過低。特別是像阿里巴巴一些應用實例數巨大的場景，問題尤爲顯著。MaxUnavailable 的功能正式爲了解決這個問題，它容許應用實例被並行升級，且保持始終保持最大不可用的實例數不超過 MaxUnavailable 的限制數。

Broadcast Job - 像 DaemonSet 那樣運行的一次性 Job

Broadcast Job 會在集羣中每一個node上面跑一個pod直至結束。相似於社區的DaemonSet, 區別在於DaemonSet始終保持一個pod長服務在每一個node上跑，而BroadcastJob中最終這個pod會結束。相比DaemonSet，Broadcast結束後再也不佔用資源，這在某些場景中特別適用，好比升級node中某些組件，檢測node上一些配置是否正確等。

SidecarSet - 大規模場景下 Sidecar 管理利器

Sidecar 在Kubernetes中是一個輔助容器的概念，和主容器跑在同一個pod中。Sidecar容器通常是一些基礎服務組件如monitoring容器，log collection容器等。在一個公司中，主業務容器，和基礎組件容器一般由不一樣的團隊開發和維護，多個團隊同時操做和修改同一份yaml文件，同一個API資源對象，時常會產生一些衝突，且不便於管理。SidecarSet的理念在於將主業務容器和輔助容器的運維模式解耦。當業務用戶提交應用時，不須要顯示指定sidecar容器，由sidecar容器相應的團隊編寫規則負責自動注入。而且在容器運維和升級時候，利用Advanced Statefulset 原地升級的功能，業務團隊，和基礎架構團隊分別按照本身定義的策略升級各自相應的容器，而不須要耦合在一塊兒升級，產生沒必要要的影響。Istio 其實採用相似的思想自動給業務容器注入sidecar容器的功能，可是其缺少sidecar容器後續升級運維的能力。SidecarSet有效地把Sidecar容器的部署和管理抽象出來。

OpenKruise 正在面向開源社區招募合做夥伴與子項目！

Kruise 社區的準則，是基於Kubernetes 的核心技術理念來構建更強大的自動化能力。目前，Kruise 正在計劃發佈更多的Controller來覆蓋更多的場景和功能好比豐富的發佈策略，金絲雀發佈，藍綠髮布，分批發布等等。

更爲重要的是，OpenKruise 是一個 Umbrella 項目，OpenKruise 的維護者們，正以最開放的姿態面向全球招募合做夥伴和貢獻者。沒錯，咱們很是期待您可以爲 OpenKruise 貢獻和共建新的自動化能力，或者一塊兒來共同推 Kubernetes 雲原生應用編排能力的演進與發展。

更多信息，請移步 Kruise Github： https://github.com/openkruise/kruise

---

本文做者：地町

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。