應雲而生，幽靈的威脅 - 雲原生應用交付與運維的思考

做者 | 易立  阿里雲資深技術專家
來源|阿里巴巴雲原生公衆號

本系列文章：

• 第一篇 - 雲原生基礎設施

• 第二篇 - 雲原生軟件架構

• 第三篇 - 雲原生應用交付與運維（本文）

過去的 2020 是充滿不肯定性的一年，但也是充滿機遇的一年。突發的新冠疫情爲全社會的數字化轉型按下加速鍵。雲計算已經再也不是一種技術，而是成爲支撐數字經濟發展和業務創新的關鍵基礎設施。在利用雲計算重塑企業 IT 的過程當中，生於雲、長於雲、最大化實現雲價值的雲原生技術獲得了愈來愈多企業的認同，成爲企業 IT 降本提效的重要手段。

然而，雲原生變革也不僅是基礎設施和應用架構等技術層面，同時也在推動企業 IT 組織、流程和文化的變革。

在 CNCF 2020 年度調研報告中，已經有 83％ 的組織也在生產環境中使用 Kubernetes，然而面臨的前三大挑戰是複雜性，文化改變與安全。

爲了更好地加速業務創新和解決互聯網規模的挑戰，雲原生應用架構與開發方式應運而生，與傳統單體應用架構相比，分佈式微服務架構具有更好的、更快的迭代速度、更低的開發複雜性，更好的可擴展性和彈性。然而，正如星戰宇宙中，原力既有光明也有黑暗的一面。微服務應用在部署、運維和管理的複雜性卻大大增長，DevOps 文化和背後支撐的自動化工具與平臺能力成爲關鍵。

在容器技術出現以前，DevOps 理論已經發展多年。可是，若是」開發「與」運維「團隊不能用相同的語言進行交流，用一致的技術進行協做，那就永遠沒法打破組織和文化的藩籬。Docker 容器技術的出現，實現了軟件交付流程的標準化，一次構建，隨處部署。結合雲計算可編程基礎設施和 Kubernetes 聲明式的 API，能夠經過流水線去實現自動化的持續集成與持續交付應用和基礎設施，大大加速了開發和運維角色的融合。

雲原生也是對團隊業務價值和功能的重構。傳統運維團隊的一些職責轉移到開發團隊，如應用配置和發佈，下降了每次發佈的人力成本，而運維職責將更加關注系統的穩定性和IT治理。Google 倡導的 SRE Site Reliability Engineering （站點可靠性工程），是經過軟件和自動化手段，來解決系統的運維複雜性和穩定性問題。此外，安全與成本優化也成爲雲上運維關注重點。

安全是企業上雲的核心關切之一。雲原生的敏捷性和動態性給企業安全帶來新的挑戰。因爲雲上安全是責任共擔模型，須要企業理解與雲服務商之間的責任邊界，更要思考如何經過工具化、自動化的流程固化安全最佳實踐。此外，傳統安全架構經過防火牆保護邊界，而內部的任何用戶或服務受到徹底的信任。2020 突發的新冠疫情，大量的企業須要員工和客戶遠程辦公與協同，企業應用須要在 IDC 和雲上部署和交互。在物理安全邊界消失以後，雲安全正在迎來一場深入的變革。

此外，新冠疫情進一步讓企業更加關注IT成本優化。雲原生的一個重要優點是充分利用雲的彈性能力，來按需提供業務所需計算資源，避免資源浪費，實現成本優化的目標。可是，與傳統成本預算審覈制度不一樣，雲原生的動態性、和高密度應用部署，讓 IT 成本管理更加複雜。

爲此，雲原生理念和技術也在發展，幫助用戶持續下降潛在風險和系統複雜性。下面咱們將介紹在雲原生應用交付與運維領域的一些新趨勢。

Kubernetes 成爲了通用的、統一的雲控制平面

Kubernetes 這個單詞來自於希臘語，含義是舵手或領航員，是 「控制論」英文 「cybernetic」 的詞根。Kubernetes 成爲在容器編排的事實標準，不僅得益於 Google 的光環和 CNCF（雲原生計算基金會）的努力運做。背後是 Google 在 Borg 大規模分佈式資源調度和自動化運維領域的沉澱和系統化思考，認真理解 Kubernetes 架構設計，有助於思考在分佈式系統系統調度、管理的一些本質問題。

