超大規模商用 K8s 場景下，阿里巴巴如何動態解決容器資源的按需分配問題？

做者 | 張曉宇（衷源） 阿里雲容器平臺技術專家

關注『阿里巴巴雲原生』公衆號，回覆關鍵詞「1010」，可獲取本文 PPT。

導讀：資源利用率一直是不少平臺管理和研發人員關心的話題。本文做者經過阿里巴巴容器平臺團隊在這一領域的工做實踐，整理出了一套資源利用提高的方案，但願可以帶給你們帶來一些討論和思考。

引言

不知道你們有沒有過這樣的經歷：當咱們擁有了一套 Kubernetes 集羣，而後開始部署應用的時候，咱們應該給容器分配多少資源呢？

這很難說。因爲 Kubernetes 本身的機制，咱們能夠理解容器的資源實質上是一個靜態的配置。

若是我發現資源不足，爲了分配給容器更多資源，咱們須要重建 Pod；

若是分配冗餘的資源，那麼咱們的 worker node 節點彷佛又部署不了多少容器。

試問，咱們能作到容器資源的按需分配嗎？接下來，咱們將在本次分享中和你們一塊兒進行探討這個問題的答案。

生產環境中的真實挑戰

首先請容許咱們根據咱們的實際狀況拋出咱們實際生產環境的挑戰。或許你們還記得 2018 年的天貓雙 11，這一天的總成交額達到了 2135 億。由此一斑可窺全豹，可以支撐如此龐大規模的交易量背後的系統，其應用種類和數量應該是怎樣的一種規模。

在這種規模下，咱們經常聽到的容器調度，如：容器編排，負載均衡，集羣擴縮容，集羣升級，應用發佈，應用灰度等等這些詞，在被「超大規模集羣」這個詞修飾後，都再也不是件容易處理的事情。規模自己也就是咱們最大的挑戰。如何運營和管理好這麼一個龐大的系統，並遵循業界 dev-ops 宣傳的那樣效果，猶如讓大象去跳舞。可是馬老師曾說過，大象就該幹大象該乾的事情，爲何要去跳舞呢。

Kubernetes 的幫助

大象是否能夠跳舞，帶着這個問題，咱們須要從淘寶、天貓等 APP 背後系統提及。

這套互聯網系統應用部署大體可分爲三個階段，傳統部署，虛擬機部署和容器部署。相比於傳統部署，虛擬機部署有了更好的隔離性和安全性，可是在性能上不可避免的產生了大量損耗。而容器部署又在虛擬機部署實現隔離和安全的背景下，提出了更輕量化的解決方案。咱們的系統也是沿着這麼一條主航道上運行的。假設底層系統比如一艘巨輪，面對巨量的集裝箱---容器，咱們須要一個優秀的船長，對它們進行調度編排，讓系統這艘大船能夠避開層層險阻，操做難度下降，且具有更多靈活性，最終達成航行的目的。

理想與現實

在開始之初，想到容器化和 Kubernetes 的各類美好場景，咱們理想中的容器編排效果應該是這樣的：

從容：咱們的工程師更加從容的面對複雜的挑戰，再也不眉頭緊鎖而是更多笑容和自信；

優雅：每一次線上變動操做均可以像品着紅酒同樣氣定神閒，優雅地按下執行的回車鍵；

有序：從開發到測試，再到灰度發佈，一鼓作氣，行雲流水；

穩定：系統健壯性良好，任爾東西南北風，咱們系統巋然不動。整年系統可用性 N 多個 9；

高效：節約出更多人力，實現「快樂工做，認真生活」。

然而理想很豐滿，現實很骨感。迎接咱們的倒是雜亂和形態萬千的窘迫。

雜亂，是由於做爲一個異軍突起的新型技術棧，不少配套工具和工做流的建設處於初級階段。Demo 版本中運行良好的工具，在真實場景下大規模鋪開，各類隱藏的問題就會暴露無遺，層出不窮。從開發到運維，全部的工做人員都在各類被動地疲於奔命。另外，「大規模鋪開」還意味着，要直接面對形態萬千的生產環境：異構配置的機器、複雜的需求，甚至是適配用戶的既往的使用習慣等等。

