簡(jiǎn)介：過去的 2020 是充滿不確定性的一年，但也是充滿機(jī)遇的一年。突發(fā)的新冠疫情為全社會(huì)的數(shù)字化轉(zhuǎn)型按下加速鍵。云計(jì)算已經(jīng)不再是一種技術(shù)，而是成為支撐數(shù)字經(jīng)濟(jì)發(fā)展和業(yè)務(wù)創(chuàng)新的關(guān)鍵基礎(chǔ)設(shè)施。在利用云計(jì)算重塑企業(yè) IT 的過程中，生于云、長(zhǎng)于云、最大化實(shí)現(xiàn)云價(jià)值的云原生技術(shù)得到了越來越多企業(yè)的認(rèn)同，成為企業(yè) IT 降本提效的重要手段。

作者 | 易立? 阿里云資深技術(shù)專家
來源|阿里巴巴云原生公眾號(hào)

本系列文章：

• 第一篇 -?云原生基礎(chǔ)設(shè)施
• 第二篇 -?云原生軟件架構(gòu)
• 第三篇 - 云原生應(yīng)用交付與運(yùn)維（本文）

過去的 2020 是充滿不確定性的一年，但也是充滿機(jī)遇的一年。突發(fā)的新冠疫情為全社會(huì)的數(shù)字化轉(zhuǎn)型按下加速鍵。云計(jì)算已經(jīng)不再是一種技術(shù)，而是成為支撐數(shù)字經(jīng)濟(jì)發(fā)展和業(yè)務(wù)創(chuàng)新的關(guān)鍵基礎(chǔ)設(shè)施。在利用云計(jì)算重塑企業(yè) IT 的過程中，生于云、長(zhǎng)于云、最大化實(shí)現(xiàn)云價(jià)值的云原生技術(shù)得到了越來越多企業(yè)的認(rèn)同，成為企業(yè) IT 降本提效的重要手段。

然而，云原生變革也不只是基礎(chǔ)設(shè)施和應(yīng)用架構(gòu)等技術(shù)層面，同時(shí)也在推進(jìn)企業(yè) IT 組織、流程和文化的變革。

在 CNCF 2020 年度調(diào)研報(bào)告中，已經(jīng)有 83％ 的組織也在生產(chǎn)環(huán)境中使用 Kubernetes，然而面臨的前三大挑戰(zhàn)是復(fù)雜性，文化改變與安全。

為了更好地加速業(yè)務(wù)創(chuàng)新和解決互聯(lián)網(wǎng)規(guī)模的挑戰(zhàn)，云原生應(yīng)用架構(gòu)與開發(fā)方式應(yīng)運(yùn)而生，與傳統(tǒng)單體應(yīng)用架構(gòu)相比，分布式微服務(wù)架構(gòu)具備更好的、更快的迭代速度、更低的開發(fā)復(fù)雜性，更好的可擴(kuò)展性和彈性。然而，正如星戰(zhàn)宇宙中，原力既有光明也有黑暗的一面。微服務(wù)應(yīng)用在部署、運(yùn)維和管理的復(fù)雜性卻大大增加，DevOps 文化和背后支撐的自動(dòng)化工具與平臺(tái)能力成為關(guān)鍵。

在容器技術(shù)出現(xiàn)之前，DevOps 理論已經(jīng)發(fā)展多年。但是，如果”開發(fā)“與”運(yùn)維“團(tuán)隊(duì)不能用相同的語(yǔ)言進(jìn)行交流，用一致的技術(shù)進(jìn)行協(xié)作，那就永遠(yuǎn)無法打破組織和文化的藩籬。Docker 容器技術(shù)的出現(xiàn)，實(shí)現(xiàn)了軟件交付流程的標(biāo)準(zhǔn)化，一次構(gòu)建，隨處部署。結(jié)合云計(jì)算可編程基礎(chǔ)設(shè)施和 Kubernetes 聲明式的 API，可以通過流水線去實(shí)現(xiàn)自動(dòng)化的持續(xù)集成與持續(xù)交付應(yīng)用和基礎(chǔ)設(shè)施，大大加速了開發(fā)和運(yùn)維角色的融合。

云原生也是對(duì)團(tuán)隊(duì)業(yè)務(wù)價(jià)值和功能的重構(gòu)。傳統(tǒng)運(yùn)維團(tuán)隊(duì)的一些職責(zé)轉(zhuǎn)移到開發(fā)團(tuán)隊(duì)，如應(yīng)用配置和發(fā)布，降低了每次發(fā)布的人力成本，而運(yùn)維職責(zé)將更加關(guān)注系統(tǒng)的穩(wěn)定性和IT治理。Google 倡導(dǎo)的 SRE Site Reliability Engineering （站點(diǎn)可靠性工程），是通過軟件和自動(dòng)化手段，來解決系統(tǒng)的運(yùn)維復(fù)雜性和穩(wěn)定性問題。此外，安全與成本優(yōu)化也成為云上運(yùn)維關(guān)注重點(diǎn)。

安全是企業(yè)上云的核心關(guān)切之一。云原生的敏捷性和動(dòng)態(tài)性給企業(yè)安全帶來新的挑戰(zhàn)。由于云上安全是責(zé)任共擔(dān)模型，需要企業(yè)理解與云服務(wù)商之間的責(zé)任邊界，更要思考如何通過工具化、自動(dòng)化的流程固化安全最佳實(shí)踐。此外，傳統(tǒng)安全架構(gòu)通過防火墻保護(hù)邊界，而內(nèi)部的任何用戶或服務(wù)受到完全的信任。2020 突發(fā)的新冠疫情，大量的企業(yè)需要員工和客戶遠(yuǎn)程辦公與協(xié)同，企業(yè)應(yīng)用需要在 IDC 和云上部署和交互。在物理安全邊界消失之后，云安全正在迎來一場(chǎng)深刻的變革。