Kubernetes 架構的核心就是控制器循環，也是一個典型的"負反饋"控制系統。當控制器觀察到指望狀態與當前狀態存在不一致，就會持續調整資源，讓當前狀態趨近於指望狀態。好比，根據應用副本數變化進行擴縮容，節點宕機後自動遷移應用等。

K8s 的成功離不開 3 個重要的架構選擇：

• 聲明式（Declarative）的 API：在 Kubernetes 之上，開發者只需定義抽象資源的目標狀態，而由控制器來具體實現如何達成。好比 Deployment、StatefulSet、 Job 等不一樣類型工做負載資源的抽象。讓開發者能夠關注於應用自身，而非系統執行細節。聲明式API是雲原生重要的設計理念，這樣的架構方式有助於將總體運維複雜性下沉，交給基礎設施實現和持續優化。此外因爲分佈式系統的內生穩定性挑戰，基於聲明式的，面向終態的 「level-triggered」 實現比基於命令式 API、事件驅動的 「edge-triggered」 方式能夠提供更加健壯的分佈式系統實現。

• 屏蔽底層實現：K8s 經過一系列抽象如 Loadbalance Service、Ingress、CNI、CSI，幫助業務應用能夠更好經過業務語義使用基礎設施，無需關注底層實現差別。

• 可擴展性架構：全部 K8s 組件都是基於一致的、開放的 API 進行實現和交互。三方開發者也可經過 CRD（Custom Resource Definition）/ Operator 等方法提供領域相關的擴展實現，極大擴展了 K8s 的應用場景。

正因如此，Kubernetes 管理的資源和基礎設施範圍已經遠超容器應用。下面是幾個例子：

• 基礎架構管理：與開源的 Terraform 或者雲供應商自身提供的 Infrastructure as Code(IaC)工具如阿里雲 ROS、AWS CloudFormation 不一樣，Crossplane（https://crossplane.io/）和 AWS Controllers for Kubernetes 在 Kubernetes 基礎之上擴展了對基礎設施的管理和抽象。這樣能夠採用一致的方式進行管理和變動 K8s 應用和雲基礎設施。

• 虛擬機管理：K8s 經過 KubeVirt 能夠實現對虛擬機和容器的統一調度與管理，能夠利用虛擬化彌補容器技術的一些侷限性，好比在 CI/CD 場景中，能夠結合 Windows 虛擬機進行自動化測試。

• IoT 設備管理：KubeEdge 和 OpenYurt 等邊緣容器技術都提供了對海量邊緣設備的管理能力。

• K8s 集羣管理：阿里雲容器服務 ACK 的節點池管理，集羣管理等徹底都是採用 Kubernetes 方式進行自動化管理與運維的。ACK Infra 支撐了部署在全球各地數萬個 Kubernetes 集羣，基於 K8s 完成自動化了擴縮容、故障發現/自愈等能力。

1. 工做負載自動化升級

K8s 控制器 「把複雜留給本身，把簡單交給別人」的理想很是美好，然而實現一個高效、健壯的控制器卻充滿技術挑戰。

• 因爲 K8s 內置工做負載的侷限性，一些需求沒法知足企業應用遷移的需求，經過Operator framework 進行擴展成爲了常見的解決方案。可是一方面對重複的需求重複造輪子，會形成了資源的浪費；也會致使技術的碎片化，下降可移植性。

• 隨着愈來愈多的企業 IT 架構，從 on Kubernetes 到 in Kubernetes，大量的  CRD、自定義 Controller 給 Kubernetes 的穩定性和性能帶來大量的挑戰。面向終態的自動化是一把 「雙刃劍」，它既爲應用帶來了聲明式的部署能力，同時也潛在地會將一些誤操做行爲被終態化放大。在發生操做故障時副本數維持、版本一致性、級聯刪除等機制反而極可能致使爆炸半徑擴大。

OpenKruise 是阿里雲開源的雲原生應用自動化管理引擎，也是當前託管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 項目。它來自阿里巴巴多年來容器化、雲原生的技術沉澱，是阿里內部生產環境大規模應用的基於 Kubernetes 之上的標準擴展組件，一套緊貼上游社區標準、適應互聯網規模化場景的技術理念與最佳實踐。以開源項目 OpenKruise 方式與社區開放、共建。一方面幫助企業客戶在雲原生的探索的過程當中，少走彎路，減小技術碎片，提高穩定性；一方面推進上游技術社區，逐漸完善和豐富 Kubernetes的應用週期自動化能力。