除了讓人心力交瘁的混亂，系統還面臨着應用容器的各類崩潰問題：內存不足致使的 OOM，CPU quota 分配太少，致使進程被 throttle，還有帶寬不足，響應時延大幅上升...甚至是交易量在面對訪問高峯時候因爲系統不給力致使的斷崖式下跌等等。這些都使咱們在大規模商用 Kubernetes 場景中積累很是多的經驗。

直面問題

穩定性

問題總要進行面對的。正如某位高人說過：若是感受哪裏不太對，那麼確定有些地方出問題了。因而咱們就要剖析，問題究竟出在哪裏。針對於內存的 OOM，CPU 資源被 throttle，咱們能夠推斷咱們給與容器分配的初始資源不足。

資源不足就勢必形成整個應用服務穩定性降低。例如上圖的場景：雖然是同一種應用的副本，或許是因爲負載均衡不夠強大，或者是因爲應用自身的緣由，甚至是因爲機器自己是異構的，相同數值的資源，可能對於同一種應用的不一樣副本並具備相等的價值和意義。在數值上他們看似分配了相同的資源，然而在實際負載工做時，極有可能出現的現象是肥瘦不均的。

而在資源 overcommit 的場景下，應用在整個節點資源不足，或是在所在的 CPU share pool 資源不足時，也會出現嚴重的資源競爭關係。資源競爭是對應用穩定性最大的威脅之一。因此咱們要盡力在生產環境中清除全部的威脅。

咱們都知道穩定性是件很重要的事情，尤爲對於掌控上百萬容器生殺大權的一線研發人員。或許不經心的一個操做就有可能形成影響面巨大的生產事故。

所以，咱們也按照通常流程作了系統預防和兜底工做。

在預防維度，咱們能夠進行全鏈路的壓力測試，而且提早經過科學的手段預判應用須要的副本數和資源量。若是無法準確預算資源，那就只採用冗餘分配資源的方式了。

在兜底維度，咱們能夠在大規模訪問流量抵達後，對不緊要的業務作服務降級並同時對主要應用進行臨時擴容。

可是對於陡然增長几分鐘的突增流量，這麼多組合拳的花費不菲，彷佛有些不划算。或許咱們能夠提出一些解決方案，達到咱們的預期。

資源利用率

回顧一下咱們的應用部署狀況：節點上的容器通常分屬多種應用，這些應用自己不必定，也通常不會同時處於訪問的高峯。對於混合部署應用的宿主機，若是能都錯峯分配上面運行容器的資源或許更科學。

應用的資源需求可能就像月亮同樣有陰晴圓缺，有周期變化。例如在線業務，尤爲是交易業務，它們在資源使用上呈現必定的週期性，例如：在凌晨、上午時，它的使用量並非很高，而在午間、下午時會比較高。

打個比方：對於 A 應用的重要時刻，對於 B 應用可能不那麼重要，適當打壓 B 應用，騰挪出資源給 A 應用，這是個不錯的選擇。這聽起來有點像是分時複用的感受。可是若是咱們按照流量峯值時的需求配置資源就會產生大量的浪費。

除了對於實時性要求很高的在線應用外，咱們還有離線應用和實時計算應用等：離線計算對於 CPU 、Memory 或網絡資源的使用以及時間不那麼敏感，因此在任什麼時候間段它均可以運行；實時計算，可能對於時間敏感性就會很高。

早期，咱們業務是在不一樣的節點按照應用的類型獨立進行部署。從上面這張圖來看，若是它們進行分時複用資源，針對實時性這個需求層面，咱們會發現它實際的最大使用量不是 2+2+1=5，而是某一時刻重要緊急應用需求量的最大值，也就是 3 。若是咱們可以數據監測到每一個應用的真實使用量，給它分配合理值，那麼就能產生資源利用率提高的實際效果。

對於電商應用，對於採用了重量級 Java 框架和相關技術棧的 Web 應用，短期內 HPA 或者 VPA 都不是件容易的事情。

先說 HPA，咱們或許能夠秒級拉起了 Pod，建立新的容器，然而拉起的容器是否真的可用呢。從建立到可用，可能須要比較久的時間，對於大促和搶購秒殺-這種訪問量「洪峯」可能僅維持幾分鐘或者十幾分鐘的實際場景，若是咱們等到 HPA 的副本所有可用，可能市場活動早已經結束了。

