Kubernetes 上 API 網(wǎng)關的未來

關鍵要點

• API 網(wǎng)關已從基本的轉(zhuǎn)換器發(fā)展為適應市場需求的高級云網(wǎng)關，在管理和保護客戶端與后端服務之間的 API 通信中發(fā)揮著關鍵作用。
• 盡管開源的 Kubernetes Gateway API 項目將 API 網(wǎng)關定位為基礎設施中必不可少但可商業(yè)化的一部分，但全周期的 API 管理在推動云原生應用和服務方面仍然至關重要。
• 為了充分發(fā)揮云原生計算的潛力，傳統(tǒng)的 API 管理架構(gòu)必須重新設計，以不僅滿足 Kubernetes 和云原生環(huán)境的要求，而且還要充分利用它們提供的功能。

介紹

隨著互聯(lián)網(wǎng)和云計算的指數(shù)級增長，催生了更小、更分布式的應用程序，這些應用為高度動態(tài)的環(huán)境而設計，能夠根據(jù)需要快速擴展或縮減。這些應用程序推動了對現(xiàn)代 API 管理產(chǎn)品架構(gòu)的需求，這些架構(gòu)可以利用云原生能力實現(xiàn)可伸縮性、彈性、敏捷性和成本效益。與此同時，云原生應用幫助推動 API 網(wǎng)關從簡單轉(zhuǎn)換器發(fā)展為推動數(shù)字化計劃中不可或缺的高級中間件。

與此同時，Kubernetes 已經(jīng)成為現(xiàn)代分布式應用程序首選的開源容器編排系統(tǒng)，無論是部署在一個還是多個公共或私有云上。根據(jù) 2022 年全球 CNCF 調(diào)查^[1]顯示，89% 的 CNCF 最終用戶正在使用或試驗 Kubernetes。Kubernetes Gateway API 項目旨在通過定義聲明性 API 來配置 Kubernetes 集群中的網(wǎng)關和入口點，以促進組織實施該技術。預計這一發(fā)展將使得 API 網(wǎng)關變得更加易于訪問和產(chǎn)品化，盡管完整生命周期的 API 管理仍然對于推動云原生應用程序和服務至關重要。

本文將探討 API 網(wǎng)關如何演變、傳統(tǒng) API 網(wǎng)關在支持 Kubernetes 云原生環(huán)境方面的不足之處、當今的 API 網(wǎng)關需求、為什么 Envoy 是構(gòu)建下一代 API 網(wǎng)關的最佳標準，以及基于 Kubernetes 的 API 管理的未來。

網(wǎng)關的演變

在探討 API 網(wǎng)關是如何演變之前，讓我們快速定義我們所說的 API 管理與 API 網(wǎng)關的含義。API 管理包括策略規(guī)劃、設計、實施到監(jiān)控 API 在其生命周期的每個階段的端到端過程。API 網(wǎng)關是 API 管理基礎設施中的一個專用組件，作為 API 請求的主要入口點，促進客戶端和后端服務之間的通信。

API 網(wǎng)關的演變可以分為九個不同的階段，每個階段都代表了它們能力的進步和變化。這些階段反映了 API 網(wǎng)關為滿足現(xiàn)代應用架構(gòu)和 API 管理的不斷發(fā)展的需求而進行的持續(xù)開發(fā)和適應。

