KUBERNETES和邊緣計(jì)算，擴(kuò)展邊緣管理并支持多種需求

使用微服務(wù)模式構(gòu)建應(yīng)用程序并將這些服務(wù)部署到Kubernetes上已成為當(dāng)今運(yùn)行云原生應(yīng)用程序的實(shí)際方法。 在微服務(wù)架構(gòu)中，單個(gè)應(yīng)用程序被分解為多個(gè)微服務(wù)。 每個(gè)微服務(wù)均由一個(gè)小團(tuán)隊(duì)擁有，該團(tuán)隊(duì)有權(quán)并負(fù)責(zé)為特定的微服務(wù)做出正確的決策。

[[330824]]

這種職責(zé)通常從用戶請(qǐng)求到達(dá)的系統(tǒng)邊緣開始，一直到服務(wù)的業(yè)務(wù)邏輯，再到相關(guān)的消息傳遞和數(shù)據(jù)存儲(chǔ)架構(gòu)。

Edge和Kubernetes入口

最終用戶需要訪問微服務(wù)。 內(nèi)部微服務(wù)和最終用戶之間的邊界稱為邊緣。 為了使最終用戶訪問內(nèi)部應(yīng)用程序，流量需要越過邊緣。 在Kubernetes中，流量使用一種稱為入口的軟件穿越邊緣。

將API網(wǎng)關(guān)與在Kubernetes上運(yùn)行的基于微服務(wù)的應(yīng)用程序集成時(shí)，您必須考慮兩個(gè)主要挑戰(zhàn)：

• 如何擴(kuò)展對(duì)100多種服務(wù)和相關(guān)API的管理; 和
• 網(wǎng)關(guān)如何支持通常跨整個(gè)邊緣堆棧的廣泛的微服務(wù)體系結(jié)構(gòu)，協(xié)議和配置。

API網(wǎng)關(guān)：微服務(wù)的聯(lián)絡(luò)點(diǎn)

API網(wǎng)關(guān)是如何管理，保護(hù)和呈現(xiàn)API的核心。 它作為軟件組件(或一系列組件)部署在虛擬機(jī)上或Kubernetes中，并充當(dāng)系統(tǒng)的單個(gè)入口點(diǎn)。 API網(wǎng)關(guān)的主要職責(zé)是使用戶能夠可靠，安全地訪問多個(gè)API，微服務(wù)和后端系統(tǒng)。

微服務(wù)和Kubernetes提供了實(shí)現(xiàn)靈活性。 例如，一個(gè)團(tuán)隊(duì)可以選擇在系統(tǒng)的邊緣(內(nèi)部服務(wù)和最終用戶之間的邊界)公開基于容器的微服務(wù)，作為一組基于HTTP的REST API。 另一個(gè)團(tuán)隊(duì)可能會(huì)選擇Protobufs和gRPC。 有實(shí)時(shí)流需求的團(tuán)隊(duì)可以通過WebSocket API公開其微服務(wù)。 Kubernetes中部署的任何API網(wǎng)關(guān)都必須支持所有這些協(xié)議。

每個(gè)團(tuán)隊(duì)不僅可以自由做出這些選擇，而且對(duì)后果負(fù)責(zé)。 這通常轉(zhuǎn)化為"您構(gòu)建，運(yùn)行"。 盡管并非每個(gè)組織都完全贊同這種工作方式，但是每個(gè)微服務(wù)團(tuán)隊(duì)都需要能夠理解，診斷和配置處理每個(gè)服務(wù)以及每個(gè)用戶對(duì)應(yīng)用程序的請(qǐng)求的各個(gè)方面。 與應(yīng)用程序和API相關(guān)的運(yùn)行時(shí)要求的多樣性意味著，每個(gè)團(tuán)隊(duì)都將使用邊緣堆棧中的所有層，例如，動(dòng)態(tài)請(qǐng)求處理，WAF和任何緩存實(shí)現(xiàn)。

微服務(wù)的開發(fā)范例(獨(dú)立，授權(quán)和負(fù)責(zé)的團(tuán)隊(duì))為使用API網(wǎng)關(guān)，Kubernetes入口和邊緣的微服務(wù)團(tuán)隊(duì)帶來了一系列新挑戰(zhàn)。

在本文中，我們確定了邊緣的兩個(gè)重要挑戰(zhàn)：管理獨(dú)立的微服務(wù)以及訪問全面的邊緣堆棧。