此外，新冠疫情進(jìn)一步讓企業(yè)更加關(guān)注IT成本優(yōu)化。云原生的一個(gè)重要優(yōu)勢(shì)是充分利用云的彈性能力，來按需提供業(yè)務(wù)所需計(jì)算資源，避免資源浪費(fèi)，實(shí)現(xiàn)成本優(yōu)化的目標(biāo)。但是，與傳統(tǒng)成本預(yù)算審核制度不同，云原生的動(dòng)態(tài)性、和高密度應(yīng)用部署，讓 IT 成本管理更加復(fù)雜。

為此，云原生理念和技術(shù)也在發(fā)展，幫助用戶持續(xù)降低潛在風(fēng)險(xiǎn)和系統(tǒng)復(fù)雜性。下面我們將介紹在云原生應(yīng)用交付與運(yùn)維領(lǐng)域的一些新趨勢(shì)。

Kubernetes 成為了通用的、統(tǒng)一的云控制平面

Kubernetes 這個(gè)單詞來自于希臘語(yǔ)，含義是舵手或領(lǐng)航員，是 “控制論”英文 “cybernetic” 的詞根。Kubernetes 成為在容器編排的事實(shí)標(biāo)準(zhǔn)，不只得益于 Google 的光環(huán)和 CNCF（云原生計(jì)算基金會(huì)）的努力運(yùn)作。背后是 Google 在 Borg 大規(guī)模分布式資源調(diào)度和自動(dòng)化運(yùn)維領(lǐng)域的沉淀和系統(tǒng)化思考，認(rèn)真理解 Kubernetes 架構(gòu)設(shè)計(jì)，有助于思考在分布式系統(tǒng)系統(tǒng)調(diào)度、管理的一些本質(zhì)問題。

Kubernetes 架構(gòu)的核心就是控制器循環(huán)，也是一個(gè)典型的"負(fù)反饋"控制系統(tǒng)。當(dāng)控制器觀察到期望狀態(tài)與當(dāng)前狀態(tài)存在不一致，就會(huì)持續(xù)調(diào)整資源，讓當(dāng)前狀態(tài)趨近于期望狀態(tài)。比如，根據(jù)應(yīng)用副本數(shù)變化進(jìn)行擴(kuò)縮容，節(jié)點(diǎn)宕機(jī)后自動(dòng)遷移應(yīng)用等。

K8s 的成功離不開 3 個(gè)重要的架構(gòu)選擇：

• 聲明式（Declarative）的 API：在 Kubernetes 之上，開發(fā)者只需定義抽象資源的目標(biāo)狀態(tài)，而由控制器來具體實(shí)現(xiàn)如何達(dá)成。比如 Deployment、StatefulSet、 Job 等不同類型工作負(fù)載資源的抽象。讓開發(fā)者可以關(guān)注于應(yīng)用自身，而非系統(tǒng)執(zhí)行細(xì)節(jié)。聲明式API是云原生重要的設(shè)計(jì)理念，這樣的架構(gòu)方式有助于將整體運(yùn)維復(fù)雜性下沉，交給基礎(chǔ)設(shè)施實(shí)現(xiàn)和持續(xù)優(yōu)化。此外由于分布式系統(tǒng)的內(nèi)生穩(wěn)定性挑戰(zhàn)，基于聲明式的，面向終態(tài)的 “l(fā)evel-triggered” 實(shí)現(xiàn)比基于命令式 API、事件驅(qū)動(dòng)的 “edge-triggered” 方式可以提供更加健壯的分布式系統(tǒng)實(shí)現(xiàn)。
• 屏蔽底層實(shí)現(xiàn)：K8s 通過一系列抽象如 Loadbalance Service、Ingress、CNI、CSI，幫助業(yè)務(wù)應(yīng)用可以更好通過業(yè)務(wù)語(yǔ)義使用基礎(chǔ)設(shè)施，無需關(guān)注底層實(shí)現(xiàn)差異。
• 可擴(kuò)展性架構(gòu)：所有 K8s 組件都是基于一致的、開放的 API 進(jìn)行實(shí)現(xiàn)和交互。三方開發(fā)者也可通過 CRD（Custom Resource Definition）/ Operator 等方法提供領(lǐng)域相關(guān)的擴(kuò)展實(shí)現(xiàn)，極大擴(kuò)展了 K8s 的應(yīng)用場(chǎng)景。

正因如此，Kubernetes 管理的資源和基礎(chǔ)設(shè)施范圍已經(jīng)遠(yuǎn)超容器應(yīng)用。下面是幾個(gè)例子：