• 早期的網(wǎng)關：作為轉(zhuǎn)換器，使不同的網(wǎng)絡架構(gòu)之間的通信成為可能，并促進了不同系統(tǒng)之間的連接。
• 代理服務器：包括 Apache HTTP Server 和 Squid 在內(nèi)的代理服務器作為網(wǎng)關越來越受歡迎，可以跨多個端點管理流量，并提供緩存、安全和訪問控制等功能。
• 硬件負載均衡器：如 F5 Networks Big-IP，出現(xiàn)是為了優(yōu)化性能并處理隨著應用程序變得更加復雜而增加的用戶需求。
• 軟件負載均衡器：包括 HAProxy，由于其強大的功能、性能和可靠性而成為了流行的選擇。它提供了高級的負載均衡算法、會話持久性、健康檢查和可伸縮性選項，使其非常適合處理大量的 API 流量。
• 應用交付控制器（ADCs）：如 NGINX 和 Citrix ADC 作為優(yōu)化應用性能和確?？蛻舳撕头掌髦g的安全通信的高級網(wǎng)關出現(xiàn)。它們提供負載均衡、安全套接字層(SSL)和傳輸層安全性(TLS)終止、安全性、緩存和流量管理功能。
• SOAP 網(wǎng)關：隨著 SOAP 和 web 服務 API 的并行發(fā)展，支持集成、協(xié)議轉(zhuǎn)換和 SOAP 基礎服務的安全性實施。
• API 網(wǎng)關：隨著 web API 和面向服務的架構(gòu)的崛起，作為訪問 API 的中介并處理如路由、身份驗證、速率限制和轉(zhuǎn)換等任務而演變。它們在保護、監(jiān)控和管理 API 流量中發(fā)揮著至關重要的作用，其中一些利用了 Netty 網(wǎng)絡框架。API 網(wǎng)關進一步演變，以處理微服務架構(gòu)中通信和路由的復雜性，與服務發(fā)現(xiàn)機制集成，實現(xiàn)動態(tài)路由、負載均衡和協(xié)議轉(zhuǎn)換。
• 微網(wǎng)關：隨著微服務、邊緣計算和物聯(lián)網(wǎng)的崛起，越來越多地在網(wǎng)絡邊緣使用。它們將處理能力和連接性帶到數(shù)據(jù)源附近，減少延遲和擁塞，同時實現(xiàn)數(shù)據(jù)聚合、本地處理和安全性實施。它們還促進了 IoT 設備與后端系統(tǒng)之間的通信。
• 云原生 API 網(wǎng)關：云原生 API 網(wǎng)關的出現(xiàn)是為了管理云原生環(huán)境中的流量，利用 Kubernetes 等容器編排平臺并采用云原生原則來實現(xiàn)可擴展性和彈性在云原生環(huán)境中，網(wǎng)關越來越多地結(jié)合人工智能和機器學習技術。

API 網(wǎng)關的角色

在當今的技術環(huán)境中，API 網(wǎng)關的角色已經(jīng)受到了其演變的顯著影響。目前，API 網(wǎng)關作為 API 管理的核心，充當 API 請求的入口點，抽象出各種服務的服務質(zhì)量(QoS)問題。它集成了各種 QoS 功能，包括安全性、速率限制、消息轉(zhuǎn)換、請求路由、緩存和 API 洞察，以確保 API 請求的全面管理。

API 安全性至關重要，身份驗證和授權(quán)起著關鍵作用。身份驗證方法，如雙向 TLS (mTLS)、Open Authorization (OAuth) 2.0 Tokens 和 API 密鑰，以及通過授權(quán)范圍進行的細粒度訪問控制，增強了安全性。

API 速率限制確保用戶遵循定義的策略公平使用。它防止濫用，保持一致的服務質(zhì)量，并在 API 管理中促進透明度和責任。

緩存為 API 驅(qū)動的應用程序提供了顯著的好處。通過減少后端負載、最小化延遲、優(yōu)化帶寬使用和提供對后端故障的彈性，它增強了性能、可伸縮性和彈性。

消息轉(zhuǎn)換功能允許用戶修改 API 請求，但在 API 網(wǎng)關上直接實施大量轉(zhuǎn)換可能會影響性能。最佳實踐是使用專為復雜消息轉(zhuǎn)換設計的集成層。

請求路由涉及根據(jù)定義的規(guī)則和配置將傳入的 API 請求引導到適當?shù)暮蠖朔?，同時還結(jié)合了服務負載均衡、故障轉(zhuǎn)移機制和 A/B 測試。

API 洞察通過收集和發(fā)布數(shù)據(jù)進行分析和可視化，提供業(yè)務智能。

監(jiān)控和可觀察性涉及數(shù)據(jù)收集和分析，以獲得 API 性能、可用性和使用情況的洞察。這些功能允許組織跟蹤指標、檢測異常并解決問題，確保 API 網(wǎng)關和底層 API 基礎設施的高效運行和持續(xù)改進。

現(xiàn)代 API 網(wǎng)關不僅支持 REST 服務，還包括對 GraphQL 服務、gRPC 服務和各種流服務的支持。每種類型的 API 從 API 網(wǎng)關獲得不同的 QoS 處理。部署模式包括集中式模式，其中所有 API 一起進行縮放，以及分布式模式。API 管理器控制平面管理部署在不同環(huán)境中的網(wǎng)關，提供集中化的控制和配置。

云原生環(huán)境中的 API 管理

