KUBERNETES和邊緣計算，擴展邊緣管理并支持多種需求

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

[[330824]]

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

Edge和Kubernetes入口

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

微服務(wù)架構(gòu)實現(xiàn)了架構(gòu)靈活性。 應(yīng)用程序開發(fā)人員利用這種靈活性來選擇最適合服務(wù)特定要求的編程語言和體系結(jié)構(gòu)。 無論架構(gòu)如何，邊緣都需要支持需要向用戶公開的廣泛功能。 這擴展了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īng)用程序開發(fā)人員在自助服務(wù)模型中公開這些功能。

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

摘要

隨著組織采用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ù)時的重點。 微服務(wù)的組織模型驅(qū)動著邊緣的這些新挑戰(zhàn)，在這種模型中，獨立團隊有權(quán)并負責為微服務(wù)制定正確的體系結(jié)構(gòu)和實施決策。

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