用戶如何在自己的服務(wù)器上運(yùn)行Azure服務(wù)？

公有云看上去大同小異，都提供相似的服務(wù)并收取相似的費(fèi)用。但由于每家云計(jì)算供應(yīng)商有不同的發(fā)展歷史和自己的專(zhuān)長(zhǎng)，關(guān)注的重點(diǎn)有所不同。對(duì)于微軟公司來(lái)說(shuō)，該公司非常關(guān)注混合云，因?yàn)橛捎跀?shù)據(jù)敏感性或政府監(jiān)管，很多用戶的工作負(fù)載一直在自己的內(nèi)部部署數(shù)據(jù)中心運(yùn)行。

這是一個(gè)雙向的承諾，提供用于快速遷移數(shù)據(jù)和服務(wù)的工具，在內(nèi)部部署數(shù)據(jù)中心資源不足時(shí)使用云平臺(tái)處理非敏感、不受監(jiān)管的數(shù)據(jù)，并將其Azure管理工具引入用戶的數(shù)據(jù)中心，微軟公司在Azure Stack中擁有自己的硬件、使用Azure Stack HCI批準(zhǔn)的第三方硬件或其Azur Arc應(yīng)用程序管理工具。

基于Azure Arc和容器構(gòu)建

Azure Arc的演變一直是人們關(guān)注的焦點(diǎn)。最初是作為通過(guò)Azure門(mén)戶管理內(nèi)部部署應(yīng)用程序虛擬基礎(chǔ)設(shè)施的工具，它增加了對(duì)數(shù)據(jù)服務(wù)和Kubernetes容器編排的支持。這是有趣的選項(xiàng)，因?yàn)樵贏zure自己的Kubernetes管理工具的版本上構(gòu)建是管理Kubernetes環(huán)境的一種快速簡(jiǎn)便的方法，不需要用戶深入了解Kubernetes部署和配置。

除了在自己的硬件上托管自己的云原生應(yīng)用程序之外，Azure Arc的Kubernetes工具還有另外的作用。微軟公司一直在重新構(gòu)建自己的大部分Azure平臺(tái)服務(wù)。雖然這些一直基于微服務(wù)以支持快速橫向擴(kuò)展，但它們已經(jīng)使用微軟公司自己的虛擬化技術(shù)運(yùn)行。這種情況正在慢慢改變，將它們從專(zhuān)用的Windows Server實(shí)例轉(zhuǎn)移到在容器中運(yùn)行，并使用自定義Kubernetes擴(kuò)展和服務(wù)來(lái)支持容器化代碼。

而向容器的轉(zhuǎn)變，以及Kubernetes對(duì)Windows和Linux容器的支持，使微軟公司能夠推廣自己的內(nèi)部Azure托管服務(wù)，使用Kubernetes和相關(guān)技術(shù)來(lái)提高擴(kuò)展性，并使這些容器具有可移植性。人們已經(jīng)在Azure StackEdge硬件上運(yùn)行的Azure IoT Hub中看到了一些這種可移植性，因此需要將計(jì)算能力放在需要的地方，而不是依賴可能有問(wèn)題的網(wǎng)絡(luò)。

下一個(gè)合乎邏輯的步驟是使用Arc的Azure Kubernetes作為主機(jī)，將可移植應(yīng)用程序容器遷移到任何一個(gè)Azure托管平臺(tái)。這種方法允許用戶在代碼所在的位置運(yùn)行Azure服務(wù)，Arc不僅支持內(nèi)部部署系統(tǒng)，還支持AWS或谷歌云平臺(tái)上托管的基礎(chǔ)設(shè)施。如果用戶對(duì)Azure Function有依賴關(guān)系，但希望將其包含在數(shù)據(jù)中心運(yùn)行的應(yīng)用程序中以及Azure和AWS上的多云應(yīng)用程序中，那么現(xiàn)在不局限于將Azure Function的代碼轉(zhuǎn)換為AWS Lambda。

與往常一樣，這種方法是一種權(quán)衡。用戶依賴于Azure Arc，并且需要在其使用的平臺(tái)上進(jìn)行管理。但是，用戶現(xiàn)在只需開(kāi)發(fā)一次應(yīng)用程序代碼，使不同版本和不同平臺(tái)之間沒(méi)有延遲，無(wú)需使用通用API，從而降低風(fēng)險(xiǎn)，并提供盡可能多的多云覆蓋范圍。

設(shè)置Azure Arc的應(yīng)用服務(wù)支持