Kubernetes 的采用推動了 API 網(wǎng)關的廣泛使用，因為組織利用了容器化和微服務架構(gòu)的好處。API 網(wǎng)關在基于 Kubernetes 的環(huán)境中實現(xiàn)了高效的 API 管理、可伸縮性和安全性，使其成為現(xiàn)代應用開發(fā)和部署中的關鍵組件。

在使用傳統(tǒng)的 API 管理 Kubernetes 時存在的缺陷

盡管它們被廣泛使用，但傳統(tǒng)的 API 管理架構(gòu)并不適合 Kubernetes 和其他云原生環(huán)境。它們具有將多個功能捆綁在一個應用程序中的單一設計。這使得難以獨立縮放各個組件，相反，必須將整個應用程序一起縮放，這會浪費資源，并在處理高流量或增加的工作負載時導致性能問題。

傳統(tǒng)的 API 管理架構(gòu)還依賴于與云原生環(huán)境不兼容的特定基礎設施組件和技術。它們不僅具有更大的內(nèi)存占用和更長的服務器啟動時間；它們可能還需要專用硬件、特定軟件配置或?qū)Ｓ薪鉀Q方案。這限制了它們利用云平臺的優(yōu)勢，包括自動擴展、基礎設施即代碼實踐和多云部署。由于 API 管理架構(gòu)中存在一些外部依賴關系，API 網(wǎng)關在支持云原生應用程序方面也面臨類似挑戰(zhàn)。為了克服這些挑戰(zhàn)并滿足當前和未來云原生環(huán)境的需求，需要重新設計 API 網(wǎng)關。

Envoy 代理：重構(gòu) API 網(wǎng)關的關鍵

Envoy^[2] 已經(jīng)成為重構(gòu) API 網(wǎng)關的首選解決方案，因為這個開源的邊緣和服務代理專為云原生應用設計。此外，其適應性、可擴展性和強大的安全功能使其成為在各種云環(huán)境中管理 API 流量的絕佳選擇。作為一個開源解決方案，Envoy 從全球的開發(fā)者那里獲得了持續(xù)的改進，他們?yōu)榇硖峁┝诵鹿δ堋⒃鰪姽δ芎湾e誤修復，進一步增強了代理的健壯性和可靠性。

從 API 管理的角度看，Envoy 提供了如限速、響應緩存、CORS 處理、請求認證和授權(quán)等關鍵功能。它支持同時暴露 REST 和 gRPC 服務，并與 AWS 進行直接集成，以暴露 AWS Lambda 函數(shù)。該代理還提供了內(nèi)置的可觀察性功能，與開放遙測無縫集成，為監(jiān)控和調(diào)試提供了全面的指標和跟蹤數(shù)據(jù)。Envoy 代理使用 xDS API 進行配置，這些 API 允許動態(tài)配置、服務發(fā)現(xiàn)、流量路由和代理的運行時控制。通過利用 xDS API，Envoy 可以輕松地進行設置和修改，以滿足不斷變化的需求。

Envoy 代理主要采用兩種部署模式：邊車代理模式和前端代理模式。在邊車代理模式中，Envoy 作為 SOA 架構(gòu)中內(nèi)部流量的通信總線。它通常用作服務網(wǎng)格中的邊車，管理網(wǎng)絡流量并與其代理的服務并行。Envoy 的輕量級核心和強大的功能，如負載均衡和服務發(fā)現(xiàn)，使其成為 Istio 等服務網(wǎng)格實現(xiàn)的熱門選擇。

在前端代理模式中，Envoy 在 Kubernetes Ingress 控制器中使用，將服務暴露給外部消費者。一些 Ingress 控制器是基于 Envoy 構(gòu)建的，利用其核心功能。Envoy 的靈活配置模型和功能集也使其成為 API 網(wǎng)關的理想選擇。大多數(shù)現(xiàn)代 API 網(wǎng)關都是基于 Envoy 代理構(gòu)建的，該代理作為基本框架。

云原生 API 管理架構(gòu)

基于 Envoy 代理的 API 網(wǎng)關在增強整體 API 管理架構(gòu)中起到了關鍵作用，因為它們利用了云原生技術來有效地管理 API，同時確保了可擴展性和彈性。在這里，API 管理架構(gòu)基于微服務原則、容器化和使用 Kubernetes 的容器編排，為云原生環(huán)境中的高效 API 管理提供了基礎設施。