挑戰(zhàn)1：擴(kuò)展邊緣管理

隨著部署的微服務(wù)數(shù)量的增加，管理邊緣的挑戰(zhàn)也越來越多

在微服務(wù)架構(gòu)中，工程師將管理更多的服務(wù)和應(yīng)用程序。 每個(gè)團(tuán)隊(duì)都需要能夠獨(dú)立管理他們的服務(wù)，以使發(fā)布與其他團(tuán)隊(duì)的計(jì)劃脫鉤。 在邊緣公開應(yīng)用程序的傳統(tǒng)方法通常是通過集中的操作或平臺(tái)團(tuán)隊(duì)來完成的。 但是，當(dāng)組織擁有數(shù)百個(gè)微服務(wù)時(shí)，一個(gè)運(yùn)維團(tuán)隊(duì)無法擴(kuò)展以處理必要的變更量。

需要在邊緣修改配置的典型更改：

• 正在部署的服務(wù)的新版本。
• 修改端點(diǎn)，路由指令或關(guān)聯(lián)的后端服務(wù)。
• 身份驗(yàn)證和授權(quán)服務(wù)的更改。
• 修改非功能性需求，例如速率限制，超時(shí)，重試模式和斷路。
• 用戶對(duì)新功能的測(cè)試，例如，為一小部分Beta測(cè)試用戶啟用功能。

采用基于微服務(wù)的體系結(jié)構(gòu)將導(dǎo)致發(fā)行數(shù)量顯著增加。 這種增加只會(huì)加劇邊緣管理方面的挑戰(zhàn)，并增加集中式操作方法的壓力。

挑戰(zhàn)2：支持各種范圍的邊緣要求

微服務(wù)在邊緣引入了許多新問題

微服務(wù)架構(gòu)實(shí)現(xiàn)了架構(gòu)靈活性。 應(yīng)用程序開發(fā)人員利用這種靈活性來選擇最適合服務(wù)特定要求的編程語言和體系結(jié)構(gòu)。 無論架構(gòu)如何，邊緣都需要支持需要向用戶公開的廣泛功能。 這擴(kuò)展了API網(wǎng)關(guān)的傳統(tǒng)角色，并且與邊緣整合工具需求相關(guān)的一些挑戰(zhàn)包括：

• 熟練地路由各種協(xié)議的能力。 常見協(xié)議包括HTTP / 1.1，HTTP / 2，WebSocket，gRPC，gRPC-Web和TCP。
• 提供任何特定服務(wù)所需的完整邊緣功能集合，范圍從流量管理到可觀察性再到身份驗(yàn)證等等。
• 為應(yīng)用程序開發(fā)人員在自助服務(wù)模型中公開這些功能。

鼓勵(lì)微服務(wù)團(tuán)隊(duì)實(shí)施的多樣性使工程師可以選擇"適合工作的工具"。 但是，基礎(chǔ)平臺(tái)的整合提供了許多好處。 與其允許開發(fā)人員構(gòu)建定制的實(shí)現(xiàn)以提供額外的協(xié)議支持或安全處理，不如讓其在邊緣具有預(yù)先批準(zhǔn)的"自助"選項(xiàng)，從而使他們可以選擇最合適的選項(xiàng)，從而更加易于管理和擴(kuò)展。 功能組合。

摘要

隨著組織采用Kubernetes并轉(zhuǎn)向基于微服務(wù)的體系結(jié)構(gòu)，最終用戶與內(nèi)部微服務(wù)之間的邊界出現(xiàn)了一系列新的挑戰(zhàn)。 因此，系統(tǒng)的"邊緣"以及相關(guān)技術(shù)(例如API網(wǎng)關(guān))是采用微服務(wù)時(shí)的重點(diǎn)。 微服務(wù)的組織模型驅(qū)動(dòng)著邊緣的這些新挑戰(zhàn)，在這種模型中，獨(dú)立團(tuán)隊(duì)有權(quán)并負(fù)責(zé)為微服務(wù)制定正確的體系結(jié)構(gòu)和實(shí)施決策。

管理系統(tǒng)邊緣一直很復(fù)雜。 添加具有多種體系結(jié)構(gòu)的更多服務(wù)只會(huì)增加對(duì)邊緣的需求。 平臺(tái)團(tuán)隊(duì)必須相應(yīng)地設(shè)計(jì)，選擇和實(shí)現(xiàn)其API網(wǎng)關(guān)和邊緣工具。