更多信息能夠參考：《OpenKruise 2021 規劃曝光：More than workloads》

2. 開發與運維新協做界面浮現

雲原生技術出現也帶來了企業 IT 組織結構的變化。爲了更好應對業務敏捷性的須要，微服務應用架構催生了 「雙比薩團隊」（Two-pizza teams) 。較小的、獨立的、自包含的開發團隊能夠更好達成共識，加速業務創新。SRE 團隊成爲了水平支撐團隊，支撐上層研發效率提高和系統穩定性。而隨着 Kubernetes 的發展，讓 SRE 團隊能夠基於 K8s 構建本身企業的應用平臺，推動標準化和自動化，讓上層應用開發團隊經過自服務的方式進行資源管理和應用生命週期管理。咱們看到組織方式進一步發生了變化，新的平臺工程團隊開始浮現。

參考：https://blog.getambassador.io/the-rise-of-cloud-native-engineering-organizations-1a244581bda5

這也與 K8s 自身定位是很是相契合的。Kubernetes 的技術定位面向應用運維的基礎設施和 Platform for Platform，並非面向開發者的一體化應用平臺。愈來愈多的企業會由平臺工程團隊基於 Kubernetes 構建本身的 PaaS 平臺，提高研發效率和運維效率。

相似 Cloud Foundry 的經典 PaaS 實現會創建一套獨立概念模型、技術實現和擴展機制，這種方式能夠提供簡化用戶體驗，可是也引入了一些缺陷。沒法和快速發展的 Kubernetes 體系相結合，沒法充分組合使用多種新的技術實現，好比 Serverless 編程模型，支持 AI/數據分析等新計算業務。可是基於 K8s 的 PaaS 平臺缺少統一的架構設計和實現規劃，會出現不少碎片化的技術實現，並不利於可持續的發展。

Open Application Model（OAM）開放應用模型，以及它的 Kubernetes 實現 KubeVela 項目，正是阿里雲聯合微軟和雲原生社區，共同推出的雲原生應用交付與管理領域的標準模型與框架項目。其中，OAM 的設計思想是爲包括 Kubernetes 在內的任何雲端基礎設施提供一個統1、面向最終用戶的應用定義模型；而 KubeVela，則是這個統一模型在 Kubernetes 上的 PaaS 參考實現。

KubeVela/OAM 提供了面向 Kubernetes 的服務抽象和服務組裝能力，能夠將不一樣實現的工做負載和運維特徵進行統一抽象和描述，並提供插件式的註冊與發現機制，進行動態組裝。平臺工程團隊能夠採用一致的方式進行新功能擴展，而且保持與 Kubernetes 上新的應用框架良好的互操做性。對於應用開發和運維團隊，實現了關注點分離（Separation of Concerns），能夠將應用定義、運維能力與基礎設施實現解構，讓應用交付過程變得更加高效、可靠和自動化。

在雲原生應用模型定義領域，業界也在不一樣方向進行探索。好比 AWS 新發布的 Proton 是面向雲原生應用交付的服務，經過 Proton，能夠下降容器和 Serverless 部署、運維複雜性，而且能夠和 GitOps 結合起來，提高整個應用交付流程的自動化和可管理性。

阿里雲 Serverless K8s 支持的 Knative 能夠同時支持 Serverless 容器和函數來實現事件驅動的應用，讓開發者使用一個編程模型，能夠高效選擇底層不一樣 Serverless 化算力進行優化執行等。

無處不在的安全風險催生安全架構變革

1. DevSecOps 成爲關鍵因素

敏捷開發與可編程雲基礎設施結合在一塊兒，大大提高了企業應用的交付效率。然而在這個過程當中，若是忽視了安全風險控制，有可能形成巨大的損失。Gartner 論斷，到 2025年，雲上基礎設施 99% 的安全***問題是因爲用戶錯誤的配置和管理形成的。

在傳統軟件開發流程中，在系統設計開發完成後和發佈交付前，安全人員纔開始介入進行安全審覈。這種流程沒法知足業務快速迭代的訴求。」Shifting left on security「 (安全性左移)」開始獲得更多的關注，這將應用程序設計、開發人員儘早與安全團隊協做，並沒有縫地嵌入安全實踐。經過左移安全性，不只能夠下降安全風險，還能夠下降修復成本。IBM 的研究人員發現，解決設計中的安全問題比代碼開發期間能節省 6 倍左右的成本，比測試期間能節省 15 倍左右的成本。