• 基礎(chǔ)架構(gòu)管理：與開源的 Terraform 或者云供應(yīng)商自身提供的 Infrastructure as Code(IaC)工具如阿里云 ROS、AWS CloudFormation 不同，Crossplane（https://crossplane.io/）和 AWS Controllers for Kubernetes 在 Kubernetes 基礎(chǔ)之上擴(kuò)展了對(duì)基礎(chǔ)設(shè)施的管理和抽象。這樣可以采用一致的方式進(jìn)行管理和變更 K8s 應(yīng)用和云基礎(chǔ)設(shè)施。
• 虛擬機(jī)管理：K8s 通過 KubeVirt 可以實(shí)現(xiàn)對(duì)虛擬機(jī)和容器的統(tǒng)一調(diào)度與管理，可以利用虛擬化彌補(bǔ)容器技術(shù)的一些局限性，比如在 CI/CD 場(chǎng)景中，可以結(jié)合 Windows 虛擬機(jī)進(jìn)行自動(dòng)化測(cè)試。
• IoT 設(shè)備管理：KubeEdge 和 OpenYurt 等邊緣容器技術(shù)都提供了對(duì)海量邊緣設(shè)備的管理能力。
• K8s 集群管理：阿里云容器服務(wù) ACK 的節(jié)點(diǎn)池管理，集群管理等完全都是采用 Kubernetes 方式進(jìn)行自動(dòng)化管理與運(yùn)維的。ACK Infra 支撐了部署在全球各地?cái)?shù)萬(wàn)個(gè) Kubernetes 集群，基于 K8s 完成自動(dòng)化了擴(kuò)縮容、故障發(fā)現(xiàn)/自愈等能力。

1. 工作負(fù)載自動(dòng)化升級(jí)

K8s 控制器 “把復(fù)雜留給自己，把簡(jiǎn)單交給別人”的理想非常美好，然而實(shí)現(xiàn)一個(gè)高效、健壯的控制器卻充滿技術(shù)挑戰(zhàn)。

• 由于 K8s 內(nèi)置工作負(fù)載的局限性，一些需求無法滿足企業(yè)應(yīng)用遷移的需求，通過Operator framework 進(jìn)行擴(kuò)展成為了常見的解決方案。但是一方面對(duì)重復(fù)的需求重復(fù)造輪子，會(huì)造成了資源的浪費(fèi)；也會(huì)導(dǎo)致技術(shù)的碎片化，降低可移植性。
• 隨著越來越多的企業(yè) IT 架構(gòu)，從 on Kubernetes 到 in Kubernetes，大量的? CRD、自定義 Controller 給 Kubernetes 的穩(wěn)定性和性能帶來大量的挑戰(zhàn)。面向終態(tài)的自動(dòng)化是一把 “雙刃劍”，它既為應(yīng)用帶來了聲明式的部署能力，同時(shí)也潛在地會(huì)將一些誤操作行為被終態(tài)化放大。在發(fā)生操作故障時(shí)副本數(shù)維持、版本一致性、級(jí)聯(lián)刪除等機(jī)制反而很可能導(dǎo)致爆炸半徑擴(kuò)大。

OpenKruise 是阿里云開源的云原生應(yīng)用自動(dòng)化管理引擎，也是當(dāng)前托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 項(xiàng)目。它來自阿里巴巴多年來容器化、云原生的技術(shù)沉淀，是阿里內(nèi)部生產(chǎn)環(huán)境大規(guī)模應(yīng)用的基于 Kubernetes 之上的標(biāo)準(zhǔn)擴(kuò)展組件，一套緊貼上游社區(qū)標(biāo)準(zhǔn)、適應(yīng)互聯(lián)網(wǎng)規(guī)模化場(chǎng)景的技術(shù)理念與最佳實(shí)踐。以開源項(xiàng)目 OpenKruise 方式與社區(qū)開放、共建。一方面幫助企業(yè)客戶在云原生的探索的過程中，少走彎路，減少技術(shù)碎片，提升穩(wěn)定性；一方面推動(dòng)上游技術(shù)社區(qū)，逐漸完善和豐富 Kubernetes的應(yīng)用周期自動(dòng)化能力。

更多信息可以參考：《OpenKruise 2021 規(guī)劃曝光：More than workloads》

2. 開發(fā)與運(yùn)維新協(xié)作界面浮現(xiàn)

云原生技術(shù)出現(xiàn)也帶來了企業(yè) IT 組織結(jié)構(gòu)的變化。為了更好應(yīng)對(duì)業(yè)務(wù)敏捷性的需要，微服務(wù)應(yīng)用架構(gòu)催生了 “雙比薩團(tuán)隊(duì)”（Two-pizza teams) 。較小的、獨(dú)立的、自包含的開發(fā)團(tuán)隊(duì)可以更好達(dá)成共識(shí)，加速業(yè)務(wù)創(chuàng)新。SRE 團(tuán)隊(duì)成為了水平支撐團(tuán)隊(duì)，支撐上層研發(fā)效率提升和系統(tǒng)穩(wěn)定性。而隨著 Kubernetes 的發(fā)展，讓 SRE 團(tuán)隊(duì)可以基于 K8s 構(gòu)建自己企業(yè)的應(yīng)用平臺(tái)，推進(jìn)標(biāo)準(zhǔn)化和自動(dòng)化，讓上層應(yīng)用開發(fā)團(tuán)隊(duì)通過自服務(wù)的方式進(jìn)行資源管理和應(yīng)用生命周期管理。我們看到組織方式進(jìn)一步發(fā)生了變化，新的平臺(tái)工程團(tuán)隊(duì)開始浮現(xiàn)。

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

