2019 年 6 月 24 日至 26 日, 由 Cloud Native Computing Foundation (CNCF) 主辦的雲原生技術大會 KubeCon + CloudNativeCon + Open Source Summit（上海 ）即将在中國上海盛裝啟幕。在本次 KubeCon 上，阿裡雲将為全球使用者分享阿裡巴巴超大規模雲原生落地實踐、雲原生前沿技術與應用包括OpenKruise 開源項目、開放雲原生應用中心（Cloud Native App Hub），同時将重磅釋出邊緣容器、雲原生應用管理與傳遞體系等産品和服務。
“雲原生應用自動化引擎”加持下的阿裡“雲原生”
随着雲原生概念的興起，越來越多的應用開始嘗試在雲原生的土壤上耕耘。那麼什麼是雲原生，簡而言之，雲原生就是一套能夠充分利用“雲”的能力，高效建構與傳遞應用的方法論集合，使得應用容器化的使用者可以充分的利用雲的彈性、“不可變基礎設施”等優勢專注于自身核心業務價值。
目前，阿裡巴巴基礎設施的雲原生演進與更新也正在如火如荼的進行。而在阿裡巴巴上雲的過程中，阿裡内部在超大規模的網際網路場景中，已經開始進行大量的雲原生的理念落地實踐，比如輕量級容器化，阿裡巴巴經濟體正在大規模推進應用的輕量級容器化，進而達成利用容器的靈活、一緻等特性快速建構符合雲原生理念的電商站點傳遞的能力，适應類似“雙十一”大促的嚴苛技術需求；再比如說雲原生應用管理, 阿裡巴巴經濟體正在将 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：