DevOps 研發協做流程也隨之擴展成爲 DevSecOps。它首先是理念文化的變化，安全成爲每一個人的責任，而非專一安全團隊的責任；其次儘早解決安全問題，將安全左移到軟件設計階段，下降總體安全治理成本；最後是經過自動化工具鏈而非人治方式，實現風險預防、持續監測和及時響應能力。

DevSecOps 落地的技術前提是實現可驗證的、可復現的構建和部署流程，這樣能夠保障咱們在測試、預發、生產等不一樣環境對架構安全性進行持續驗證和改進。咱們能夠利用雲原生技術中的 immutable infrastructure （不可變基礎設施） 和聲明式的策略管理 Policy as Code 結合在一塊兒實現 DevSecOps 的落地實踐。下圖是一個最簡化的容器應用 DevSecOps 流水線。

當代碼提交以後，能夠經過阿里雲鏡像服務 ACR 主動掃描應用，並對鏡像進行簽名，當容器服務 K8s 集羣開始部署應用時，安全策略能夠對鏡像進行驗籤，能夠拒絕未經過驗籤的應用鏡像。同理，若是咱們利用 Infrastructure as Code 的方式對基礎設施進行變動，咱們能夠經過掃描引擎在變動以前就進行風險掃描，若是發現相關的安全風險能夠終止並告警。

此外，當應用部署到生產環境以後，任何變動都需經過上述自動化流程。這樣的方式最小化了人爲的錯誤配置引起的安全風險。Gartner 預測，到 2025年 60% 的企業會採納 DevSecOps 和不可變基礎設施實踐，與 2020 年相比下降 70% 安全事件。

2. 服務網格加速零信任安全架構落地

分佈式微服務應用不但部署和管理複雜性提高，其安全***面也被放大。在傳統的三層架構中，安全防禦主要在南北向流量，而在微服務架構中，東西向流量防禦會有更大的挑戰。在傳統的邊界防禦方式下，若是一個應用由於安全缺陷被攻陷，缺少安全控制機制來阻止內部威脅「橫向移動」。

https://www.nist.gov/blogs/taking-measure/zero-trust-cybersecurity-never-trust-always-verify

「零信任」最先由 Forrester 在 2010 年左右提出，簡單地說，零信任就是假定全部威脅均可能發生，不信任網絡內部和外部的任何人/設備/應用，須要基於認證和受權重構訪問控制的信任基礎，引導安全體系架構從「網絡中心化」走向「身份中心化」；不信任傳統網絡邊界保護，而代之以微邊界保護。

Google 在大力推進雲原生安全和零信任架構，好比 BeyondProd 方法論。阿里和螞蟻集團上雲過程當中，也開始引入零信任架構理念和實踐。其中的關鍵是：

• 統一身份標識體系：爲微服務架構中每個服務組件都提供一個獨立的身份標識。

• 統一訪問的受權模型：服務間調用須要經過身份進行鑑權。

• 統一訪問控制策略：全部服務的訪問控制經過標準化方向進行集中管理和統一控制。

安全架構是一種 cross-cutting concern，貫穿在整個 IT 架構與全部組件相關的關注點。若是它與具體微服務框架實現耦合，任何安全架構調整均可能對每一個應用服務進行從新編譯和部署，此外微服務的實現者能夠繞開安全體系。而服務網格能夠提供獨立於應用實現的，鬆耦合、分佈式的零信任安全架構。

下圖是 Istio 服務網格的安全架構：

其中：

• 既能夠利用現有身份服務提供身份標識，也支持 SPIFFE 格式的身份標識。身份標識能夠經過 X.509 證書或者 JWT 格式進行傳遞。

• 經過服務網格控制平面 API 來統一管理，認證、受權、服務命名等安全策略。

• 經過 Envoy Sidecar 或者邊界代理服務器做爲策略執行點（PEP）來執行安全策略，能夠爲東西向和南北向的服務訪問提供安全訪問控制。並且 Sidecar 爲每一個微服務提供了應用級別的防火牆，網絡微分段最小化了安全***面。

服務網格讓網絡安全架構與應用實現解耦，能夠獨立演進，獨立管理，提高安全合規保障。此外利用其對服務調用的遙測能力，能夠進一步經過數據化、智能化方法對服務間通訊流量進行風險分析、自動化防護。雲原生零信任安全還在早期，咱們期待將來更多的安全能力下沉到基礎設施之中。

新一代軟件交付方式開始浮現