這也與 K8s 自身定位是非常相契合的。Kubernetes 的技術(shù)定位面向應(yīng)用運(yùn)維的基礎(chǔ)設(shè)施和 Platform for Platform，并不是面向開發(fā)者的一體化應(yīng)用平臺(tái)。越來越多的企業(yè)會(huì)由平臺(tái)工程團(tuán)隊(duì)基于 Kubernetes 構(gòu)建自己的 PaaS 平臺(tái)，提升研發(fā)效率和運(yùn)維效率。

類似 Cloud Foundry 的經(jīng)典 PaaS 實(shí)現(xiàn)會(huì)建立一套獨(dú)立概念模型、技術(shù)實(shí)現(xiàn)和擴(kuò)展機(jī)制，這種方式可以提供簡(jiǎn)化用戶體驗(yàn)，但是也引入了一些缺陷。無法和快速發(fā)展的 Kubernetes 體系相結(jié)合，無法充分組合使用多種新的技術(shù)實(shí)現(xiàn)，比如 Serverless 編程模型，支持 AI/數(shù)據(jù)分析等新計(jì)算業(yè)務(wù)。但是基于 K8s 的 PaaS 平臺(tái)缺乏統(tǒng)一的架構(gòu)設(shè)計(jì)和實(shí)現(xiàn)規(guī)劃，會(huì)出現(xiàn)很多碎片化的技術(shù)實(shí)現(xiàn)，并不利于可持續(xù)的發(fā)展。

Open Application Model（OAM）開放應(yīng)用模型，以及它的 Kubernetes 實(shí)現(xiàn) KubeVela 項(xiàng)目，正是阿里云聯(lián)合微軟和云原生社區(qū)，共同推出的云原生應(yīng)用交付與管理領(lǐng)域的標(biāo)準(zhǔn)模型與框架項(xiàng)目。其中，OAM 的設(shè)計(jì)思想是為包括 Kubernetes 在內(nèi)的任何云端基礎(chǔ)設(shè)施提供一個(gè)統(tǒng)一、面向最終用戶的應(yīng)用定義模型；而 KubeVela，則是這個(gè)統(tǒng)一模型在 Kubernetes 上的 PaaS 參考實(shí)現(xiàn)。

KubeVela/OAM 提供了面向 Kubernetes 的服務(wù)抽象和服務(wù)組裝能力，可以將不同實(shí)現(xiàn)的工作負(fù)載和運(yùn)維特征進(jìn)行統(tǒng)一抽象和描述，并提供插件式的注冊(cè)與發(fā)現(xiàn)機(jī)制，進(jìn)行動(dòng)態(tài)組裝。平臺(tái)工程團(tuán)隊(duì)可以采用一致的方式進(jìn)行新功能擴(kuò)展，并且保持與 Kubernetes 上新的應(yīng)用框架良好的互操作性。對(duì)于應(yīng)用開發(fā)和運(yùn)維團(tuán)隊(duì)，實(shí)現(xiàn)了關(guān)注點(diǎn)分離（Separation of Concerns），可以將應(yīng)用定義、運(yùn)維能力與基礎(chǔ)設(shè)施實(shí)現(xiàn)解構(gòu)，讓應(yīng)用交付過程變得更加高效、可靠和自動(dòng)化。

在云原生應(yīng)用模型定義領(lǐng)域，業(yè)界也在不同方向進(jìn)行探索。比如 AWS 新發(fā)布的 Proton 是面向云原生應(yīng)用交付的服務(wù)，通過 Proton，可以降低容器和 Serverless 部署、運(yùn)維復(fù)雜性，并且可以和 GitOps 結(jié)合起來，提升整個(gè)應(yīng)用交付流程的自動(dòng)化和可管理性。

阿里云 Serverless K8s 支持的 Knative 可以同時(shí)支持 Serverless 容器和函數(shù)來實(shí)現(xiàn)事件驅(qū)動(dòng)的應(yīng)用，讓開發(fā)者使用一個(gè)編程模型，可以高效選擇底層不同 Serverless 化算力進(jìn)行優(yōu)化執(zhí)行等。

無處不在的安全風(fēng)險(xiǎn)催生安全架構(gòu)變革

1. DevSecOps 成為關(guān)鍵因素

敏捷開發(fā)與可編程云基礎(chǔ)設(shè)施結(jié)合在一起，大大提升了企業(yè)應(yīng)用的交付效率。然而在這個(gè)過程中，如果忽視了安全風(fēng)險(xiǎn)控制，有可能造成巨大的損失。Gartner 論斷，到 2025年，云上基礎(chǔ)設(shè)施 99% 的安全滲透問題是由于用戶錯(cuò)誤的配置和管理造成的。

在傳統(tǒng)軟件開發(fā)流程中，在系統(tǒng)設(shè)計(jì)開發(fā)完成后和發(fā)布交付前，安全人員才開始介入進(jìn)行安全審核。這種流程無法滿足業(yè)務(wù)快速迭代的訴求。”Shifting left on security“ (安全性左移)”開始得到更多的關(guān)注，這將應(yīng)用程序設(shè)計(jì)、開發(fā)人員盡早與安全團(tuán)隊(duì)協(xié)作，并無縫地嵌入安全實(shí)踐。通過左移安全性，不僅可以降低安全風(fēng)險(xiǎn)，還可以降低修復(fù)成本。IBM 的研究人員發(fā)現(xiàn)，解決設(shè)計(jì)中的安全問題比代碼開發(fā)期間能節(jié)省 6 倍左右的成本，比測(cè)試期間能節(jié)省 15 倍左右的成本。

