作者：易立
本系列文章
*
第一篇 - 雲原生基礎設施 第二篇 - 雲原生軟體架構* 第三篇 - 雲原生應用傳遞與運維（本文）
過去的 2020 是充滿不确定性的一年，但也是充滿機遇的一年。突發的新冠疫情為全社會的數字化轉型按下加速鍵。雲計算已經不再是一種技術，而已經成為了支撐數字經濟發展和業務創新的關鍵基礎設施。在利用雲計算重塑企業IT的過程中，生于雲、長于雲、最大化實作雲價值的雲原生技術都到越來越多企業的認同，成為企業IT降本提效的重要手段。然而，雲原生變革也不止是基礎設施和應用架構等技術層面，同時也在推進企業IT組織、流程和文化的變革。
在
CNCF 2020年度調研報告中，已經有 83％的組織也在生産環境中使用 Kubernetes，然而面臨的前三大挑戰是複雜性，文化改變與安全。
為了更好加速業務創新和解決網際網路規模的挑戰，雲原生應用架構與開發方式應運而生，與傳統單體應用架構相比，分布式微服務架構具備更好的更快的疊代速度、更低的開發複雜性，更好的可擴充性和彈性。然而，正如星戰宇宙中，原力既有光明也有黑暗的一面。微服務應用在部署、運維和管理的複雜性卻大大增加。DevOps文化和背後支撐的自動化工具與平台能力成為關鍵。
在容器技術出現之前，DevOps理論已經發展多年。但是如果”開發“與”運維“團隊不能用相同的語言進行交流，一緻的技術進行協作，那就永遠無法打破組織和文化的藩籬。Docker容器技術的出現，實作了軟體傳遞流程的标準化，一次建構，随處部署。結合雲計算可程式設計基礎設施和Kubernetes聲明式的API。可以通過流水線去實作自動化的持續內建與持續傳遞應用和基礎設施，大大加速了開發和運維角色的融合。
雲原生也是對團隊業務價值和功能的重構。傳統運維團隊的一些職責轉移到開發團隊，如應用配置和釋出，降低了每次釋出的人力成本，而運維職責将更加關注系統的穩定性和IT治理。Google倡導的SRE Site Reliability Engineering - 站點可靠性工程），是通過軟體和自動化手段，來解決系統的運維複雜性和穩定性問題。此外，安全與成本優化也成為雲上運維關注重點。
安全是企業上雲的核心關切之一。雲原生的靈活性和動态性給企業安全帶來新的挑戰。由于雲上安全是責任共擔模型，需要企業了解與雲服務商之間的責任邊界，更要思考如何通過工具化、自動化的流程固化安全最佳實踐。此外，傳統安全架構通過防火牆保護邊界，而内部的任何使用者或服務受到完全的信任。2020 突發的新冠疫情，大量的企業需要員工和客戶遠端辦公與協同，企業應用需要在IDC和雲上部署和互動。在實體安全邊界消失之後，雲安全正在迎來一場深刻的變革。
此外，新冠疫情進一步讓企業更加關注IT成本優化。雲原生的一個重要優勢是充分利用雲的彈性能力，來按需提供業務所需計算資源，避免資源浪費，實作成本優化的目标。但是，與傳統成本預算稽核制度不同，雲原生的動态性、和高密度應用部署，讓IT成本管理更加複雜。
為此，雲原生理念和技術也在發展，幫助使用者持續降低潛在風險和系統複雜性。下面我們将介紹在雲原生應用傳遞與運維領域的一些新趨勢。
https://www.atatech.org/articles/195584?spm=ata.home.0.0.31e07536wnPEnN&flag_data_from=home_follow_user_article#0 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 和AWS Controllers for Kubernetes在Kubernetes基礎之上擴充了對基礎設施的管理和抽象。這樣可以采用一緻的方式進行管理和變更K8s應用和雲基礎設施。
- 虛拟機管理: K8s通過KubeVirt可以實作對虛拟機和容器的統一排程與管理，可以利用虛拟化彌補容器技術的一些局限性，比如在CI/CD場景中，可以結合Windows虛拟機進行自動化測試。
- IoT裝置管理：KubeEdge和OpenYurt等邊緣容器技術都提供了對海量邊緣裝置的管理能力。
- K8s叢集管理：阿裡雲容器服務ACK的節點池管理，叢集管理等完全都是采用Kubernetes方式進行自動化管理與運維的。ACK Infra支撐了部署在全球各地數萬個Kubernetes叢集，基于K8s完成自動化了擴縮容、故障發現/自愈等能力。
https://www.atatech.org/articles/195584?spm=ata.home.0.0.31e07536wnPEnN&flag_data_from=home_follow_user_article#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 workloadshttps://www.atatech.org/articles/195584?spm=ata.home.0.0.31e07536wnPEnN&flag_data_from=home_follow_user_article#2 開發與運維新協作界面浮現。
雲原生技術出現也帶來了企業IT組織結構的變化。為了更好應對業務靈活性的需要，微服務應用架構催生了 “雙比薩團隊”（Two-pizza teams) 。較小的、獨立的、自包含的開發團隊可以更好達成共識，加速業務創新。SRE團隊成為了水準支撐團隊，支撐上層研發效率提升和系統穩定性。而随着 Kubernetes的發展，讓SRE團隊可以基于K8s建構自己企業的應用平台，推進标準化和自動化，讓上層應用開發團隊通過自服務的方式進行資源管理和應用生命周期管理。我們看到組織方式進一步發生了變化。新的平台工程團隊開始浮現。
這也與K8s自身定位是非常相契合的。Kubernetes的技術定位面向應用運維的基礎設施和Platform for Platform，并不是面向開發者的一體化應用平台。越來越多的企業會由平台工程團隊基于Kubernetes建構自己的PaaS平台，提升研發效率和運維效率。
類似 Cloud Foundry 的經典 PaaS 實作會建立一套獨立概念模型、技術實作和擴充機制，這種方式可以提供簡化使用者體驗，但是也引入了一些缺陷。無法和快速發展的 Kubernetes 體系相結合，無法充分組合使用多種新的技術實作，比如Serverless程式設計模型，支援AI/資料分析等新計算業務。但是基于K8s的PaaS平台缺乏統一的架構設計和實作規劃，會出現很多碎片化的技術實作，并不利于可持續的發展。
Open Application Model（OAM）開放應用模型，以及它的 Kubernetes 實作 KubeVela 項目，正是阿裡雲聯合微軟和雲原生社群，共同推出的雲原生應用傳遞與管理領域的标準模型與架構項目。其中，OAM 的設計思想是為包括 Kubernetes 在内的任何雲端基礎設施提供一個統一、面向最終使用者的應用定義模型；而 KubeVela，則是這個統一模型在 Kubernetes 上的 PaaS 參考實作。
KubeVela/OAM 提供了面向Kubernetes的服務抽象和服務組裝能力，可以将不同實作的工作負載和運維特征進行統一抽象和描述，并提供插件式的注冊與發現機制，進行動态組裝。平台工程團隊可以采用一緻的方式進行新功能擴充，并且保持與Kubernetes上新的應用架構良好的互操作性。對于應用開發和運維團隊，實作了關注點分離（Separation of Concerns），可以将應用定義、運維能力與基礎設施實作解構。讓應用傳遞過程變得更加高效、可靠和自動化。
在雲原生應用模型定義領域，業界也在不同方向進行探索。比如 AWS 新釋出的 Proton 是面向雲原生應用傳遞的服務，通過Proton，可以降低容器和Serverless部署、運維複雜性，并且可以和GitOps結合起來，提升整個應用傳遞流程的自動化和可管理性。阿裡雲Serverless K8s支援的Knative可以同時支援Serverless 容器和函數來實作事件驅動的應用，讓開發者使用一個程式設計模型，可以高效選擇底層不同Serverless化算力進行優化執行，等等。
https://www.atatech.org/articles/195584?spm=ata.home.0.0.31e07536wnPEnN&flag_data_from=home_follow_user_article#3 無處不在的安全風險催生安全架構變革
https://www.atatech.org/articles/195584?spm=ata.home.0.0.31e07536wnPEnN&flag_data_from=home_follow_user_article#4 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 的方式對基礎設施進行變更，我們可以通過掃描引擎在變更之前就進行風險掃描，如果發現相關的安全風險可以終止并告警。
此外，當應用部署到生産環境之後，任何變更都需通過上述自動化流程。這樣的方式最小化了人為的錯誤配置引發的安全風險。Garter預測，到2025年60%的企業會采納DevSecOps和不可變基礎設施實踐，與2020年相比，進而降低70%安全事件。
https://www.atatech.org/articles/195584?spm=ata.home.0.0.31e07536wnPEnN&flag_data_from=home_follow_user_article#5 服務網格加速零信任安全架構落地
分布式微服務應用不但部署和管理複雜性提升，其安全攻擊面也被放大。在傳統的三層架構中，安全防護主要在南北向流量，而在微服務架構中，東西向流量防護會有更大的挑戰。在傳統的邊界防護方式下，如果一個應用因為安全缺陷被攻陷，缺乏安全控制機制來阻止内部威脅“橫向移動”。
“零信任”最早由Forrester在2010年左右提出，簡單地說，零信任就是假定所有威脅都可能發生, 不信任網絡内部和外部的任何人/裝置/應用，需要基于認證和授權重構通路控制的信任基礎，引導安全體系架構從“網絡中心化”走向“身份中心化”；不信任傳統網絡邊界保護，而代之以微邊界保護。
Google在大力推動雲原生安全和零信任架構，比如
BeyondProd方法論。阿裡和螞蟻集團上雲過程中，也開始引入零信任架構理念和實踐。其中的關鍵是：
- 統一身份辨別體系：為微服務架構中每一個服務元件都提供一個獨立的身份辨別
- 統一通路的授權模型：服務間調用需要通過身份進行鑒權
- 統一通路控制政策：所有服務的通路控制通過标準化方向進行集中管理、和統一控制
安全架構是一種cross-cutting concern，是貫穿在整個IT架構，與所有元件相關的關注點。 如果它與具體微服務架構實作耦合，任何安全架構調整都可能對每個應用服務進行重新編譯和部署，此外微服務的實作者可以繞開安全體系。而服務網格可以提供獨立于應用實作的，松耦合、分布式的零信任安全架構。
下圖是 Istio 服務網格的安全架構，
其中
- 既可以利用現有身份服務提供身份辨別，也支援 SPIFFE 格式的身份辨別。身份辨別可以通過 X.509 證書或者 JWT格式進行傳遞。
- 通過服務網格控制平面API來統一管理，認證、授權、服務命名等安全政策。
- 通過 Envoy Sidecar 或者邊界代理伺服器作為政策執行點（PEP）來執行安全政策，可以為東西向和南北向的服務通路提供安全通路控制。而且Sidecar為每個微服務提供了應用級别的防火牆，網絡微分段最小化了安全攻擊面
服務網格讓網絡安全架構與應用實作解耦，可以獨立演進，獨立管理，提升安全合規保障。此外利用其對服務調用的遙測能力，可以進一步通過資料化、智能化方法對服務間通信流量進行風險分析、自動化防禦。雲原生零信任安全還在早期，我們期待未來更多的安全能力下沉到基礎設施之中。
https://www.atatech.org/articles/195584?spm=ata.home.0.0.31e07536wnPEnN&flag_data_from=home_follow_user_article#6 新一代軟體傳遞方式開始浮現
https://www.atatech.org/articles/195584?spm=ata.home.0.0.31e07536wnPEnN&flag_data_from=home_follow_user_article#7 從Infrastructure as Code到Everything as Code
基礎架構即代碼（Infrastructure-as-Code， IaC）是一種典型的聲明式API，他改變了雲上企業IT架構的管理、配置和協同方式。利用IaC工具，我們可以将雲伺服器、網絡和資料庫等雲端資源，進而實作完全自動化的建立、配置群組裝。
我們可以将IaC概念進行延伸，可以覆寫整個雲原生軟體的傳遞、運維流程，即 Everything as Code。下面圖中涉及了應用環境中各種模型，從基礎設施到應用模型定義到全局性的傳遞方式和安全體系，我們都可以通過聲明式方式對應用配置進行建立、管理和變更。
通過這種方式，我們可以為分布式的雲原生應用提供靈活的、健壯、自動化的全生命周期管理能力
- 所有配置可被版本管理，可追溯，可審計
- 所有配置可維護、可測試、可了解、可協作
- 所有配置可以進行靜态分析、保障變更的可預期性
- 所有配置可以在不同環境重制，所有環境差異也需要進行顯示聲明，提升一緻性
https://www.atatech.org/articles/195584?spm=ata.home.0.0.31e07536wnPEnN&flag_data_from=home_follow_user_article#8 聲明式的 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 的組建，我們可以期待未來社群将進一步推動相關領域标準化過程和技術落地。
為了更好幫助大家了解，我們也提供了一個基于GitOps和托管服務網格ASM的自動化漸進式釋出示例，詳見系列文章
Flagger on ASMhttps://www.atatech.org/articles/195584?spm=ata.home.0.0.31e07536wnPEnN&flag_data_from=home_follow_user_article#9 運維體系從标準化、自動化向資料化、智能化演進
随着微服務應用規模的發展，問題定位、性能優化的複雜度呈爆炸式增長。企業在IT服務管理領域雖然已經擁有多種工具集合，比如，日志分析，性能監控，配置管理等等。但是不同管理系統之間是一個個的資料孤島，無法提供複雜問題診斷所必需的端到端可見性。許多現有工具都采用基于規則的方法進行監視、警報。在日益複雜和動态的雲原生環境中，基于規則的方法過于脆弱，維護成本高且難以擴充。
AIOps是利用大資料分析和機器學習等技術自動化IT運維流程。AIOps可以通過大量的日志和性能資料處理、系統的環境配置分析，獲得對IT系統内部和外部的依賴的可見性，增強前瞻性和問題洞察，實作自治運維。
得益于雲原生技術生态的發展，AIOps與Kubernetes等技術将互相促進，進一步完善企業IT的成本優化、故障檢測和叢集優化等方案。這裡面有幾個重要的助力：
- 可觀測能力的标準化：随着雲原生技術社群 Prometheus、OpenTelemetry、OpenMetrics 等項目的發展，應用可觀測性領域在日志、監控、鍊路追蹤等領域進一步标準化和融合，使得多名額、根因分析的資料集更加豐富。Service Mesh 非侵入的資料遙測能力可以在不修改現有應用的前提下擷取更加豐富的業務名額。進而提高 AIOPS 的 AI 層面的準确率和覆寫率。
- 應用傳遞管理能力的标準化：Kubernetes 聲明式API、面向終态的應用傳遞方式，提供了更加一緻的管理運維體驗。Service Mesh 非侵入的服務流量管理能力，讓我們可以用透明的方式對應用進行管理和自動化運維。
在阿裡集團的DevOps平台“雲效”和容器平台釋出變更系統相結合，可以實作應用的“無人值守釋出”。在釋出過程中，系統持續收集包括系統資料、日志資料、業務資料等各種名額，并通過算法比對釋出前後的名額異動。一旦發現問題，就可以對釋出過程進行阻斷，甚至自動化復原。有了這項技術，任何一個開發團隊都可以安全的做好釋出工作，而不必擔心線上變更導緻的重大故障了。
https://www.atatech.org/articles/195584?spm=ata.home.0.0.31e07536wnPEnN&flag_data_from=home_follow_user_article#10 雲原生成本優化逐漸受到關注
随着企業将更多核心業務從資料中心遷移到雲上，越來越多的企業迫切需要對雲上環境進行的預算制定、成本核算和成本優化。從固定的财務成本模型，轉化為變化的、按需付費的雲财務模型，這是一個重要的觀念和技術轉變。然而大多數企業尚未對雲财務管理有清晰的認知和技術手段，在
FinOps 2020年調研報告中，将近一半的受訪者（49％）幾乎沒有或沒有自動化方法管理雲支出。為了幫助組織更好了解雲成本和IT收益，FinOps理念開始流行。
FinOps是雲财務管理的方式，是企業IT營運模式的轉變，目标是提升組織對雲成本的了解和更好地做決策。2020年8月，Linux基金會宣布成立
FinOps基金會，通過最佳實踐、教育和标準推進雲财務管學科。目前雲廠商開始逐漸加大對FinOps的支援，幫助企業的财務流程可以更好适應雲資源的可變性和動态性。比如AWS Cost Explorer, 阿裡雲費用中心，可以幫助企業更好進行成本分析和分攤。
詳見越來越多的企業在雲上通過Kubernetes平台來管理、使用基礎設施資源。通過容器來提升部署密度和應用彈性，進而降低整體計算成本。 但是在Kubernetes的動态性為資源計量和成本分攤引入新的複雜性挑戰。由于多個容器可以被動态部署在同一個虛拟機執行個體之上，可以按需彈性伸縮，我們無法簡單将底層雲資源與容器應用一一對應。2020年11月，CNCF基金會和FinOps基金會釋出了一份新的關于Kubernetes雲财務管理的白皮書
“FinOps for Kubernetes: Unpacking container cost allocation and optimization”來幫助大家更好了解相關财務管理實踐。
阿裡雲容器服務也在産品中内置了很多成本管理和優化的最佳實踐。很多客戶非常關心如何基于 Kubernetes 和資源彈性實作成本優化，通常我們建議企業更好了解自己業務類型，為K8s叢集劃分不同的節點池，在成本、穩定性和性能等多元度考量中尋找平衡點。
- 日常業務：對于可預測的、相對不變的負載，我們可以利用包年包月的裸金屬或者大規格虛拟機來提升資源使用率，降低成本。
- 計劃内的短期或周期性業務：比如雙十一大促，跨年活動等短期業務峰值，或者月底結算等周期性業務負載變化，我們可以利用虛拟機或者彈性容器執行個體來應對業務高峰。
- 非預期的突發彈性業務：比如突發新聞熱點，或者臨時的計算任務。彈性容器執行個體可以輕松實作每分鐘上千執行個體的擴容。
更多關于Kubernetes規劃問題，可以參考
https://developer.aliyun.com/article/743627https://www.atatech.org/articles/195584?spm=ata.home.0.0.31e07536wnPEnN&flag_data_from=home_follow_user_article#11 總結
過去十年，基礎架構上雲，網際網路應用架構更新，研發流程靈活化幾個技術大趨勢相交彙，與容器、Serverless、服務網格等技術創新相結合，共同催生了雲原生的理念誕生和發展。雲原生正在重新定義的計算基礎設施，應用架構群組織流程，是雲計算發展的曆史的必然。感謝所有一起在雲原生時代的同行者，讓我們共同探索和定義雲原生的未來。
片尾彩蛋，本系列三篇文章的名稱向星戰系列緻敬 :-) 你發現了嗎？
https://www.atatech.org/articles/195584?spm=ata.home.0.0.31e07536wnPEnN&flag_data_from=home_follow_user_article#12 團隊招聘
阿裡雲容器服務團隊招聘啦！歡迎轉崗、社招推薦! 一起創造雲原生激情澎湃的未來！杭州、北京、深圳均有機會哦。
https://www.atatech.org/articles/195584?spm=ata.home.0.0.31e07536wnPEnN&flag_data_from=home_follow_user_article#13
https://www.kubernetes.org.cn/8921.html掃碼了解更多技術幹貨與客戶案例：