云原生 API 管理架構(gòu)包括兩個獨特的平面：控制平面和數(shù)據(jù)平面。控制平面是命令中心，執(zhí)行 API 管理任務和 API 密鑰生成。數(shù)據(jù)平面作為 API 調(diào)用的網(wǎng)關，將創(chuàng)建的 API 暴露給公共或私有消費者。該架構(gòu)設計為高度可擴展，允許單個控制平面管理多個數(shù)據(jù)平面。這使得無縫的 API 網(wǎng)關聯(lián)邦成為可能，并促進了跨多個云提供商或本地數(shù)據(jù)中心的 API 管理。為了增強可擴展性和彈性，該架構(gòu)利用了 Kubernetes 的基本功能，如自動縮放和自我修復，以確保最佳性能和可靠性。

Envoy 網(wǎng)關項目與 API 標準化

在 2022 年，Envoy 的創(chuàng)建者 Matt Klein 推出了一個名為 Envoy Gateway^[3] 的新項目，專門針對 API 網(wǎng)關。Envoy 已經(jīng)具備了構(gòu)建 API 網(wǎng)關所需的組件，包括代理層；用于網(wǎng)絡流量過濾、路由和處理的可配置過濾器架構(gòu)；以及用于向 Envoy 代理傳輸數(shù)據(jù)的 xDS API。開源的 Envoy 網(wǎng)關項目增加了一個管理層，用于處理 Envoy 代理作為獨立網(wǎng)關或作為 Kubernetes 管理的 API 網(wǎng)關。

該項目的目標是提供一個簡化的 API 層和部署模型，專注于更簡單的用例。它還旨在將各種 CNCF API 網(wǎng)關項目整合到一個公共核心中，使供應商能夠在 Envoy 和 Envoy Gateway 之上構(gòu)建增值解決方案。通過促進社區(qū)合作，該項目還旨在消除在開發(fā)基本 API 網(wǎng)關功能方面的重復努力，使供應商能夠更加專注于 API 管理功能。這種統(tǒng)一努力有可能提高效率并鼓勵 API 網(wǎng)關領域的創(chuàng)新。

Envoy 網(wǎng)關項目主要基于 Kubernetes Gateway API^[4]，該 API 定義了如何將 Kubernetes 服務暴露給外部世界。它利用 Kubernetes CRD 定義，如 GatewayClass、Gateway、HTTPRoute、TCPRoute 等來配置 API 網(wǎng)關。CRD 描述了諸如流量分割、請求路由、重定向、重寫和 TLS 處理等重要功能。此外，還可以將各種策略與 API 網(wǎng)關或特定 API 路徑關聯(lián)。

通過采用 Kubernetes Gateway API 作為基礎，供應商可以靈活地在其首選的技術棧上開發(fā)自己的實現(xiàn)，并且可以利用 API 規(guī)范提供的擴展點來包含供應商特定的功能。這種方法促進了共享、標準化的 API 規(guī)范的采用，從而促進了 API 網(wǎng)關之間的互操作性，提高了 API 網(wǎng)關的一致性，并為未來的創(chuàng)新打開了新的可能性。

Kubernetes 上的 API 管理的未來

API 管理在動態(tài)的 API 環(huán)境中起著至關重要的作用，隨著 API 標準化的推進，API 網(wǎng)關將成為基礎設施的基本元素。這一變化將使開發(fā)人員免于直接管理網(wǎng)關及其相關的復雜性，使他們可以將注意力集中在構(gòu)建和維護 API 以及其他核心開發(fā)任務上。因此，重點轉(zhuǎn)向 API 管理，該管理涵蓋了一系列基本功能。

• API 生命周期管理使 API 的生命周期得以規(guī)劃，允許自定義事件和生命周期變更的利益相關者授權(quán)。
• API 治理建立了流程和政策，以確保有效的 API 開發(fā)、管理，并符合組織目標和標準。
• API 市場作為一個在線平臺，供開發(fā)人員發(fā)現(xiàn)、訪問和管理 API。它提供文檔、目錄、SDK、測試工具、社區(qū)支持和貨幣化選項。
• API 版本管理涉及管理不同的 API 版本，以適應變化，同時保持向后兼容性。
• API 產(chǎn)品化將 API 視為可銷售的產(chǎn)品，應用產(chǎn)品管理原則以滿足開發(fā)者和業(yè)務需求。這包括創(chuàng)建用戶友好的體驗和實施貨幣化策略。
• API 洞察提供有價值的信息，通過分析使用情況、性能和行為，使得可以進行數(shù)據(jù)驅(qū)動的決策，以增強 API 體驗。