DevOps 研發(fā)協(xié)作流程也隨之?dāng)U展成為 DevSecOps。它首先是理念文化的變化，安全成為每個(gè)人的責(zé)任，而非專注安全團(tuán)隊(duì)的責(zé)任；其次盡早解決安全問題，將安全左移到軟件設(shè)計(jì)階段，降低整體安全治理成本；最后是通過自動(dòng)化工具鏈而非人治方式，實(shí)現(xiàn)風(fēng)險(xiǎn)預(yù)防、持續(xù)監(jiān)測(cè)和及時(shí)響應(yīng)能力。

DevSecOps 落地的技術(shù)前提是實(shí)現(xiàn)可驗(yàn)證的、可復(fù)現(xiàn)的構(gòu)建和部署流程，這樣可以保障我們?cè)跍y(cè)試、預(yù)發(fā)、生產(chǎn)等不同環(huán)境對(duì)架構(gòu)安全性進(jìn)行持續(xù)驗(yàn)證和改進(jìn)。我們可以利用云原生技術(shù)中的 immutable infrastructure （不可變基礎(chǔ)設(shè)施） 和聲明式的策略管理 Policy as Code 結(jié)合在一起實(shí)現(xiàn) DevSecOps 的落地實(shí)踐。下圖是一個(gè)最簡(jiǎn)化的容器應(yīng)用 DevSecOps 流水線。

當(dāng)代碼提交之后，可以通過阿里云鏡像服務(wù) ACR 主動(dòng)掃描應(yīng)用，并對(duì)鏡像進(jìn)行簽名，當(dāng)容器服務(wù) K8s 集群開始部署應(yīng)用時(shí)，安全策略可以對(duì)鏡像進(jìn)行驗(yàn)簽，可以拒絕未通過驗(yàn)簽的應(yīng)用鏡像。同理，如果我們利用 Infrastructure as Code 的方式對(duì)基礎(chǔ)設(shè)施進(jìn)行變更，我們可以通過掃描引擎在變更之前就進(jìn)行風(fēng)險(xiǎn)掃描，如果發(fā)現(xiàn)相關(guān)的安全風(fēng)險(xiǎn)可以終止并告警。

此外，當(dāng)應(yīng)用部署到生產(chǎn)環(huán)境之后，任何變更都需通過上述自動(dòng)化流程。這樣的方式最小化了人為的錯(cuò)誤配置引發(fā)的安全風(fēng)險(xiǎn)。Gartner 預(yù)測(cè)，到 2025年 60% 的企業(yè)會(huì)采納 DevSecOps 和不可變基礎(chǔ)設(shè)施實(shí)踐，與 2020 年相比降低 70% 安全事件。

2. 服務(wù)網(wǎng)格加速零信任安全架構(gòu)落地

分布式微服務(wù)應(yīng)用不但部署和管理復(fù)雜性提升，其安全攻擊面也被放大。在傳統(tǒng)的三層架構(gòu)中，安全防護(hù)主要在南北向流量，而在微服務(wù)架構(gòu)中，東西向流量防護(hù)會(huì)有更大的挑戰(zhàn)。在傳統(tǒng)的邊界防護(hù)方式下，如果一個(gè)應(yīng)用因?yàn)榘踩毕荼还ハ?#xff0c;缺乏安全控制機(jī)制來阻止內(nèi)部威脅“橫向移動(dòng)”。

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

“零信任”最早由 Forrester 在 2010 年左右提出，簡(jiǎn)單地說，零信任就是假定所有威脅都可能發(fā)生，不信任網(wǎng)絡(luò)內(nèi)部和外部的任何人/設(shè)備/應(yīng)用，需要基于認(rèn)證和授權(quán)重構(gòu)訪問控制的信任基礎(chǔ)，引導(dǎo)安全體系架構(gòu)從“網(wǎng)絡(luò)中心化”走向“身份中心化”；不信任傳統(tǒng)網(wǎng)絡(luò)邊界保護(hù)，而代之以微邊界保護(hù)。

Google 在大力推動(dòng)云原生安全和零信任架構(gòu)，比如 BeyondProd 方法論。阿里和螞蟻集團(tuán)上云過程中，也開始引入零信任架構(gòu)理念和實(shí)踐。其中的關(guān)鍵是：

• 統(tǒng)一身份標(biāo)識(shí)體系：為微服務(wù)架構(gòu)中每一個(gè)服務(wù)組件都提供一個(gè)獨(dú)立的身份標(biāo)識(shí)。
• 統(tǒng)一訪問的授權(quán)模型：服務(wù)間調(diào)用需要通過身份進(jìn)行鑒權(quán)。
• 統(tǒng)一訪問控制策略：所有服務(wù)的訪問控制通過標(biāo)準(zhǔn)化方向進(jìn)行集中管理和統(tǒng)一控制。

安全架構(gòu)是一種 cross-cutting concern，貫穿在整個(gè) IT 架構(gòu)與所有組件相關(guān)的關(guān)注點(diǎn)。如果它與具體微服務(wù)框架實(shí)現(xiàn)耦合，任何安全架構(gòu)調(diào)整都可能對(duì)每個(gè)應(yīng)用服務(wù)進(jìn)行重新編譯和部署，此外微服務(wù)的實(shí)現(xiàn)者可以繞開安全體系。而服務(wù)網(wǎng)格可以提供獨(dú)立于應(yīng)用實(shí)現(xiàn)的，松耦合、分布式的零信任安全架構(gòu)。