至於社區目前的 VPA 場景，刪掉舊 Pod，建立新 Pod，這樣的邏輯更難接受。因此綜合考慮，咱們須要一個更實際的解決方案彌補 HPA 和 VPA 的在這一單機資源調度的空缺。

解決方案

交付標準

咱們首先要對解決方案設定一個能夠交付的標準那就是—— 「既要穩定性，也要利用率，還要自動化實施，固然若是可以智能化那就更好」，而後再交付標準進行細化：

安全穩定：工具自己高可用。所用的算法和實施手段必須作到可控；

業務容器按需分配資源：能夠及時根據業務實時資源消耗對不過久遠的未來進行資源消耗預測，讓用戶明白業務接下來對於資源的真實需求；

工具自己資源開銷小：工具自己資源的消耗要儘量小，不要成爲運維的負擔；

操做方便，擴展性強：能作到無需接受培訓便可玩轉這個工具，固然工具還要具備良好擴展性，供用戶 DIY；

快速發現 & 及時響應：實時性，也就是最重要的特質，這也是和HPA或者VPA在解決資源調度問題方式不一樣的地方。

設計與實現

上圖是咱們最初的工具流程設計：當一個應用面臨很高的業務訪問需求時，體如今 CPU、Memory 或其餘資源類型需求量變大，咱們根據 Data Collector 採集的實時基礎數據，利用 Data Aggregator 生成某個容器或整個應用的畫像，再將畫像反饋給 Policy engine。 Policy engine 會瞬時快速修改容器 Cgroup 文件目錄下的的參數。

咱們最先的架構和咱們的想法同樣樸實，在 kubelet 進行了侵入式的修改。雖然咱們只是加了幾個接口，可是這種方式確實不夠優雅。每次 kubenrnetes 升級，對於 Policy engine 相關組件升級也有必定的挑戰。

爲了作到快速迭代並和 Kubelet 解耦，咱們對於實現方式進行了新的演進。那就是將關鍵應用容器化。這樣能夠達到如下功效：

不侵入修改 K8s 核心組件；

方便迭代&發佈；

藉助於 Kubernetes 相關的 QoS Class 機制，容器的資源配置，資源開銷可控。

固然在後續演進中，咱們也在嘗試和 HPA，VPA 進行打通，畢竟這些和 Policy engine 存在着互補的關係。所以咱們架構進一步演進成以下情形。當 Policy engine 在處理一些更多複雜場景搞到無力時，上報事件讓中心端作出更全局的決策。水平擴容或是垂直增長資源。

下面咱們具體討論一下 Policy engine 的設計。Policy engine 是單機節點上進行智能調度並執行 Pod 資源調整的核心組件。它主要包括 api server，指揮中心 command center 和執行層 executor。

其中 api server 用於服務外界對於 policy engine 運行狀態的查詢和設置的請求；

command center 根據實時的容器畫像和物理機自己的負載以及資源使用狀況，做出 Pod 資源調整的決策；

Executor 再根據 command center 的決策，對容器的資源限制進行調整。同時，executor 也把每次調整的 revision info 持久化，以便發生故障時能夠回滾。

指揮中心按期從 data aggregator 獲取容器的實時畫像，包括聚合的統計數據和預測數據，首先判斷節點狀態，例如節點磁盤異常，或者網絡不通，表示該節點已經發生異常，須要保護現場，再也不對Pod進行資源調整，以避免形成系統震盪，影響運維和調試。若是節點狀態正常，指揮中心會策略規則，對容器數據進行再次過濾。好比容器 CPU 率飆高，或者容器的響應時間超過安全閾值。若是條件知足，則對知足條件的容器集合給出資源調整建議，傳遞給executor。

在架構設計上，咱們遵循瞭如下原則：

插件化：全部的規則和策略被設計爲能夠經過配置文件來修改，儘可能與核心控制流程的代碼解耦，與 data collector 和 data aggregator 等其餘組件的更新和發佈解耦，提高可擴展性；

穩定，這包括如下幾個方面：

控制器穩定性。指揮中心的決策以不影響單機乃至全局穩定性爲前提，包括容器的性能穩定和資源分配穩定。例如，目前每一個控制器僅負責一種 cgroup 資源的控制，即在同一時間窗口內，Policy engine 不一樣時調整多種資源，以避免形成資源分配震盪，干擾調整效果；