1. 從 Infrastructure as Code 到 Everything as Code

基礎架構即代碼（Infrastructure-as-Code， IaC）是一種典型的聲明式 API，它改變了雲上企業IT架構的管理、配置和協同方式。利用 IaC 工具，咱們能夠將雲服務器、網絡和數據庫等雲端資源，進而實現徹底自動化的建立、配置和組裝。

咱們能夠將 IaC 概念進行延伸，能夠覆蓋整個雲原生軟件的交付、運維流程，即  Everything as Code。下圖中涉及了應用環境中各類模型，從基礎設施到應用模型定義到全局性的交付方式和安全體系，咱們均可以經過聲明式方式對應用配置進行建立、管理和變動。

經過這種方式，咱們能夠爲分佈式的雲原生應用提供靈活、健壯、自動化的全生命週期管理能力：

• 全部配置可被版本管理，可追溯，可審計。
• 全部配置可維護、可測試、可理解、可協做。
• 全部配置能夠進行靜態分析、保障變動的可預期性。
• 全部配置能夠在不一樣環境重現，全部環境差別也須要進行顯示聲明，提高一致性。

2. 聲明式的 CI/CD 實踐逐漸受到關注

更進一步，咱們能夠將應用程序的全部環境配置都經過源代碼控制系統進行管理，並經過自動化的流程進行面向終態地交付和變動，這就是 GitOps 的核心理念。

GitOps 最初由 Weaveworks 的 Alexis Richardson 提出，目標是提供一套統一部署、管理和監控應用程序的最佳實踐。在 GitOps 中，從應用定義到基礎設施配置的全部環境信息都做爲源代碼，經過 Git 進行版本管理；全部發布、審批、變動的流程都記錄在 Git 的歷史狀態中。這樣 Git 成爲 source of truth，咱們能夠高效地追溯歷史變動、能夠輕鬆回滾到指定版本。GitOps 與 Kubernetes 提倡的聲明式 API、不可變基礎設施相結合，咱們能夠保障相同配置的可復現性，避免線上環境因爲配置漂移致使的不可預測的穩定性風險。

結合上文提到的 DevSecOps 自動化流程，咱們能夠在業務上線以前，提供一致的測試和預發環境，更早，更快地捕獲系統中的穩定性風險，更完善地驗證灰度、回滾措施。

GitOps 提高了交付效率，改進了開發者的體驗，也提高了分佈式應用交付的穩定性。

GitOps 在過去兩年時間裏，在阿里集團和螞蟻都被普遍使用，成爲雲原生應用標準化的交付方式。目前 GitOps 還在發展初期，開源社區還在不斷完善相關的工具和最佳實踐。2020年，Weaveworks 的 Flagger 目併入 Flux，開發者能夠經過 GitOps 的方式實現灰度發佈、藍綠髮布、A/B 測試等漸進的交付策略，能夠控制發佈的爆炸半徑，提高發布的穩定性。在 2020 年底，CNCF 應用交付領域小組正式宣佈了 GitOps Working Group 的組建，咱們期待將來社區將進一步推進相關領域標準化過程和技術落地。

3. 運維體系從標準化、自動化向數據化、智能化演進

隨着微服務應用規模的發展，問題定位、性能優化的複雜度呈爆炸式增加。企業在IT服務管理領域雖然已經擁有多種工具集合，好比，日誌分析、性能監控、配置管理等。可是不一樣管理系統之間是一個個數據孤島，沒法提供複雜問題診斷所必需的端到端可見性。許多現有工具都採用基於規則的方法進行監視、警報。在日益複雜和動態的雲原生環境中，基於規則的方法過於脆弱，維護成本高且難以擴展。

AIOps 是利用大數據分析和機器學習等技術自動化IT運維流程。AIOps 能夠經過大量的日誌和性能數據處理、系統的環境配置分析，得到對IT系統內部和外部的依賴的可見性，加強前瞻性和問題洞察，實現自治運維。

得益於雲原生技術生態的發展，AIOps 與 Kubernetes 等技術將相互促進，進一步完善企業 IT 的成本優化、故障檢測和集羣優化等方案。這裏面有幾個重要的助力：

• 可觀測能力的標準化：隨着雲原生技術社區 Prometheus、OpenTelemetry、OpenMetrics 等項目的發展，應用可觀測性領域在日誌、監控、鏈路追蹤等領域進一步標準化和融合，使得多指標、根因分析的數據集更加豐富。Service Mesh 非侵入的數據遙測能力能夠在不修改現有應用的前提下獲取更加豐富的業務指標。從而提升 AIOPS 的 AI 層面的準確率和覆蓋率。