下圖是 Istio 服務(wù)網(wǎng)格的安全架構(gòu)：

其中：

• 既可以利用現(xiàn)有身份服務(wù)提供身份標(biāo)識(shí)，也支持 SPIFFE 格式的身份標(biāo)識(shí)。身份標(biāo)識(shí)可以通過 X.509 證書或者 JWT 格式進(jìn)行傳遞。
• 通過服務(wù)網(wǎng)格控制平面 API 來統(tǒng)一管理，認(rèn)證、授權(quán)、服務(wù)命名等安全策略。
• 通過 Envoy Sidecar 或者邊界代理服務(wù)器作為策略執(zhí)行點(diǎn)（PEP）來執(zhí)行安全策略，可以為東西向和南北向的服務(wù)訪問提供安全訪問控制。而且 Sidecar 為每個(gè)微服務(wù)提供了應(yīng)用級(jí)別的防火墻，網(wǎng)絡(luò)微分段最小化了安全攻擊面。

服務(wù)網(wǎng)格讓網(wǎng)絡(luò)安全架構(gòu)與應(yīng)用實(shí)現(xiàn)解耦，可以獨(dú)立演進(jìn)，獨(dú)立管理，提升安全合規(guī)保障。此外利用其對(duì)服務(wù)調(diào)用的遙測(cè)能力，可以進(jìn)一步通過數(shù)據(jù)化、智能化方法對(duì)服務(wù)間通信流量進(jìn)行風(fēng)險(xiǎn)分析、自動(dòng)化防御。云原生零信任安全還在早期，我們期待未來更多的安全能力下沉到基礎(chǔ)設(shè)施之中。

新一代軟件交付方式開始浮現(xiàn)

1. 從 Infrastructure as Code 到 Everything as Code

基礎(chǔ)架構(gòu)即代碼（Infrastructure-as-Code， IaC）是一種典型的聲明式 API，它改變了云上企業(yè)IT架構(gòu)的管理、配置和協(xié)同方式。利用 IaC 工具，我們可以將云服務(wù)器、網(wǎng)絡(luò)和數(shù)據(jù)庫(kù)等云端資源，進(jìn)而實(shí)現(xiàn)完全自動(dòng)化的創(chuàng)建、配置和組裝。

我們可以將 IaC 概念進(jìn)行延伸，可以覆蓋整個(gè)云原生軟件的交付、運(yùn)維流程，即? Everything as Code。下圖中涉及了應(yīng)用環(huán)境中各種模型，從基礎(chǔ)設(shè)施到應(yīng)用模型定義到全局性的交付方式和安全體系，我們都可以通過聲明式方式對(duì)應(yīng)用配置進(jìn)行創(chuàng)建、管理和變更。

通過這種方式，我們可以為分布式的云原生應(yīng)用提供靈活、健壯、自動(dòng)化的全生命周期管理能力：

• 所有配置可被版本管理，可追溯，可審計(jì)。
• 所有配置可維護(hù)、可測(cè)試、可理解、可協(xié)作。
• 所有配置可以進(jìn)行靜態(tài)分析、保障變更的可預(yù)期性。
• 所有配置可以在不同環(huán)境重現(xiàn)，所有環(huán)境差異也需要進(jìn)行顯示聲明，提升一致性。

2. 聲明式的 CI/CD 實(shí)踐逐漸受到關(guān)注

更進(jìn)一步，我們可以將應(yīng)用程序的所有環(huán)境配置都通過源代碼控制系統(tǒng)進(jìn)行管理，并通過自動(dòng)化的流程進(jìn)行面向終態(tài)地交付和變更，這就是 GitOps 的核心理念。

GitOps 最初由 Weaveworks 的 Alexis Richardson 提出，目標(biāo)是提供一套統(tǒng)一部署、管理和監(jiān)控應(yīng)用程序的最佳實(shí)踐。在 GitOps 中，從應(yīng)用定義到基礎(chǔ)設(shè)施配置的所有環(huán)境信息都作為源代碼，通過 Git 進(jìn)行版本管理；所有發(fā)布、審批、變更的流程都記錄在 Git 的歷史狀態(tài)中。這樣 Git 成為 source of truth，我們可以高效地追溯歷史變更、可以輕松回滾到指定版本。GitOps 與 Kubernetes 提倡的聲明式 API、不可變基礎(chǔ)設(shè)施相結(jié)合，我們可以保障相同配置的可復(fù)現(xiàn)性，避免線上環(huán)境由于配置漂移導(dǎo)致的不可預(yù)測(cè)的穩(wěn)定性風(fēng)險(xiǎn)。

結(jié)合上文提到的 DevSecOps 自動(dòng)化流程，我們可以在業(yè)務(wù)上線之前，提供一致的測(cè)試和預(yù)發(fā)環(huán)境，更早，更快地捕獲系統(tǒng)中的穩(wěn)定性風(fēng)險(xiǎn)，更完善地驗(yàn)證灰度、回滾措施。

GitOps 提升了交付效率，改進(jìn)了開發(fā)者的體驗(yàn)，也提升了分布式應(yīng)用交付的穩(wěn)定性。