觸發規則穩定性。例如，某一條規則的原始觸發條件爲容器的性能指標超出安全閾值，可是爲避免控制動做被某一突發峯值觸發而致使震盪，咱們把觸發規則定製爲：過去一段時間窗口內性能指標的低百分位超出安全閾值；若是規則知足，說明這段時間內絕大部分的性能指標值都已經超出了安全閾值，就須要觸發控制動做了；

另外，與社區版 Vertical-Pod-Autoscaler 不一樣，Policy engine 不主動驅逐騰挪容器，而是直接修改容器的 cgroup 文件；

自愈：資源調整等動做的執行可能會產生一些異常，咱們在每一個控制器內都加入了自愈回滾機制，保證整個系統的穩定性；

不依賴應用先驗知識：爲全部不一樣的應用分別進行壓測、定製策略，或者提早對可能排部在一塊兒的應用進行壓測，會致使巨大開銷，可擴展性下降。咱們的策略在設計上儘量通用，儘可能採用不依賴於具體平臺、操做系統、應用的指標和控制策略。

在資源調整方面，Cgroup 支持咱們對各個容器的 CPU、內存、網絡和磁盤 IO 帶寬資源進行隔離和限制，目前咱們主要對容器的 CPU 資源進行調整，同時在測試中探索在時分複用的場景下動態調整 memory limit 和 swap usage 而避免 OOM 的可行性；在將來咱們將支持對容器的網絡和磁盤 IO 的動態調整。

調整效果

上圖展現了咱們在測試集羣獲得的一些實驗結果。咱們把高優先級的在線應用和低優先級的離線應用混合部署在測試集羣裏。SLO 是 250ms，咱們但願在線應用的 latency 的 95 百分位值低於閾值 250ms。

在實驗結果中能夠看到：

在大約90s前，在線應用的負載很低；latency 的均值和百分位都在 250ms 如下；

到了 90s後，咱們給在線應用加壓，流量增長，負載也升高，致使在線應用 latency 的 95 百分位值超過了 SLO；

在大約 150s 左右，咱們的小步快跑控制策略被觸發，漸進式地 throttle 與在線應用發生資源競爭的離線應用；

到了大約 200s 左右，在線應用的性能恢復正常，latency 的 95 百分位回落到 SLO 如下。

這說明了咱們的控制策略的有效性。

經驗和教訓

下面咱們總結一下在整個項目的進行過程當中，咱們收穫的一些經驗和教訓，但願這些經驗教訓可以對遇到相似問題和場景的人有所幫助。

避開硬編碼，組件微服務化，不只便於快速演進和迭代，還有利於熔斷異常服務。

儘量不要調用類庫中仍是 alpha 或者 beta 特性的接口。 例如咱們曾經直接調用 CRI 接口讀取容器的一些信息，或者作一些更新操做，可是隨着接口字段或者方法的修改，共建有些功能就會變得不可用，或許有時候，調用不穩定的接口還不如直接獲取某個應用的打印信息可能更靠譜。

基於 QoS 的資源動態調整方面：如咱們以前所講，阿里集團內部有上萬個應用，應用之間的調用鏈至關複雜。應用 A 的容器性能發生異常，不必定都是在單機節點上的資源不足或者資源競爭致使，而頗有多是它下游的應用 B、應用 C，或者數據庫、cache 的訪問延遲致使的。因爲單機節點上這種信息的侷限性，基於單機節點信息的資源調整，只能採用「盡力而爲」，也就是 best effort 的策略了。在將來，咱們計劃打通單機節點和中心端的資源調控鏈路，由中心端綜合單機節點上報的性能信息和資源調整請求，統一進行資源的從新分配，或者容器的從新編排，或者觸發 HPA，從而造成一個集羣級別的閉環的智能資源調控鏈路，這將會大大提升整個集羣維度的穩定性和綜合資源利用率。

