阿里開源！雲原生應用自動化引擎 OpenKruise | 直擊 KubeCon

時間 2019-11-19

標籤阿里開源原生應用自動化引擎 openkruise kubecon 欄目阿里巴巴简体版

原文原文鏈接

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

接下來的三天，阿里妹將連線會場，爲你帶來實時報道。網絡

2019年6月24日至26日，由 CNCF 主辦的雲原生技術大會 KubeCon 在中國上海盛裝啓幕，阿里雲容器平臺團隊正式宣佈開源重量級項目 OpenKruise，將基於阿里巴巴經濟體多年大規模應用部署、發佈與管理最佳實踐沉澱的能力開放給業界。架構

OpenKruise 是阿里巴巴開源的 Kubernetes 之上雲原生應用自動化的引擎。Kruise 項目源自於阿里巴巴經濟體應用過去多年的大規模應用部署、發佈與管理的最佳實踐，源於阿里雲Kubernetes服務數千客戶的需求沉澱。框架

「雲原生應用自動化引擎」加持下的阿里經濟體「全面上雲」

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

當前，阿里巴巴基礎設施的雲原生演進與升級也正在如火如荼的進行。而在這個阿里巴巴經濟體總體雲化的過程當中，阿里內部在超大規模的互聯網場景中，已經開始進行大量的雲原生的理念落地實踐，好比輕量級容器化。ide

阿里巴巴經濟體正在大規模推動應用的輕量級容器化，從而達成利用容器的敏捷和一致等特性快速構建符合雲原生理念的電商站點交付的能力，適應相似「雙十一」大促的嚴苛技術需求。再好比說雲原生應用管理，阿里巴巴經濟體正在將 Kubernetes 等項目的應用編排與自動化能力，穿透到上層運維框架當中，驅動電商應用按照雲原生的技術理念進行編排、交付、運行。ui

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

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

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

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

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

OpenKruise 是阿里巴巴開源的 Kubernetes 之上雲原生應用自動化的引擎。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，加入了兩個新的特性。

原地升級（In-place update strategy）

原生的 StatefulSet 在作 rolling update 的時候會銷燬而且重建 pods. 這在阿里巴巴規模體量的場景下，代價巨大。

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

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

容許最大不可用實例的配置(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 容器的部署和管理抽象出來。