GitOps 在過去兩年時(shí)間里，在阿里集團(tuán)和螞蟻都被廣泛使用，成為云原生應(yīng)用標(biāo)準(zhǔn)化的交付方式。目前 GitOps 還在發(fā)展初期，開源社區(qū)還在不斷完善相關(guān)的工具和最佳實(shí)踐。2020年，Weaveworks 的 Flagger 目并入 Flux，開發(fā)者可以通過 GitOps 的方式實(shí)現(xiàn)灰度發(fā)布、藍(lán)綠發(fā)布、A/B 測(cè)試等漸進(jìn)的交付策略，可以控制發(fā)布的爆炸半徑，提升發(fā)布的穩(wěn)定性。在 2020 年末，CNCF 應(yīng)用交付領(lǐng)域小組正式宣布了 GitOps Working Group 的組建，我們期待未來社區(qū)將進(jìn)一步推動(dòng)相關(guān)領(lǐng)域標(biāo)準(zhǔn)化過程和技術(shù)落地。

3. 運(yùn)維體系從標(biāo)準(zhǔn)化、自動(dòng)化向數(shù)據(jù)化、智能化演進(jìn)

隨著微服務(wù)應(yīng)用規(guī)模的發(fā)展，問題定位、性能優(yōu)化的復(fù)雜度呈爆炸式增長(zhǎng)。企業(yè)在IT服務(wù)管理領(lǐng)域雖然已經(jīng)擁有多種工具集合，比如，日志分析、性能監(jiān)控、配置管理等。但是不同管理系統(tǒng)之間是一個(gè)個(gè)數(shù)據(jù)孤島，無法提供復(fù)雜問題診斷所必需的端到端可見性。許多現(xiàn)有工具都采用基于規(guī)則的方法進(jìn)行監(jiān)視、警報(bào)。在日益復(fù)雜和動(dòng)態(tài)的云原生環(huán)境中，基于規(guī)則的方法過于脆弱，維護(hù)成本高且難以擴(kuò)展。

AIOps 是利用大數(shù)據(jù)分析和機(jī)器學(xué)習(xí)等技術(shù)自動(dòng)化IT運(yùn)維流程。AIOps 可以通過大量的日志和性能數(shù)據(jù)處理、系統(tǒng)的環(huán)境配置分析，獲得對(duì)IT系統(tǒng)內(nèi)部和外部的依賴的可見性，增強(qiáng)前瞻性和問題洞察，實(shí)現(xiàn)自治運(yùn)維。

得益于云原生技術(shù)生態(tài)的發(fā)展，AIOps 與 Kubernetes 等技術(shù)將相互促進(jìn)，進(jìn)一步完善企業(yè) IT 的成本優(yōu)化、故障檢測(cè)和集群優(yōu)化等方案。這里面有幾個(gè)重要的助力：

• 可觀測(cè)能力的標(biāo)準(zhǔn)化：隨著云原生技術(shù)社區(qū) Prometheus、OpenTelemetry、OpenMetrics 等項(xiàng)目的發(fā)展，應(yīng)用可觀測(cè)性領(lǐng)域在日志、監(jiān)控、鏈路追蹤等領(lǐng)域進(jìn)一步標(biāo)準(zhǔn)化和融合，使得多指標(biāo)、根因分析的數(shù)據(jù)集更加豐富。Service Mesh 非侵入的數(shù)據(jù)遙測(cè)能力可以在不修改現(xiàn)有應(yīng)用的前提下獲取更加豐富的業(yè)務(wù)指標(biāo)。從而提高 AIOPS 的 AI 層面的準(zhǔn)確率和覆蓋率。
• 應(yīng)用交付管理能力的標(biāo)準(zhǔn)化：Kubernetes 聲明式 API、面向終態(tài)的應(yīng)用交付方式，提供了更加一致的管理運(yùn)維體驗(yàn)。Service Mesh 非侵入的服務(wù)流量管理能力，讓我們可以用透明的方式對(duì)應(yīng)用進(jìn)行管理和自動(dòng)化運(yùn)維。

通過阿里集團(tuán)的 DevOps 平臺(tái)“云效”和容器平臺(tái)發(fā)布變更系統(tǒng)相結(jié)合，可以實(shí)現(xiàn)應(yīng)用的“無人值守發(fā)布”。在發(fā)布過程中，系統(tǒng)持續(xù)收集包括系統(tǒng)數(shù)據(jù)、日志數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)等各種指標(biāo)，并通過算法比對(duì)發(fā)布前后的指標(biāo)異動(dòng)。一旦發(fā)現(xiàn)問題，就可以對(duì)發(fā)布過程進(jìn)行阻斷，甚至自動(dòng)化回滾。有了這項(xiàng)技術(shù)，任何一個(gè)開發(fā)團(tuán)隊(duì)都可以安全的做好發(fā)布工作，而不必?fù)?dān)心線上變更導(dǎo)致的重大故障了。

云原生成本優(yōu)化逐漸受到關(guān)注

隨著企業(yè)將更多核心業(yè)務(wù)從數(shù)據(jù)中心遷移到云上，越來越多的企業(yè)迫切需要對(duì)云上環(huán)境進(jìn)行預(yù)算制定、成本核算和成本優(yōu)化。從固定的財(cái)務(wù)成本模型，轉(zhuǎn)化為變化的、按需付費(fèi)的云財(cái)務(wù)模型，這是一個(gè)重要的觀念和技術(shù)轉(zhuǎn)變。然而大多數(shù)企業(yè)尚未對(duì)云財(cái)務(wù)管理有清晰的認(rèn)知和技術(shù)手段，在 FinOps 2020 年調(diào)研報(bào)告中，將近一半的受訪者（49％）幾乎沒有或沒有自動(dòng)化方法管理云支出。為了幫助組織更好了解云成本和IT收益，FinOps 理念開始流行。