資源v.s.性能模型：可能有人已經注意到，咱們的調整策略裏，並無明顯地提出爲容器創建「資源v.s.性能」的模型。這種模型在學術論文裏很是常見，通常是對被測的幾種應用進行了離線壓測或者在線壓測，改變應用的資源分配，測量應用的性能指標，獲得性能隨資源變化的曲線，最終用在實時的資源調控算法中。在應用數量比較少，調用鏈比較簡單，集羣裏的物理機硬件配置也比較少的狀況下，這種基於壓測的方法能夠窮舉到全部可能的狀況，找到最優或者次優的資源調整方案，從而獲得比較好的性能。可是在阿里集團的場景下，咱們有上萬個應用，不少重點應用的版本發佈也很是頻繁，每每新版本發佈後，舊的壓測數據，或者說資源性能模型，就不適用了。另外，咱們的集羣不少是異構集羣，在某一種物理機上測試獲得的性能數據，在另外一臺不一樣型號的物理機上就不會復現。這些都對咱們直接應用學術論文裏的資源調控算法帶來了障礙。因此，針對阿里集團內部的場景，咱們採用了這樣的策略：不對應用進行離線壓測，獲取顯示的資源性能模型。而是創建實時的動態容器畫像，用過去一段時間窗口內容器資源使用狀況的統計數據做爲對將來一小段時間內的預測，而且動態更新；最後基於這個動態的容器畫像，執行小步快跑的資源調整策略，邊走邊看，盡力而爲。

總結與展望

總結起來，咱們的工做主要實現瞭如下幾方面的收益：

經過分時複用以及將不一樣優先級的容器（也就是在線和離線任務）混合部署，而且經過對容器資源限制的動態調整，保證了在線應用在不一樣負載狀況下都能獲得足夠的資源，從而提升集羣的綜合資源利用率。

經過對單機節點上的容器資源的智能動態調整，下降了應用之間的性能干擾，保障高優先級應用的性能穩定性

各類資源調整策略經過 Daemonset 部署，能夠自動地、智能地在節點上運行，減小人工干預，下降了運維的人力成本。

展望將來，咱們但願在如下幾個方面增強和擴展咱們的工做：

閉環控制鏈路：前面已經提到，單機節點上因爲缺少全局信息，對於資源的調整有其侷限性，只能盡力而爲。將來，咱們但願可以打通與 HPA 和 VPA 的通路，使單機節點和中心端聯動進行資源調整，最大化彈性伸縮的收益。

容器從新編排：即便是同一個應用，不一樣容器的負載和所處的物理環境也是動態變化的，單機上調整 pod 的資源，不必定可以知足動態的需求。咱們但願單機上實時容器畫像，可以爲中心端提供更多的有效信息，幫助中心端的調度器做出更加智能的容器重編排決策。

策略智能化：咱們如今的資源調整策略仍然比較粗粒度，能夠調整的資源也比較有限；後續咱們但願讓資源調整策略更加智能化，而且考慮到更多的資源，好比對磁盤和網絡IO帶寬的調整，提升資源調整的有效性。

容器畫像精細化：目前的容器畫像也比較粗糙，僅僅依靠統計數據和線性預測；刻畫容器性能的指標種類也比較侷限。咱們但願找到更加精確的、通用的、反映容器性能的指標，以便更加精細地刻畫容器當前的狀態和對不一樣資源的需求程度。

查找干擾源：咱們但願能找到在單機節點上找到行之有效的方案，來精準定位應用性能受損時的干擾源；這對策略智能化也有很大意義。

Q & A

Q1：直接修改 cgroup 容器必定會得到資源嗎？

A1：容器技術隔離的技術基礎就是 cgroup 層面。在宿主機騰出足夠資源的狀況下，給 cgroup 設置更大的值能夠獲取更多的資源。同理，對於通常優先級不高的應用，設置較低的 cgroup 資源值就會達到抑制容器運行的效果。

Q2：底層是如何區分在線和離線優先級的？

A2：底層是沒法自動獲取誰是在線，誰是離線，或者誰的優先級高，誰的優先級低的。這個咱們能夠經過各類 Kubernetes 提供的擴展實現。最簡單的是經過 label，Annotation 標識。固然經過擴展 QoS class 也是一種思路。社區版本的 QoS class設置太過於保守，給予用戶發揮的空間不大。咱們經過這些方面也進行了加強。在合適的時候或許會推向社區。自動感知是個方向，感知誰是干擾源，感知誰是某種資源型應用，這塊咱們還在研發中。作到真正的動態，確定是具有自動感知的智能系統。

Q3：「與社區版 Vertical-Pod-Autoscaler 不一樣，Policy engine 不主動驅逐騰挪容器，而是直接修改容器的 cgroup 文件」，想問一下，不主動驅逐的話，若是 Node 的資源達到上線了會怎麼處理？