• 應用交付管理能力的標準化：Kubernetes 聲明式 API、面向終態的應用交付方式，提供了更加一致的管理運維體驗。Service Mesh 非侵入的服務流量管理能力，讓咱們能夠用透明的方式對應用進行管理和自動化運維。

經過阿里集團的 DevOps 平臺「雲效」和容器平臺發佈變動系統相結合，能夠實現應用的「無人值守發佈」。在發佈過程當中，系統持續收集包括系統數據、日誌數據、業務數據等各類指標，並經過算法比對發佈先後的指標異動。一旦發現問題，就能夠對發佈過程進行阻斷，甚至自動化回滾。有了這項技術，任何一個開發團隊均可以安全的作好發佈工做，而沒必要擔憂線上變動致使的重大故障了。

雲原生成本優化逐漸受到關注

隨着企業將更多核心業務從數據中心遷移到雲上，愈來愈多的企業迫切須要對雲上環境進行預算制定、成本覈算和成本優化。從固定的財務成本模型，轉化爲變化的、按需付費的雲財務模型，這是一個重要的觀念和技術轉變。然而大多數企業還沒有對雲財務管理有清晰的認知和技術手段，在 FinOps 2020 年調研報告中，將近一半的受訪者（49％）幾乎沒有或沒有自動化方法管理雲支出。爲了幫助組織更好了解雲成本和IT收益，FinOps 理念開始流行。

FinOps 是雲財務管理的方式，是企業 IT 運營模式的轉變，目標是提高組織對雲成本的理解和更好地作決策。2020年8月，Linux基金會宣佈成立 FinOps 基金會，經過最佳實踐、教育和標準推動雲財務管學科。目前雲廠商開始逐漸加大對 FinOps 的支持，幫助企業的財務流程能夠更好適應雲資源的可變性和動態性。好比 AWS Cost Explorer, 阿里雲費用中心，能夠幫助企業更好進行成本分析和分攤。詳見：https://developer.aliyun.com/article/772964。

愈來愈多的企業在雲上經過 Kubernetes 平臺來管理、使用基礎設施資源。經過容器來提高部署密度和應用彈性，從而下降總體計算成本。可是在 Kubernetes 的動態性爲資源計量和成本分攤引入新的複雜性挑戰。
因爲多個容器能夠被動態部署在同一個虛擬機實例之上，能夠按需彈性伸縮，咱們沒法簡單將底層雲資源與容器應用一一對應。2020年11月，CNCF 基金會和 FinOps 基金會發布了一份新的關於 Kubernetes 雲財務管理的白皮書 《FinOps for Kubernetes: Unpacking container cost allocation and optimization》來幫助你們更好理解相關財務管理實踐。

阿里雲容器服務也在產品中內置了不少成本管理和優化的最佳實踐。不少客戶很是關心如何基於 Kubernetes 和資源彈性實現成本優化，一般咱們建議企業更好了解本身業務類型，爲 K8s 集羣劃分不一樣的節點池，在成本、穩定性和性能等多維度考量中尋找平衡點。

• 平常業務：對於可預測的、相對不變的負載，咱們能夠利用包年包月的裸金屬或者大規格虛擬機來提高資源利用率，下降成本。

• 計劃內的短時間或週期性業務：好比雙十一大促，跨年活動等短時間業務峯值，或者月底結算等週期性業務負載變化，咱們能夠利用虛擬機或者彈性容器實例來應對業務高峯。

• 非預期的突發彈性業務：好比突發新聞熱點，或者臨時的計算任務。彈性容器實例能夠輕鬆實現每分鐘上千實例的擴容。

更多關於 Kubernetes 規劃問題，能夠參考：《關於 Kubernetes 規劃的靈魂 n 問》。

總結

過去十年，基礎架構上雲，互聯網應用架構升級，研發流程敏捷化幾個技術大趨勢相交匯，與容器、Serverless、服務網格等技術創新相結合，共同催生了雲原生的理念誕生和發展。雲原生正在從新定義的計算基礎設施、應用架構和組織流程，是雲計算髮展的歷史的必然。感謝全部一塊兒在雲原生時代的同行者，讓咱們共同探索和定義雲原生的將來。

片尾彩蛋，本系列三篇文章的名稱向星戰系列致敬，你發現了嗎？