FinOps 是云財(cái)務(wù)管理的方式，是企業(yè) IT 運(yùn)營(yíng)模式的轉(zhuǎn)變，目標(biāo)是提升組織對(duì)云成本的理解和更好地做決策。2020年8月，Linux基金會(huì)宣布成立 FinOps 基金會(huì)，通過最佳實(shí)踐、教育和標(biāo)準(zhǔn)推進(jìn)云財(cái)務(wù)管學(xué)科。目前云廠商開始逐漸加大對(duì) FinOps 的支持，幫助企業(yè)的財(cái)務(wù)流程可以更好適應(yīng)云資源的可變性和動(dòng)態(tài)性。比如 AWS Cost Explorer, 阿里云費(fèi)用中心，可以幫助企業(yè)更好進(jìn)行成本分析和分?jǐn)偂Ｔ斠?#xff1a;https://developer.aliyun.com/article/772964。

越來越多的企業(yè)在云上通過 Kubernetes 平臺(tái)來管理、使用基礎(chǔ)設(shè)施資源。通過容器來提升部署密度和應(yīng)用彈性，從而降低整體計(jì)算成本。但是在 Kubernetes 的動(dòng)態(tài)性為資源計(jì)量和成本分?jǐn)傄胄碌膹?fù)雜性挑戰(zhàn)。
由于多個(gè)容器可以被動(dòng)態(tài)部署在同一個(gè)虛擬機(jī)實(shí)例之上，可以按需彈性伸縮，我們無法簡(jiǎn)單將底層云資源與容器應(yīng)用一一對(duì)應(yīng)。2020年11月，CNCF 基金會(huì)和 FinOps 基金會(huì)發(fā)布了一份新的關(guān)于 Kubernetes 云財(cái)務(wù)管理的白皮書 《FinOps for Kubernetes: Unpacking container cost allocation and optimization》來幫助大家更好理解相關(guān)財(cái)務(wù)管理實(shí)踐。

阿里云容器服務(wù)也在產(chǎn)品中內(nèi)置了很多成本管理和優(yōu)化的最佳實(shí)踐。很多客戶非常關(guān)心如何基于 Kubernetes 和資源彈性實(shí)現(xiàn)成本優(yōu)化，通常我們建議企業(yè)更好了解自己業(yè)務(wù)類型，為 K8s 集群劃分不同的節(jié)點(diǎn)池，在成本、穩(wěn)定性和性能等多維度考量中尋找平衡點(diǎn)。

• 日常業(yè)務(wù)：對(duì)于可預(yù)測(cè)的、相對(duì)不變的負(fù)載，我們可以利用包年包月的裸金屬或者大規(guī)格虛擬機(jī)來提升資源利用率，降低成本。
• 計(jì)劃內(nèi)的短期或周期性業(yè)務(wù)：比如雙十一大促，跨年活動(dòng)等短期業(yè)務(wù)峰值，或者月底結(jié)算等周期性業(yè)務(wù)負(fù)載變化，我們可以利用虛擬機(jī)或者彈性容器實(shí)例來應(yīng)對(duì)業(yè)務(wù)高峰。
• 非預(yù)期的突發(fā)彈性業(yè)務(wù)：比如突發(fā)新聞熱點(diǎn)，或者臨時(shí)的計(jì)算任務(wù)。彈性容器實(shí)例可以輕松實(shí)現(xiàn)每分鐘上千實(shí)例的擴(kuò)容。

更多關(guān)于 Kubernetes 規(guī)劃問題，可以參考：《關(guān)于 Kubernetes 規(guī)劃的靈魂 n 問》。

總結(jié)

過去十年，基礎(chǔ)架構(gòu)上云，互聯(lián)網(wǎng)應(yīng)用架構(gòu)升級(jí)，研發(fā)流程敏捷化幾個(gè)技術(shù)大趨勢(shì)相交匯，與容器、Serverless、服務(wù)網(wǎng)格等技術(shù)創(chuàng)新相結(jié)合，共同催生了云原生的理念誕生和發(fā)展。云原生正在重新定義的計(jì)算基礎(chǔ)設(shè)施、應(yīng)用架構(gòu)和組織流程，是云計(jì)算發(fā)展的歷史的必然。感謝所有一起在云原生時(shí)代的同行者，讓我們共同探索和定義云原生的未來。

片尾彩蛋，本系列三篇文章的名稱向星戰(zhàn)系列致敬，你發(fā)現(xiàn)了嗎？

團(tuán)隊(duì)招聘

阿里云容器服務(wù)團(tuán)隊(duì)招聘啦！歡迎轉(zhuǎn)崗、社招推薦! 一起創(chuàng)造云原生激情澎湃的未來！杭州、北京、深圳均有機(jī)會(huì)哦。簡(jiǎn)歷發(fā)送至：yaowei.cyw@alibaba-inc.com。

一本書了解阿里雙11核心系統(tǒng)全面云原生化過程

點(diǎn)擊免費(fèi)下載《云原生大規(guī)模應(yīng)用落地指南》，從技術(shù)體系升級(jí)、到技術(shù)能力突破、再到大促業(yè)務(wù)實(shí)踐，一本書了解阿里 雙11 核心系統(tǒng)全面云原生化過程！

原文鏈接：https://developer.aliyun.com/article/782176?

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的应云而生，幽灵的威胁 - 云原生应用交付与运维的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。