通過(guò)Azure Arc運(yùn)行應(yīng)用程序服務(wù)需要注冊(cè)的Kubernetes集群。用戶可以在任何平臺(tái)上使用任何正在運(yùn)行的集群，只要它支持集群API，并且已經(jīng)在其Kubernetes系統(tǒng)上安裝了Azure CLI。務(wù)必記住的是，Azure Arc是一種管理在集群上運(yùn)行的應(yīng)用程序的方式，而不是集群本身。Arc的功能與管理平臺(tái)所需的功能之間存在明顯的分界線。用戶可以將其視為基礎(chǔ)設(shè)施管理與平臺(tái)和應(yīng)用程序管理之間的區(qū)別。需要將集群作為基礎(chǔ)設(shè)施的一部分進(jìn)行管理，而Arc處理在Kubernetes中運(yùn)行的平臺(tái)服務(wù)和應(yīng)用程序。

若要連接集群，可以使用connectk8s Azure CLI擴(kuò)展，并確保集群可以連接到所需的Azure端點(diǎn)。在連接到Arc之前，可能需要為此配置防火墻。在連接之后，注冊(cè)Arc提供程序并將其連接到本地區(qū)域的Azure資源組。Azure CLI工具下載并運(yùn)行Helm圖表，該圖表添加了建立連接所需的證書(shū)和ID，為其管理代理部署了一組Pod。

一旦集群由Azure Arc管理，就可以在集群上部署Azure應(yīng)用程序服務(wù)擴(kuò)展。該服務(wù)仍處于試用階段。接下來(lái)需要將應(yīng)用服務(wù)擴(kuò)展安裝到集群，首先設(shè)置內(nèi)部部署環(huán)境變量以保存擴(kuò)展名稱、其命名空間和整個(gè)環(huán)境的名稱。然后可以使用Azure CLI將擴(kuò)展安裝到集群。

微軟公司提供了一個(gè)示例腳本來(lái)安裝和配置應(yīng)用服務(wù)集群和Pod，添加服務(wù)帳戶、命名空間和其他關(guān)鍵配置。其安裝可能需要一些時(shí)間，因此需要耐心等待，然后再配置服務(wù)的Arc端。在這里，用戶將在創(chuàng)建應(yīng)用服務(wù)環(huán)境之前設(shè)置Arc使用的自定義位置。一旦它啟動(dòng)并運(yùn)行，就可以開(kāi)始創(chuàng)建和部署應(yīng)用程序。用戶可以配置對(duì)Kubernetes事件驅(qū)動(dòng)自動(dòng)縮放(KEDA)以及Kubernetes的默認(rèn)資源驅(qū)動(dòng)方法的支持。如果正在運(yùn)行無(wú)服務(wù)器Azure服務(wù)(例如Functions或EventGrid)，那么應(yīng)該會(huì)發(fā)現(xiàn)KEDA支持很有用。

在其開(kāi)發(fā)的現(xiàn)階段，Azure Arc的Azure應(yīng)用服務(wù)支持不適合初學(xué)者。它需要現(xiàn)有的Kubernetes環(huán)境和從命令行管理Kubernetes和Azure的經(jīng)驗(yàn)。微軟公司可以提供指導(dǎo)，但用戶需要自定義腳本以適應(yīng)其環(huán)境，無(wú)論是在內(nèi)部部署設(shè)施還是在公有云上運(yùn)行。

生成代碼并將其交付到Azure Arc應(yīng)用服務(wù)

微軟公司正在推出一種基于向?qū)У姆椒ǎ糜趶腁zure Arc門(mén)戶將服務(wù)部署到連接的集群。這將創(chuàng)建適當(dāng)?shù)馁Y源并安裝適當(dāng)?shù)臄U(kuò)展。然后，用戶可以將其用作部署資源的目標(biāo)，將它們視為Azure區(qū)域旁邊的自定義位置。這使用戶可以使用現(xiàn)有的Azure開(kāi)發(fā)工具(例如Visual Studio Code)來(lái)處理Arc資源。

一旦Azure Arc對(duì)Azure應(yīng)用服務(wù)的支持推出正式版本，它將為用戶提供與直接使用Azure相同的熟悉的開(kāi)發(fā)和操作體驗(yàn)，將其資源視為Azure服務(wù)的替代站點(diǎn)。這意味著確保提前配置它們，賦予Azure管理員新的職責(zé)，并要求在DevOps團(tuán)隊(duì)中建立新的關(guān)系。

由此產(chǎn)生的多云功能利用了Kubernetes的通用API，大多數(shù)版本都支持這些API，從邊緣到公有云。在內(nèi)部部署或Azure中開(kāi)發(fā)的代碼可以在任何受支持的平臺(tái)上運(yùn)行，隨時(shí)可以部署到數(shù)據(jù)所在的位置。隨著越來(lái)越多的Azure服務(wù)利用Azure Arc的Kubernetes支持，對(duì)多平臺(tái)服務(wù)的多云支持將變得與使用跨云虛擬基礎(chǔ)設(shè)施一樣普遍，并且通過(guò)消除基于平臺(tái)即服務(wù)的應(yīng)用程序的單點(diǎn)故障來(lái)提高其可靠性和可用性。