為了充分利用云原生生態(tài)系統(tǒng)的優(yōu)勢，許多這些功能都需要重新設計。這將涉及與 Kubernetes 上可用的各種第三方服務的無縫集成，以實現(xiàn)更全面和強大的 API 管理解決方案。

此外，采用開源分發(fā)模式對企業(yè)來說將是一個關鍵因素。開源產(chǎn)品鼓勵社區(qū)參與和適應，促進生態(tài)系統(tǒng)內(nèi)的合作與創(chuàng)新。擁抱開源還確保了 API 管理解決方案能夠從多元化社區(qū)的集體知識和貢獻中受益，從而實現(xiàn)持續(xù)改進和演進。

單一控制平面的 API 網(wǎng)關

API 標準化將 API 網(wǎng)關轉(zhuǎn)化為一種商品，為包含 API 管理和發(fā)現(xiàn)的統(tǒng)一控制平面鋪平了道路。與此同時，數(shù)據(jù)平面可以由來自不同供應商的一個或多個 API 網(wǎng)關實現(xiàn)組成。這種范式轉(zhuǎn)變帶來了許多含義和機會。

• 供應商中立性和靈活性：通過使用能夠管理來自不同供應商的多個網(wǎng)關的單一控制平面，組織實現(xiàn)了供應商中立性和增強的靈活性。這使他們能夠為每個獨特的用例或環(huán)境選擇最合適的網(wǎng)關解決方案。通過接受多個供應商，組織可以利用不同供應商提供的特定優(yōu)勢和優(yōu)點，避免供應商鎖定，并培育一個更加適應的生態(tài)系統(tǒng)。

• 互操作性和標準化：采用單一控制平面促進了不同網(wǎng)關之間的互操作性和標準化。通過遵循共享的 API、協(xié)議和數(shù)據(jù)格式，控制平面使來自不同供應商的網(wǎng)關能夠進行無縫通信和管理。這促進了配置、策略和安全措施的一致性，從而提高了 API 基礎設施的穩(wěn)定性和可靠性。

• 生態(tài)系統(tǒng)擴展和創(chuàng)新：單一控制平面管理來自多個供應商的網(wǎng)關，促進了多樣化的生態(tài)系統(tǒng)并刺激了創(chuàng)新。它使組織能夠接受和整合來自新興供應商的新網(wǎng)關解決方案，而不會對現(xiàn)有基礎設施造成中斷。這種健康的供應商之間的競爭驅(qū)動了創(chuàng)新，擴展了可用選項的范圍，并使組織能夠使用更廣泛的尖端解決方案來滿足其 API 管理需求。

• 成本優(yōu)化：單一控制平面管理來自不同供應商的網(wǎng)關，使組織有靈活性選擇與其特定要求和預算考慮相一致的經(jīng)濟有效的網(wǎng)關解決方案。這種自由使企業(yè)能夠優(yōu)化其支出，從其 API 管理基礎設施中提取最大價值，并做出與其特定需求相一致的明智決策。

• 簡化的管理和操作：組織可以集中配置、監(jiān)控和控制其 API 網(wǎng)關，消除了單獨管理不同網(wǎng)關的復雜性。這種集中化方法提高了管理效率，簡化了操作，并最大限度地減少了潛在的不一致性。由于網(wǎng)關遵循相同的 API 標準化，因此在 API 網(wǎng)關解決方案之間進行遷移變得更加容易。這簡化了從一個網(wǎng)關解決方案過渡到另一個網(wǎng)關解決方案的過程，確保了對現(xiàn)有基礎設施的平滑整合和減少了潛在的中斷。

總之，當 API 網(wǎng)關成為一種商品，并且單一控制平面管理來自不同供應商的多個網(wǎng)關時，團隊將獲得供應商中立性、簡化的管理、更大的互操作性、成本優(yōu)化、增強的安全性和更容易的生態(tài)系統(tǒng)擴展的好處。這種匯聚還將使企業(yè)能夠利用不同網(wǎng)關解決方案的優(yōu)勢，簡化操作，推動創(chuàng)新，并優(yōu)化其 API 管理的實踐。

原文地址：https://wso2.com/library/blogs/the-future-of-api-gateways-on-kubernetes/

參考資料