雲原生技術發展簡史
首先從第一個問題進行分享，那就是“爲什麼要開設雲原生技術公開課？”雲原生、CNCF 都是目前非常熱門的關鍵詞，但是這些技術並不是非常新鮮的內容。
- 2004 年— 2007 年，Google 已在內部大規模地使用像 Cgroups 這樣的容器技術；
- 2008 年，Google 將 Cgroups 合併進入了 Linux 內核主幹；
- 2013 年，Docker 項目正式發佈。
- 2014 年，Kubernetes 項目也正式發佈。這樣的原因也非常容易理解，因爲有了容器和 Docker 之後，就需要有一種方式去幫助大家方便、快速、優雅地管理這些容器，這就是 Kubernetes 項目的初衷。在 Google 和 Redhat 發佈了 Kubernetes 之後，這個項目的發展速度非常之快。
- 2015 年，由Google、Redhat 以及微軟等大型雲計算廠商以及一些開源公司共同牽頭成立了 CNCF 雲原生基金會。CNCF 成立之初，就有 22 個創始會員，而且 Kubernetes 也成爲了 CNCF 託管的第一個開源項目。在這之後，CNCF 的發展速度非常迅猛；
- 2017 年，CNCF 達到 170 個成員和 14 個基金項目；
- 2018 年，CNCF 成立三週年有了 195 個成員，19 個基金會項目和 11 個孵化項目，如此之快的發展速度在整個雲計算領域都是非常罕見的。
雲原生技術生態現狀
因此，如今我們所討論的雲原生技術生態是一個龐大的技術集合。CNCF 有一張雲原生全景圖（https://github.com/cncf/landscape），在這個全景圖裏已經有 200 多個項目和產品了，這些項目和產品也都是和 CNCF 的觀點所契合的。所以如果以這張全景圖作爲背景，加以思考就會發現，我們今天所討論的雲原生其實主要談論了以下幾點：
- 雲原生基金會 —— CNCF；
- 雲原生技術社區，比如像 CNCF 目前正式託管的 20 多個項目共同構成了現代雲計算生態的基石，其中像 Kubernetes 這樣的項目已經成爲了世界第四活躍的開源項目；
- 除了前面兩點之外，現在全球各大公有云廠商都已經支持了 Kubernetes。此外，還有 100 多家技術創業公司也在持續地進行投入。現在阿里巴巴也在談全面上雲，而且上雲就要上雲原生，這也是各大技術公司擁抱雲原生的一個例子。
我們正處於時代的關鍵節點
2019 年正是雲原生時代的關鍵節點，爲什麼這麼說？我們這裏就爲大家簡單梳理一下。
從 2013 年 Docker 項目發佈開始說起，Docker 項目的發佈使得全操作系統語義的沙盒技術唾手可得，使得用戶能夠更好地、更完整地打包自己的應用，使得開發者可以輕而易舉的獲得了一個應用的最小可運行單位，而不需要依賴任何 PaaS 能力。這對經典 PaaS 產業其實是一個“降維打擊”。
2014 年的時候，Kubernetes 項目發佈，其意義在於 Google 將內部的 Borg/Omega 系統思想借助開源社區實現了“重生”，並且提出了“容器設計模式”的思想。而 Google 之所以選擇間接開源 Kubernetes 而不是直接開源 Borg 項目，其實背後的原因也比較容易理解：Borg/Omega 這樣的系統太複雜了，是沒辦法提供給 Google 之外的人使用，但是 Borg/Omega 這樣的設計思想卻可以藉助 Kubernetes 讓大家接觸到，這也是開源 Kubernetes 的重要背景。
這樣到了 2015 年到 2016 年，就到了容器編排“三國爭霸”的時代，當時 Docker、Swarm、Mesos、Kubernetes 都在容器編排領域展開角逐，他們競爭的原因其實也比較容易理解， 那就是 Docker 或者容器本身的價值雖然大，但是如果想要讓其產生商業價值或者說對雲的價值，那麼就一定需要在編排上面佔據一個有利的位置。
Swarm 和 Mesos 的特點，那就是各自只在生態和技術方面比較強，其中，Swarm 更偏向於生態，而 Mesos 技術更強一些。相比之下， Kubernetes 則兼具了兩者優勢，最終在 2017 年“三國爭霸”的局面中得以勝出，成爲了當時直到現在的容器編排標準。這一過程的代表性事件就是 Docker 公司宣佈在覈心產品中內置了 Kubernetes 服務，並且 Swarm 項目逐漸停止維護。
到了 2018 年的時候，雲原生技術理念開始逐漸萌芽，這是因爲此時 Kubernetes 以及容器都成爲了雲廠商的既定標準，以“雲”爲核心的軟件研發思想逐步形成。
而到了 2019 年，情況似乎又將發生一些變化。
2019 年——雲原生技術普及元年
爲什麼說 2019 年很可能是一個關鍵節點呢？我們認爲 2019 年是雲原生技術的普及元年。
首先大家可以看到，在 2019 年，阿里巴巴宣佈要全面上雲，而且“上雲就要上雲原生”。我們還可以看到，以“雲”爲核心的軟件研發思想，正逐步成爲所有開發者的默認選項。像 Kubernetes 等雲原生技術正在成爲技術人員的必修課，大量的工作崗位正在湧現出來。
這種背景下，“會 Kubernetes”已經遠遠不夠了，“懂 Kubernetes”、“會雲原生架構”的重要性正日益凸顯出來。 從 2019 年開始，雲原生技術將會大規模普及，這也是爲什麼大家都要在這個時間點上學習和投資雲原生技術的重要原因。
二、“雲原生技術公開課”是一門怎樣的課程？
基於上面所提到的技術趨勢，所以阿里巴巴和 CNCF 聯合開設了雲原生技術公開課。
那麼這樣的公開課到底在講什麼內容呢？
公開課教學大綱
第一期雲原生公開課的教學大綱，主要以應用容器和 Kubernetes 爲核心，在後面幾期將會陸續上線 Service Mesh、Serverless 等相關課程。
在第一期公開課中，我們首先將課程分爲兩部分——基礎知識部分和進階知識部分，總共有 17 個知識點。
- 首先，我們希望通過第一部分的課程講解幫助大家夯實基礎。然後，對於更高階的內容展開更深入的代碼級別的剖析。希望通過這樣循序漸進的方式幫助大家學習雲原生技術；
- 其次，在每個課程後面我們的講師都會設置對應的課後自測考試題，這些考試題實際上是對本節課程最有效的歸納，我們希望能夠通過課後評測的方式來幫助大家總結知識點，打造出屬於自己的雲原生知識體系；
- 最後，我們的講師在每個知識點的背後都設計了雲端實踐，所謂“實踐出真知”，學習計算機相關的知識還是需要上手來實際地進行操作纔可以。 因此在雲端實踐部分，講師會提供詳細的實踐步驟供大家課後自我聯繫。並且在這個環節，阿里雲還會贈送了定量的阿里雲代金券幫助大家更好地在雲上進行實踐。
以上三個部分就構成了阿里雲和 CNCF 聯合推出的雲原生技術公開課的教學內容。
公開課授課計劃（第一期）
在授課計劃方面，初步這樣安排：第一堂課在 2019 年 4 月的第三週上線，此後將會每週更新一課，對於部分比較重要的知識點將會每週更新兩次，總共 25 個課時。每個知識點後面都提供了課後自測和雲端實踐。
對於講師陣容而言，也是本次公開課最引以爲傲的部分。我們的公開課將會主要由 CNCF 社區資深成員與項目維護者爲大家講解，很多課程講師都是阿里雲容器平臺團隊的專家級工程師。同時，我們也會邀請雲原生社區的資深專家和外部講師爲大家講解部分內容。因此在課程進行過程中，我們會不定期地安排大咖直播、課程答疑和落地實踐案例。
我們希望將這些內容都集成在一起，爲大家呈現一箇中國最完整、最權威、最具有影響力的雲原生技術公開課。
課程預備知識
大家可能存在這樣的疑惑，就是想要學習雲原生基礎知識之前需要哪些預備知識呢？其實大致需要三部分預備知識：
- Linux 操作系統知識：主要是一些通識性的基礎，最好具有一定的在 Linux 下開發的經驗；
- 計算機和程序設計的基礎：這一點到入門工程師或者高年級本科生水平就足夠了；
- 容器的使用基礎：希望大傢俱有容器的簡單使用經驗，比如 docker run 以及 docker build 等，最好有一定 Docker 化應用開發的經驗。當然，我們在課程中也會講解相關的基礎知識。
三、什麼是“雲原生”？雲原生該怎麼落地？
在介紹完課程之後，我們再來詳細的聊一聊“雲原生”：什麼是“雲原生”？雲原生該怎麼落地？這兩個問題也是整個課程的核心內容。
雲原生的定義
很多人都會問“到底什麼是雲原生？”
實際上，雲原生是一條最佳路徑或者最佳實踐。更詳細的說，雲原生爲用戶指定了一條低心智負擔的、敏捷的、能夠以可擴展、可複製的方式最大化地利用雲的能力、發揮雲的價值的最佳路徑。
因此，雲原生其實是一套指導進行軟件架構設計的思想。按照這樣的思想而設計出來的軟件：首先，天然就“生在雲上，長在雲上”；其次，能夠最大化地發揮雲的能力，使得我們開發的軟件和“雲”能夠天然地集成在一起，發揮出“雲”的最大價值。
所以，雲原生的最大價值和願景，就是認爲未來的軟件，會從誕生起就生長在雲上，並且遵循一種新的軟件開發、發佈和運維模式，從而使得軟件能夠最大化地發揮雲的能力。說到了這裏，大家可以思考一下爲什麼容器技術具有革命性？
其實，容器技術和集裝箱技術的革命性非常類似，即：容器技術使得應用具有了一種“自包含”的定義方式。所以，這樣的應用才能以敏捷的、以可擴展可複製的方式發佈在雲上，發揮出雲的能力。這也就是容器技術對雲發揮出的革命性影響所在，所以說，容器技術正是雲原生技術的核心底盤。
雲原生的技術範疇
雲原生的技術範疇包括了以下幾個方面：
- 第一部分是雲應用定義與開發流程。這包括應用定義與鏡像製作、配置 CI/CD、消息和 Streaming 以及數據庫等。
- 第二部分是雲應用的編排與管理流程。這也是 Kubernetes 比較關注的一部分，包括了應用編排與調度、服務發現治理、遠程調用、API 網關以及 Service Mesh。
- 第三部分是監控與可觀測性。這部分所強調的是雲上應用如何進行監控、日誌收集、Tracing 以及在雲上如何實現破壞性測試，也就是混沌工程的概念。
- 第四部分就是雲原生的底層技術，比如容器運行時、雲原生存儲技術、雲原生網絡技術等。
- 第五部分是雲原生工具集，在前面的這些核心技術點之上，還有很多配套的生態或者周邊的工具需要使用，比如流程自動化與配置管理、容器鏡像倉庫、雲原生安全技術以及雲端密碼管理等。
- 最後則是 Serverless。Serverless 是一種 PaaS 的特殊形態，它定義了一種更爲“極端抽象”的應用編寫方式，包含了 FaaS 和 BaaS 這樣的概念。而無論是 FaaS 還是 BaaS，其最爲典型的特點就是按實際使用計費（Pay as you go），因此 Serverless 計費也是重要的知識和概念。
雲原生思想的兩個理論
在瞭解完雲原生的技術範疇之後你就會發現，其所包含的技術內容還是很多的，但是這些內容的技術本質卻是類似的。雲原生技術的本質是兩個理論基礎。
- 第一個理論基礎是：不可變基礎設施。這一點目前是通過容器鏡像來實現的，其含義就是應用的基礎設施應該是不可變的，是一個自包含、自描述可以完全在不同環境中遷移的東西；
- 第二個理論基礎就是：雲應用編排理論。當前的實現方式就是 Google 所提出來的“容器設計模式”，這也是本系列課程中的 Kubernetes 部分所需主要講解的內容。
基礎設施向雲演進的過程
首先爲大家介紹一下“不可變基礎設施”的概念。其實，應用所依賴的基礎設施也在經歷一個向雲演進的過程，舉例而言，對於傳統的應用基礎設施而言，其實往往是可變的。
大家可能經常會幹這樣一件事情，比如需要發佈或者更新一個軟件，那麼流程大致是這樣的，先通過 SSH 連到服務器，然後手動升級或者降級軟件包，逐個調整服務器上的配置文件，並且將新代碼直接都部署到現有服務器上。因此，這套基礎設施會不斷地被調整和修改。
但是在雲上，對“雲”友好的應用基礎設施是不可變的。
這種場景下的上述更新過程會這麼做：一旦應用部署完成之後，那麼這套應用基礎設施就不會再修改了。如果需要更新，那麼需要現更改公共鏡像來構建新服務直接替換舊服務。而我們之所以能夠實現直接替換，就是因爲容器提供了自包含的環境（包含應用運行所需的所有依賴）。所以對於應用而言，完全不需要關心容器發生了什麼變化，只需要把容器鏡像本身修改掉就可以了。因此，對於雲友好的基礎設施是隨時可以替換和更換的，這就是因爲容器具有敏捷和一致性的能力，也就是雲時代的應用基礎設施。
所以，總結而言，雲時代的基礎設施就像是可以替代的“牲口”，可以隨時替換；而傳統的基礎設施則是獨一無二的“寵物”，需要細心呵護，這就體現出了雲時代不可變基礎設施的優點。
基礎設施向雲演進的意義
所以，像這樣的基礎設施向“不可變”演進的過程，爲我們提供了兩個非常重要的優點。
- 1、基礎設施的一致性和可靠性。同樣一個鏡像，無論是在美國打開，在中國打開，還是在印度打開都是一樣的。並且其中的 OS 環境對於應用而言都是一致的。而對於應用而言，它就不需要關心容器跑在哪裏，這就是基礎設施一致性非常重要的一個特徵。
- 2、這樣的鏡像本身就是自包含的，其包含了應用運行所需要的所有依賴，因此也可以漂移到雲上的任何一個位置。
此外，雲原生的基礎設施還提供了簡單、可預測的部署和運維能力。由於現在有了鏡像，應用還是自描述的，通過鏡像運行起來的整個容器其實可以像 Kubernetes 的 Operator 技術一樣將其做成自運維的，所以整個應用本身都是自包含的行爲，使得其能夠遷移到雲上任何一個位置。這也使得整個流程的自動化變得非常容易。
應用本身也可以更好地擴容，從 1 個實例變成 100 個實例，進而變成 1 萬個實例，這個過程對於容器化後的應用沒有任何特殊的。最後，我們這時也能夠通過不可變的基礎設施來地快速周圍的管控系統和支撐組件。因爲，這些組件本身也是容器化的，是符合不可變基礎設施這樣一套理論的組件。
以上就是不可變基礎設施爲用戶帶來的最大的優點。
雲原生關鍵技術點
當我們回過頭來看雲原生關鍵技術點或者說它所依賴的技術理論的時候，可以看到主要有這樣的四個方向：
- 如何構建自包含、可定製的應用鏡像；
- 能不能實現應用快速部署與隔離能力；
- 應用基礎設施創建和銷燬的自動化管理；
- 可複製的管控系統和支撐組件。
這四個雲原生關鍵技術點是落地實現雲原生技術的四個主要途徑，而這四個技術點也是本門課程的 17 個技術點所主要講述的核心知識。
Pivotal 是雲原生應用的提出者，並推出了Pivotal Cloud Foundry 雲原生應用平臺和 Spring 開源 Java 開發框架，成爲雲原生應用架構中先驅者和探路者。
雲原生的概念歷經了許多個版本的迭代，到了2015年Google主導成立了雲原生計算基金會（CNCF），對雲原生的定義爲：
雲原生（Cloud Native）技技術幫助企業和機構在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、 服務網格、微服務、不可變基礎設施和聲明式 API。
這些技術能夠構建容錯性好、易於管理和便於觀察的松耦合系統。結合可靠的自動化手段，雲原生技術可以使開發者輕鬆地對系統進行頻 繁並可預測的重大變更 。
乾貨！看雲原生時代阿里雲的四個“最”
雲原生已經成爲 IT 領域最熱的詞之一。到底有多火，大家感受一下：
2015 年在舊金山召開的首屆 KubeCon 只有 200 餘參會者，而今年第二次在中國舉辦的KubeCon迎來了3000+現場觀衆，遍佈全球的線上關注開者則更是不計其數。Gartner最近發佈報告表示雲原生時代已來，在未來三年中將有75%的全球化企業將在生產中使用容器化的應用。
作爲雲原生技術與應用的領先企業，阿里雲在今年的 KubeCon + CloudNativeCon 大會上爲全球企業和開發者分享了26場行業趨勢和技術演講。
阿里雲智能容器平臺負責人丁宇指出：
雲原生正在重塑整個軟件生命週期，容器、Kuberentes、雲原生成爲雲時代的三個重要標準。阿里雲將繼續加大雲原生技術棧產品體系的研發，並持續回饋開源社區，與生態合作伙伴一起，共同推動雲原生標準制定以及應用的落地。
9年技術沉澱，阿里云云原生的四個“最”
阿里巴巴是國內最早佈局雲原生技術的公司之一，丁宇在 26 日的主題演講中表示：“早在 2011年，阿里巴巴就率先開始了容器化進程，開啓了中國公司將雲原生技術體系在電商、金融、製造等領域中大規模應用的先河。”
歷經9年技術沉澱，阿里雲成爲國內唯一進入 Gartner《公有云容器服務競爭格局》報告的企業。
今年 3 月，阿里雲智能總裁張建鋒表示，未來 1-2 年內，阿里巴巴要實現 100% 的業務跑在公共雲之上，並且繼續大力投入雲原生技術的研發。
最豐富的雲原生產品家族
經過 9 年的內部技術實踐，阿里雲已擁有國內最豐富的雲原生產品家族，覆蓋八大類別 20 餘款產品，涵蓋底層基礎設施、數據智能、分佈式應用等，可以滿足不同行業場景的需求。
目前阿里巴巴集團內部電商、城市大腦等核心業務已經大規模使用雲原生技術，去年雙 11，阿里雲完成了 10 分鐘 1000 臺以上服務器的快速部署，容器部署規模達到百萬級，兩年內實現全部上雲，是全球最大規模的雲原生應用實踐。
最全面的雲原生開源貢獻
阿里雲一直致力於回饋社區、積極擁抱開源，是國內在雲原生領域的開源貢獻最全面的科技公司，涵蓋編排調度、作業管理、無服務器框架等：
● 主導維護 etcd、containerd、dragonfly 等多個 CNCF 明星項目的發展，已有超過 10 個項目進入 CNCFlandscape；
● 項目建設層面：積極建設 Kubernetes 項目，貢獻量位居全球前 10；
● 開源生態支持：加入 CNCF、OCI、CDF 等基金會，成爲多個基金會的頂級會員，共建開源生態。
今年 1 月，阿里雲資深技術專家李響成爲首個入選全球頂級開源社區 CNCF 技術監督委員會的中國工程師,致力於推動雲原生技術的落地。
最大的容器集羣和客戶羣體
除了支持集團內部應用規模化運維，阿里云云原生技術還向全社會輸出。阿里雲 ACK（容器服務）遍佈全球 18 個 region，擁有國內最大公共雲容器集羣以及客戶羣體。
邊緣容器、雲原生應用管理與交付體系
大會期間，阿里雲重磅發佈邊緣容器（ACK@Edge）和雲原生應用管理與交付體系，進一步擴大雲原生應用場景，並提升企業的雲上應用開發效率。
丁宇認爲：“隨着 5G 和物聯網時代的到來，傳統雲計算中心集中存儲、計算的模式已經無法滿足終端設備對於時效、容量、算力的需求。將雲計算的能力下沉到邊緣側、設備側，並通過中心進行統一交付、運維、管控，將是雲計算的重要發展趨勢。”
邊緣容器可實現雲、邊、端一體化的應用分發，支持不同系統架構和網絡狀況下，應用的分發和生命週期管理，並且針對邊緣及設備進行如訪問協議、同步機制、安全機制的種種優化。 該產品採用了自研高性能 Terway 網絡插件，能將彈性網卡 ENI 分配給容器實例，使容器實例和 ECS 使用同一個網絡平面，性能較傳統的 overlay 容器網絡高出 20%。
雲原生應用管理與交付體系涵蓋國內首個開放雲原生應用中心 Cloud Native App Hub、雲原生應用自動化引擎 OpenKruise 等服務。
其中，OpenKruise 開源項目源自於阿里巴巴經濟體過去多年的大規模應用部署、發佈與管理的最佳實踐，同時解決了 Kubernetes 之上應用的自動化管理問題。OpenKruise 後續會繼續覆蓋部署、升級、彈性擴縮容、QoS 調節、健康檢查，遷移修復等更多 K8s 自動化能力。
廣泛的雲原生應用實踐
全鏈路壓測、極速彈性擴縮容以及雲原生的全棧技術已廣泛服務於互聯網、金融、零售、製造、政務等領域企業和機構，大幅降低了應用開發的門檻，讓企業輕鬆享受雲的技術紅利。
例如，企業可以通過雲原生架構簡化雲上預演及實戰，提升應對流量高峯的效率及可靠性，使用阿里雲 ACK 可在容器應用層面實現業務高彈性，還可以通過 PolarDB 實現數據庫的橫向縱向擴縮容，通過 PTS 性能測試服務模擬真實業務流量進行全鏈路壓力測試。
奧組委通過容器服務 ACK，在歐洲助力奧運 OCS 頻道敏捷開發高效運維；西門子使用阿里雲 ACK，實現開放式物聯網操作系統 MindSphere 微服務架構、DevOps 以及系統的高可用；迅雷使用容器混合雲方案，完成雲下及雲上混合部署和調度，在享受極致彈性的同時降低成本。
堅持探索與落地並重，阿里巴巴雲原生之路全景揭祕
本文根據 2019年6月26日 KubeCon China 大會上李響 Keynote 演講稿整理。
演講人簡介：李響，CNCF TOC Member （CNCF技術監督委員會成員），阿里雲資深技術專家，etcd 項目作者，曾就職於 CoreOS，現負責阿里巴巴大規模容器編排與調度引擎的相關技術工作。
爲什麼要做雲原生？雲原生究竟能帶來什麼價值？從最初的獨自摸索到如今擁抱開源回饋社區，阿里巴巴走過了怎樣的雲原生旅程？又有哪些技術心得？今天，將全部分享出來。
多年沉澱，堅持探索與落地並重
阿里巴巴從 2011 年開始通過容器實踐雲原生技術體系，在整個業界都還沒有任何範例可供參考的大背境下，逐漸摸索出了一套比肩全球一線技術公司並且服務於整個阿里集團的容器化基礎設施架構。這個探索歷程雖然孤獨，但卻被始終如一的堅持至今。這正是在這個孤注一擲的技術探索與奮進的過程中，阿里巴巴的技術團隊完整的經歷了雲原生技術浪潮裏的所有關鍵節點，不僅成爲了這次技術革命的重要見證者，也逐漸成爲中國雲原生技術體系當之無愧的推動者與引領者之一。
阿里的體量大、業務複雜，推動雲原生要找到合適的切入點。在雙十一成本壓力的推動下，資源成本與效率優化成了阿里雲原生的起點。
阿里從容器入手，研究低成本虛擬化與調度技術：提供靈活、標準的部署單元；將靜態資源分配更換爲動態按需調度，進一步提升部署效率，解決資源碎片化問題，提高部署密度；通過存儲網絡虛擬化和存儲計算分離等技術，增強任務的可遷移性，進一步提高了資源的可靠性，降低了資源成本。
在資源成本的推動下，阿里完成了全面容器化，資源分配也被高效調度平臺接管。阿里的雲原生並未止步於此。提高研發效率與加快迭代週期是推動阿里業務增強的祕密武器。阿里希望通過雲原生讓開發者效率更高。
爲了降低應用部署難度，提高部署自動化程度，阿里開始採用 Kubernetes 作爲容器編排平臺，並且持續推動 Kubernetes 的性能與可擴展性。具體 Kubernetes，阿里持續對研發、部署流程進行改進。爲了構建更雲原生化的 CI/CD，進一步做到標準化和自動化，從研發到上線流程，阿里引入了諸如 Helm 的應用標準化管理，也嘗試了 GitOps 這樣的部署流程，還推動了 PaaS 層的面向終態自動化改造。於此同時，阿里也開始探索服務網格，致力於進一步提高服務治理的普適性與標準性，降低開發者採用門檻，進一步推動微服務在多語言和多環境下的普及。
今年，阿里也展開了全站上雲。經過雲原生的探索與改造，阿里基礎架構體系是現代化和標準化的。利用容器技術，應用與宿主機運行時完成了解耦；利用 Kubernetes 對 Pod 與 Volume 等的抽象，完成了對多種資源實現的統一化；通過智能調度與 PaaS 平臺，讓自動遷移應用，修復不穩定因素成爲了可能，阿里通過雲原生技術大大降低了上雲的難度。
在這個提高資源和人員效率的過程中，阿里巴巴的整個基礎設施也變得更加開放，連通開源生態，在交流互動中不斷吸收和貢獻好的理念、技術、思想。如今，阿里雲不僅支撐着中國最大的雲原生應用雙 11，而且擁有國內最大的公共雲集羣和鏡像倉庫。作爲唯一入選 Gartner 的公有云容器服務競爭格局的廠商，阿里雲也積累了最爲豐富和寶貴的客戶實踐。
追求極致，優化擴展性和規模性
彈性和規模性，這是支撐阿里巴巴各種類型的複雜場景以及流量高峯的關鍵因素。
經過不斷打磨，阿里巴巴在 Kubernetes 規模與性能上取得了顯著的成果：將存儲object 的數量提升 25倍，支持的節點數從 5000 提升到上萬，在端到端調度延遲從5s 變爲 100ms 等等。其中有不少工作在阿里巴巴和社區中共同開展，而這些研發成果都已經貢獻給社區，我們期望其他企業及開發者也可以享受阿里巴巴規模所帶來的技術紅利。
阿里巴巴持續優化性能，可以分爲以下四個維度：工作負載追蹤、性能分析、定製化調度、大規模鏡像分發。首先對工作負載調度有完整的追蹤、重放機制，其次將所有性能問題的進行細緻分析，逐一攻克技術瓶頸。Kubernetes 本身的可定製性很強，阿里巴巴針對自身業務場景沉澱了定製化的調度能力和鏡像分發系統。開源Dragonfly 項目脫胎於雙十一，具備極強的鏡像分發能力。數十個超級集羣，每個超級集羣具有數萬節點，數百萬的容器。
阿里巴巴落地 Kubernetes 可以分爲三個階段：首先通過 Kubernetes 提供資源供給，但是不過多幹擾運維流程，這系統容器是富容器，將鏡像標準化與輕量級虛擬化能力帶給了上面的 PaaS 平臺。第二步，通過 Kubernetes controller 的形式改造PaaS 平臺的運維流程，給 PaaS 帶來更強的面向終態的自動化能力。最後把運行環境等傳統重模式改成原生容器與 pod 的輕量模式，同時將 PaaS 能力完全移交給Kubernetes controller，從而形成一個完全雲原生的架構體系。
如何解決雲原生的關鍵難點
阿里巴巴雲原生的探索，起步於自研容器和調度系統，到如今擁抱開源的標準化技術。對於當下開發者的建議是：如果想構建雲原生架構，建議直接從 Kubernetes 入手即可。一方面，Kubernetes 爲平臺建設者而生，已經成爲雲原生生態的中流砥柱，它不僅向下屏蔽了底層細節，而且向上支撐各種周邊業務生態；另一方面，更重要的是社區中有着越來越多圍繞 Kubernetes 構建的開源項目，比如Service Mesh、Kubeflow。
那麼作爲過來人，阿里有哪些“避坑指南”呢？
原生技術架構演進中最爲艱難的挑戰，其實來自於 Kubernetes 本身的管理。因爲 Kubernetes 相對年輕，其自身的運維管理系統生態尚不完善。對於阿里而言，數以萬計的集羣管理至關重要，我們探索並總結了四個方法：Kubernetes on Kubernetes，利用 K8s 來管理 K8s 自身；節點發布回滾策略，按規則要求灰度發佈；將環境進行鏡像切分，分爲模擬環境和生產環境；並且在監控側下足功夫，將Kubernetes 變得更白盒化和透明化，及早發現問題、預防問題、解決問題。
另外一個關鍵技術問題是 Kubernetes 的多租戶管理。相比於 namespace 擴展性差和命名衝突等限制，可以在 Kubernetes 之上建立虛擬集羣。在提高擴展性的同時，能夠做到 API 層面的強隔離，通過 syncer 鏈接虛擬集羣和真實集羣，在 node 添加 agent，達到更好的多租管理和更好的利用。
此次 KubeCon 大會上，阿里雲重磅公佈了兩個項目：Cloud Native App Hub —— 面向所有開發者的 Kubernetes 應用管理中心，OpenKruise —— 源自全球頂級互聯網場景的 Kubernetes 自動化開源項目集。
OpenKruise 開源地址：https://github.com/openkruise/kruise
Cloud Native App Hub：https://developer.aliyun.com/hub
雲原生應用中心（Cloud Native App Hub），可以簡單理解爲 Helm 應用中國鏡像站，方便用戶獲得應用資源，並大大簡化了 Kubernetes 部署安裝一個應用的步驟；OpenKruise/Kruise 項目致力於成爲“雲原生應用自動化引擎”，解決大規模應用場景下的諸多運維痛點。這次沙龍首秀，開發者們體驗了從雲原生應用中心快速下載應用，並通過帶狀態pod 原地升級、sidecar 容器注入、節點鏡像預熱等三個場景，實際體驗了 Kruise 強大的自動化運維能力。
值得一提的是，OpenKruise 項目源自於阿里巴巴經濟體過去多年的大規模應用部署、發佈與管理的最佳實踐；源於容器平臺團隊對集團應用規模化運維，規模化建站的能力；源於阿里雲 Kubernetes 服務數千客戶的需求沉澱。從不同維度解決了 Kubernetes 之上應用的自動化問題，包括部署、升級、彈性擴縮容、QoS 調節、健康檢查，遷移修復等等。
最後，給大家來個雲原生的乾貨：