A3：這是一個好問題。首先這裏要先區分是哪一種資源，若是是 CPU 型的，咱們能夠調整低優先級容器的 cgroup 下 cpu quota 的值，首先抑制低優先級的容器對於 CPU 的爭搶。而後再適當上調高優先級容器的相關資源值。若是是內存型資源，這個不能直接去縮小低優先級容器的 cgroup 值，不然會形成 OOM，對於學習內存型資源的調整，咱們會在其餘分享中繼續討論。這個技術比較特殊。

Q4：只修改 cgroup，怎麼保證 K8s 對單個物理機可以分配更多的容器？

A4：文字直播有了必定說明，容器的資源消耗並不是是一成不變的，不少時候它們的資源消耗呈現潮汐現象，相同的資源條件下部署更多應用，完成更多做業就是達到資源利用的最大化的效果。資源出現超賣纔是咱們這個主題討論的最大價值。

Q5：也就是說，低優先級的容器，request 設置的比 limit 小不少，而後大家再動態的調整 cgroup？

A5：在現有 QoS 場景下，你能夠理解被調整的 Pod 都是 burstable 的。可是咱們並非直接調整 Pod 元數據的 limit 的值，而是調整 limit 在 cgroup 反映的值，這個值在資源競爭緩和的時候還會被調整回去的。咱們並不建議單機的 cgroup 數據和 etcd 的中心數據割裂過久。若是長期偏離，咱們會像 VPA 發出警報，聯動 VPA 作調整。固然在容器運行的高峯期，任何重建容器的操做都是不明智的。

Q6：總體的理解就是大家開始就讓物理機超配了必定比例的 pod，而後經過策略動態調整容器的 cgroup 值？

A6：若是資源徹底是富足冗餘的，這個動態調整也有必定意義。就是並不是資源用滿場景下，高優先級應用會被幹擾，實際上，當主機的 CPU 達到必定比例，打個比方例如 50%，應用的時延就變大。爲了徹底確保高優先級應用的 SLO，犧牲低優先級的 CPU 正常運行也是有價值的。

Q7:Policy engine 有沒有考慮開源？

A7：有計劃進行開源，Policy engine 更多的是和自身的應用屬性相關，電商應用或者大數據處理應用的策略都是不相同的，咱們開源會首先開源框架和附帶一些簡單的策略，更多的策略能夠用戶自定義。

Q8：我以前遇到的大部分應用都沒法正確感知 cgroup 的配置，所以不少狀況都須要在啓動參數裏面根據 cpu 或者 mem 設置參數，那麼也就是說即便改變了 cgroup 對於他們來講都無效，那麼使用場景也就有限了

A8：限制容器的資源使用這個仍是有價值的。限制低優先級應用自己也能夠提高高優先級應用的 SLO，雖然效果沒有那麼明顯。穩定性的考量一樣也很重要。

Q9:Policy engine 目前在阿里的使用如何？在生產上有多上的規模使用這種方式進行動態調整？是否和社區的 HPA VPA 配合使用？

A9: Policy engine 在阿里某些集羣已經使用。至於規模暫時沒法透漏。涉及到不少組件之間的聯動，社區的 HPA 和 VPA 目前都不太能知足咱們的需求。所以阿里的 HPA 和 VPA 都是咱們自行開發的，可是和社區的原理是一致的。阿里 HPA 的開源能夠關注 Openkruise 社區。VPA 開源計劃我這裏尚未確切消息。

Q10：當單機節點資源不足以提供容器擴容時，目前是否能夠進行 HPA 或 VPA 擴容呢？

A10：單機節點不足的時候，應用能夠經過 HPA 進行增長副本應對。可是 VPA 若是選擇原節點進行更新的話，是失敗的。只能調度到其餘資源豐富的節點。在流量陡升的場景下，重建容器未必能知足需求，極可能致使雪崩，即重建過程當中，整個應用其餘未升級的副本接受更多流量，OOM 掉，新啓動的容器再瞬間被 OOM，因此重啓容器須要慎重。快速擴容（HPA）或者快速提高高優先級資源，抑制低優先級容器資源的方式效果更明顯。

關注『阿里巴巴雲原生』公衆號，回覆關鍵詞「1010」，可獲取本文 PPT。

「 阿里巴巴雲原生微信公衆號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術公衆號。」

做者：一綠舟

原文連接：https://yq.aliyun.com/article...

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