此參考架構會顯示部署至 Azure Kubernetes Service （AKS） 的微服務應用程式。 它描述基本 AKS 組態，可供您作為大部分部署的起點。 本文假設您已對 Kubernetes 有基本的瞭解。 本文主要強調如何在 AKS 上管理微服務的基礎結構和 DevOps 層面。 如需如何設計微服務的詳細資訊，請參閱 微服務架構設計。
GitHub 架構
Helm 是雲端原生運算基金會 （NCF） 的商標。 使用此標記時不會隱含任何背書。
下載此架構的 Visio 檔案。
如果您要檢視以 AKS 基準架構為基礎的更進階微服務範例，請參閱 進階 AKS 微服務架構。
工作流程
此要求流程會實作 發行者訂閱者、競爭取用者，以及 網關路由 雲端設計模式。
下列數據流對應至上圖：
用戶端應用程式會透過 HTTPS 將 JSON 承載傳送至負載平衡器（受控輸入控制器）的公用完整功能變數名稱，以排程無人機取貨。
Managed 輸入控制器會將要求路由傳送至擷取微服務。
擷取微服務會處理 Azure 服務總線佇列中的要求和佇列傳遞要求。
工作流程微服務：
從 服務匯流排 消息佇列取用訊息資訊。
將 HTTPS 要求傳送至傳遞微服務，以將數據傳遞至 Azure Cache for Redis 中的外部資料記憶體。
將 HTTPS 要求傳送至無人機排程器微服務。
將 HTTPS 要求傳送至套件微服務，以將數據傳遞至 MongoDB 中的外部資料記憶體。
HTTPS GET 要求會傳回傳遞狀態。 此要求會透過受控輸入控制器傳遞至傳遞微服務。 然後傳遞微服務會從 Azure Cache for Redis 讀取數據。
如需範例微服務應用程式的詳細資訊，請參閱 微服務參考實作範例。
元件
AKS 是 Azure 雲端中裝載的受控 Kubernetes 叢集。 AKS 藉由將大部分責任卸除至 Azure，以減少管理 Kubernetes 的複雜度和作業額外負荷。
輸入伺服器 會將 HTTP（S） 路由公開至叢集內的服務。 參考實作會透過應用程式路由附加元件，使用 受控 NGINX 型輸入控制器。 輸入控制器會實作微服務的 API 閘道 模式。
外部數據存放區，例如 Azure SQL Database 或 Azure Cosmos DB，是由無狀態微服務用來寫入其數據和其他狀態資訊。 參考實作會使用 Azure Cosmos DB、Azure Cache for Redis、適用於 MongoDB 的 Azure Cosmos DB，以及 服務總線 作為數據存放區或儲存狀態的位置。
AKS 叢集需要 Microsoft Entra ID。 它提供 受控識別，用來存取 Azure Container Registry，以及存取和布建 Azure 資源，例如負載平衡器和受控磁碟。 在 AKS 叢集上部署的工作負載也需要Microsoft Entra 中的身分識別，才能存取 Microsoft受 Entra 保護的資源，例如 Azure Key Vault 和 Microsoft Graph。 在此參考架構中，Microsoft Entra 工作負載標識碼 與 Kubernetes 整合，並提供具有身分識別的工作負載。 您也可以針對每個工作負載使用受控識別或應用程式認證。
Container Registry 可用來儲存部署至叢集的私人容器映射。 AKS 可以使用其Microsoft Entra 身分識別向 Container Registry 進行驗證。 在參考實作中，微服務容器映射會建置並推送至 Container Registry。
Azure Pipelines 是 Azure DevOps 套件的一部分，並執行自動化建置、測試和部署。 微服務環境中強烈建議 持續整合和持續部署 （CI/CD） 方法。 各種小組可以使用 Azure Pipelines 獨立建置和部署微服務至 AKS。
Helm 是 Kubernetes 的套件管理員，可提供一種機制，將 Kubernetes 物件組合和標準化成單一單位，可發佈、部署、版本設定和更新。
Azure 監視器 收集及儲存 Azure 服務的計量和記錄、應用程式遙測和平臺計量。 Azure 監視器會與 AKS 整合，以從控制器、節點和容器收集計量。
Application Insights 監視微服務和容器。 它可用來提供微服務的可觀察性，其中包括流量流程、端對端延遲和錯誤百分比。 微服務的健康情況及其之間的關聯性可以在單一應用程式對應上顯示。
替代選擇
Azure Container Apps 提供受控無伺服器 Kubernetes 體驗。 當您不需要直接存取 Kubernetes 或其 API，且不需要控制叢集基礎結構時，它可作為裝載微服務的更簡單替代方案。
您可以使用容器的應用程式閘道、Istio 輸入閘道或非Microsoft解決方案等替代專案，而不是 AKS 中的受控輸入閘道。 如需詳細資訊，請參閱在 AKS 中輸入。
您可以將容器映像儲存在非Microsoft容器登錄中，例如 Docker Hub。
對於需要維護狀態資訊的微服務，Dapr 提供用於管理微服務狀態的抽象層。
您可以使用 GitHub Actions 來建置和部署微服務，或選擇非Microsoft CI/CD 解決方案，例如 Jenkins。
您可以使用 Kiali等替代工具達成微服務可觀察性。
案例詳細資料
微服務參考實作範例 實作本文所述的架構元件和作法。 在此範例中，一家名為 Fabrikam， Inc.的虛構公司會管理無人機機隊。 企業會註冊此服務，而使用者可要求無人機收取貨物進行遞送。 當客戶排程取貨時，後端系統會指派無人機，並通知用戶預估的遞送時間。 當交付正在進行時，客戶可以使用持續更新的預估交貨時間來追蹤無人機的位置。
此案例旨在示範 AKS 中的微服務架構和部署最佳做法。
潛在的使用案例
從案例採用下列最佳做法，在 AKS 中建構複雜的微服務型應用程式：
- 複雜的 Web 應用程式
- 使用微服務設計原則所開發的商業規則
考量
這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework。
設計
此參考架構著重於微服務，但許多建議的做法適用於在AKS上執行的其他工作負載。
微服務
微服務是鬆散結合、獨立部署的程式代碼單位。 微服務通常會透過定義完善的 API 進行通訊，而且可透過某種形式的服務探索來探索。 Kubernetes 服務物件是在 Kubernetes 中建立微服務模型的典型方式。
資料存放區
在微服務架構中，服務不應該共用數據儲存解決方案。 每個服務都應該管理自己的數據集，以避免服務之間的隱藏相依性。 數據區隔有助於避免服務之間的非預期結合。 當服務共用相同的基礎數據架構時，可能會發生此程式。 當服務管理自己的數據存放區時，他們可以使用正確的數據存放區來符合其特定需求。 如需詳細資訊，請參閱 微服務的數據考慮。
避免將持續性數據儲存在本機叢集記憶體中，因為該方法會將數據系結至節點。 請改用外部服務，例如 SQL Database 或 Azure Cosmos DB。 另一個選項是使用 Azure 磁碟記憶體或 Azure 檔案記憶體將永續性數據磁碟區掛接至解決方案。 如需詳細資訊，請參閱 AKS 中的應用程式適用的儲存體選項。
API 閘道
API 閘道是一般 微服務設計模式。 API 閘道位於外部用戶端與微服務之間。 網關可作為反向 Proxy，並將要求從用戶端路由傳送至微服務。 API 閘道也可能執行各種跨領域工作，例如驗證、安全套接字層 （SSL） 終止和速率限制。 如需詳細資訊，請參閱下列資源：
在 Kubernetes 中，輸入控制器主要處理 API 閘道的功能。 輸入與輸入控制器會搭配下列項目運作：
將用戶端要求路由至正確的後端微服務。 此路由會為用戶端提供單一端點，並協助將客戶端與服務分離。
將多個要求匯總成單一要求，以減少用戶端與後端之間的閒聊。
從後端服務卸除功能，例如 SSL 終止、驗證、IP 位址限制或用戶端速率限制（稱為 節流）。
反向 Proxy 有輸入控制器，包括 NGINX、HAProxy、Traefik 和 Azure 應用程式閘道。 AKS 提供多個受控輸入選項。 您可以從 受控 NGINX 型輸入控制器中選擇， 透過適用於容器的應用程式路由附加元件應用程式閘道。 或者，您可以選擇 Istio 輸入閘道作為輸入控制器。 如需詳細資訊，請參閱在 AKS 中輸入。
Kubernetes 對象的輸入資源已由更進階且多功能的 Kubernetes 閘道 API 所取代。 輸入控制器和閘道 API 都是用於流量管理路由和負載平衡的 Kubernetes 物件。 網關 API 設計為一般、具表達性、可延伸和角色導向，是一組現代化 API，可用來定義 Kubernetes 中的 L4 和 L7 路由規則。
輸入控制器會以邊緣路由器或反向 Proxy 的形式運作。 反向 Proxy 伺服器是潛在的瓶頸或單一失敗點，因此我們建議您部署至少兩個複本，以協助確保高可用性。
選擇輸入控制器或閘道 API 的時機
輸入資源適用於下列使用案例：
輸入控制器很容易設定，而且適合較小型且較不複雜的 Kubernetes 部署，可優先設定容易設定。
如果您目前已在 Kubernetes 叢集中設定輸入控制器，且它們符合您的需求，可能不需要立即轉換至 Kubernetes 閘道 API。
您應該使用閘道 API：
當您處理複雜的路由設定、流量分割和進階流量管理策略時。 Kubernetes 閘道 API 的路由資源所提供的彈性至關重要。
如果網路需求需要自定義解決方案或非Microsoft外掛程式的整合。 以自訂資源定義為基礎的 Kubernetes 閘道 API 方法可以提供增強的擴充性。
可靠性
可靠性可確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性的設計檢閱檢查清單。
分割微服務
使用命名空間來組織叢集中的服務。 Kubernetes 叢集中的每個物件都屬於命名空間。 最好使用命名空間來組織叢集中的資源。
命名空間有助於防止命名衝突。 當多個小組將微服務部署到相同的叢集中時，如果微服務全都進入相同的命名空間，則很難管理微服務。 命名空間也可讓您：
將資源條件約束套用至命名空間，讓指派給該命名空間的 Pod 總數不能超過命名空間的資源配額。
在命名空間層級套用原則，包括角色型訪問控制 （RBAC） 和安全策略。
當多個小組開發及部署微服務時，您可以使用命名空間作為方便的機制來控制每個小組可以部署的區域。 例如，開發小組 A 只能獲得命名空間 A 的存取權，而開發小組 B 只能透過 Kubernetes RBAC 原則來存取命名空間 B。
針對微服務架構，請考慮將微服務組織成限定內容，併為每個限定內容建立命名空間。 例如，與「訂單履行」限定內容相關的所有微服務都可以進入相同的命名空間。 或者，為每個開發小組建立命名空間。
將公用程式服務放入自己的個別命名空間。 例如，您可以將 Elasticsearch 和 Prometheus 等叢集監視工具部署到監視命名空間。
健康情況探查
Kubernetes 定義 Pod 可以公開的三種健康情況探查類型：
整備探查： 告訴 Kubernetes Pod 是否準備好接受要求。
Liveness 探查： 告訴 Kubernetes 是否應該移除 Pod 並啟動新的實例。
啟動探查： 告訴 Kubernetes 是否已啟動 Pod。
當您考慮探查時，請務必記住服務在 Kubernetes 中的運作方式。 服務具有符合一組零個或多個 Pod 的標籤選取器。 Kubernetes 會將流量平衡到符合選取器之 Pod 的流量。 只有成功啟動且狀況良好的 Pod 才會接收流量。 如果容器當機，Kubernetes 會終止 Pod 並排程取代。
有時 Pod 可能尚未準備好接收流量，即使它已成功啟動也一樣。 例如，可能會進行初始化工作，例如當容器中執行的應用程式將數據載入記憶體或讀取組態檔時。 您可以針對這些緩慢啟動的容器使用啟動探查。 這種方法有助於防止 Kubernetes 在有機會完全初始化之前終止它們。
Liveness 探查可用來檢查 Pod 是否正在執行，但無法正常運作，且需要重新啟動。 例如，如果容器正在處理 HTTP 要求，但突然停止回應而不當機，即時性探查會偵測此事件並觸發 Pod 重新啟動。 如果您設定活躍度探查，它會注意到容器沒有回應時，並提示 Kubernetes 在容器重複失敗探查時重新啟動 Pod。
設計微服務探查時，請考慮下列幾點。
如果您的程式代碼有很長的啟動時間，則啟動完成之前，活躍度探查報告失敗有危險。 若要延遲活躍度探查的開始，請使用啟動探查，或使用具有活躍度探查的
initialDelaySeconds設定。只有在重新啟動Pod可能會將Pod還原為狀況良好的狀態時，才會協助進行活躍度探查。 您可以使用活躍度探查來減輕記憶體流失或非預期的死結，但沒有理由重新啟動 Pod，而 Pod 將會再次失敗。
有時候會使用整備探查來檢查相依服務。 例如，如果 Pod 相依於資料庫，探查可能會檢查資料庫連線。 不過，此方法可能會造成非預期的問題。 外部服務可能暫時無法使用。 此無法使用會導致服務中所有 Pod 的整備探查失敗，導致其從負載平衡中移除。 此移除會建立上游的級聯失敗。
更好的方法是在您的服務內實作重試處理，讓您的服務能夠正確地從暫時性失敗中復原。 或者，Istio 服務網格 可以實作重試處理、容錯和斷路器，以建立可處理微服務失敗的復原架構。
資源限制
資源爭用可能會影響服務的可用性。 定義容器 資源條件約束，讓單一容器無法壓倒叢集資源，例如記憶體和 CPU。 針對非容器資源，例如線程或網路連線，請考慮使用 Bulkhead 模式來隔離資源。
使用 資源配額 來限制命名空間所允許的資源總數。 這項限制可確保前端無法耗盡資源的後端服務，反之亦然。 資源配額可協助將相同叢集中的資源配置給多個微服務開發小組。
安全性
安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 如需詳細資訊，請參閱 安全性的設計檢閱檢查清單。
TLS 和 SSL 加密
在許多實作中，輸入控制器會用於 SSL 終止。 在部署輸入控制器時，您必須建立或匯入傳輸層安全性 （TLS） 憑證。 僅針對開發和測試目的使用自我簽署憑證。 如需詳細資訊，請參閱 使用應用程式路由附加元件設定自定義功能變數名稱和 SSL 憑證。
針對生產工作負載，請從受信任的證書頒發機構單位取得已簽署的憑證。
根據組織的原則，您可能也需要輪替憑證。 您可以使用 Key Vault 來輪替微服務使用的憑證。 如需詳細資訊，請參閱 在 Key Vault 中設定憑證自動輪替。
RBAC
當多個小組同時開發和部署微服務時，AKS RBAC 機制可以提供使用者動作的細微控制和篩選。 您可以使用 Kubernetes RBAC 或 Azure RBAC 搭配 Microsoft Entra ID 來控制叢集資源的存取。 如需詳細資訊，請參閱 AKS的存取和身分識別選項。
驗證和授權
微服務可以要求取用的服務或使用者使用憑證、認證和 RBAC 機制來驗證和授權微服務的存取權。 Microsoft Entra 識別碼可用來實作 OAuth 2.0 令牌以進行授權。 Istio 等服務網格也提供微服務的授權和驗證機制，其中包括 OAuth 令牌驗證和令牌型路由。 參考實作未涵蓋微服務驗證和授權案例。
秘密管理和應用程式認證
應用程式和服務通常需要認證，讓它們能夠連線到外部服務，例如 Azure 儲存體 或 SQL 資料庫。 挑戰在於確保這些認證安全，而不會洩漏認證。
針對 Azure 資源，請盡可能使用受控識別。 受控識別就像是儲存在 entra ID Microsoft 的應用程式或服務的唯一標識符。 它會使用此身分識別向 Azure 服務進行驗證。 應用程式或服務在 Microsoft Entra 識別符中建立服務主體，並使用 OAuth 2.0 令牌進行驗證。 在進程內執行的程式代碼可以透明地取得令牌。 這種方法有助於確保您不需要儲存任何密碼或連接字串。 若要使用受控識別，您可以使用 Microsoft Entra Workload ID，將Microsoft Entra 身分識別指派給 AKS 中的個別 Pod。
即使您使用受控識別，您仍然需要儲存某些認證或其他應用程式秘密。 對於不支援受控識別、非Microsoft服務或 API 金鑰的 Azure 服務而言，此記憶體是必要的。 您可以使用下列選項，協助更安全地儲存秘密：
Key Vault： 在 AKS 中，您可以將一或多個秘密從 Key Vault 掛接為磁碟區。 磁碟區會從 金鑰保存庫 讀取秘密。 然後Pod可以讀取秘密，例如一般磁碟區。 如需詳細資訊，請參閱 在AKS叢集中使用密鑰保存庫提供者將 CSI 驅動程式儲存在 AKS 叢集中。 Pod 會使用工作負載身分識別或用戶或系統指派的受控識別來驗證自己。 如需詳細資訊，請參閱 將 Azure 身分識別提供者連線至 Azure Kubernetes Service （AKS） 中的 Key Vault 秘密存放區 CSI 驅動程式。
HashiCorp Vault： Microsoft Entra 受控識別可讓 Kubernetes 應用程式向 HashiCorp Vault 進行驗證。 您可以 將儲存庫部署至 Kubernetes。 請考慮在與應用程式叢集不同的專用叢集中執行它。
Kubernetes 秘密： 另一個選項是使用 Kubernetes 秘密。 此選項是最容易設定但最不安全的選項。 秘密會儲存在etcd中，這是分散式索引鍵/值存放區。 AKS 會在待用時加密 etcd。 Microsoft管理加密金鑰。
使用 Key Vault 之類的解決方案提供數個優點，包括：
- 集中控制秘密。
- 協助確保所有秘密都會在待用時加密。
- 集中式金鑰管理。
- 秘密的訪問控制。
- 金鑰生命週期管理。
- 審計。
參考實作會將 Azure Cosmos DB 連接字串和其他秘密儲存在 Key Vault 中。 參考實作會使用微服務的受控識別來向 Key Vault 進行驗證並存取秘密。
容器與協調器安全性
下列建議做法可協助保護您的Pod和容器。
監視威脅。 使用適用於容器的 Defender Microsoft 或非Microsoft功能來監視威脅。 如果您在虛擬機 （VM） 上裝載容器，請使用 Microsoft Defender for Servers 或非Microsoft功能。 此外，您可以將 Azure 監視器 中 容器監視解決方案的記錄整合到 Microsoft Sentinel 或現有的安全性資訊和事件管理 （SIEM） 解決方案。
監視弱點。 使用適用於雲端的Defender Microsoft 或非Microsoft解決方案，持續監視映像和執行容器中的已知弱點。
自動化映像修補。 使用 Azure Container Registry 工作，這是 Container Registry 的功能，可將映像修補自動化。 容器映像是從圖層建置而來。 基底層包括 OS 映像和應用程式架構映像，例如 ASP.NET Core 或 Node.js。 基底映像通常是從應用程式開發人員建立上游，而其他項目維護者會加以維護。 在上游修補這些映射時，請務必更新、測試及重新部署您自己的映像，以免造成任何已知的安全性弱點。 Azure Container Registry 工作可協助將此程序自動化。
將映像儲存在受信任的私人登錄中。 使用信任的私人登錄，例如 Container Registry 或 Docker Trusted Registry 來儲存映像。 使用 Kubernetes 中的驗證許可 Webhook，協助確保 Pod 只能從受信任的登錄擷取映像。
套用最低許可權原則。 請勿以特殊許可權模式執行容器。 特殊許可權模式可讓容器存取主機上的所有裝置。 可能的話，請避免在容器內以根目錄的形式執行進程。 容器不會從安全性觀點提供完全隔離，因此最好以非特殊許可權使用者身分執行容器進程。
部署 CI/CD 考慮
請考慮微服務架構強固 CI/CD 程式的下列目標：
每個小組都可以獨立建置及部署其擁有的服務，而不會影響或中斷其他小組。
將新版本的服務部署到生產環境之前，它會部署到開發、測試和Q&A 環境以進行驗證。 每個階段都會強制執行質量大門。
新版本的服務可以與舊版並存部署。
已備妥足夠的訪問控制原則。
針對容器化工作負載，您可以信任部署到生產環境的容器映像。
若要深入了解挑戰，請參閱 微服務架構的 CI/CD。
使用 Istio 之類的服務網格可協助 CI/CD 程式，例如 Canary 部署、微服務的 A/B 測試，以及具有以百分比為基礎的流量分割的分段推出。
如需特定建議和最佳做法的詳細資訊，請參閱 使用 Azure DevOps 和 Helm 在 Kubernetes 上建置微服務的 CI/CD 管線。
成本優化
成本優化著重於減少不必要的費用，並提升營運效率的方式。 如需詳細資訊，請參閱 成本優化的設計檢閱檢查清單。
使用 Azure 定價計算機來預估成本。 Microsoft Azure Well-Architected Framework中的 成本 一節會說明其他考慮。
針對此架構中使用的部分服務，請考慮下列幾點。
AKS
在 免費層中，Kubernetes 叢集的部署、管理和作業中，AKS 沒有任何相關成本。 您只需支付 Kubernetes 叢集取用的 VM 實例、記憶體和網路資源。
請考慮使用 水準 Pod 自動調整程式，根據負載自動調整微服務或相應放大微服務。
設定 叢集自動調整程式，以根據負載相應縮小或相應放大節點。
請考慮使用 現成節點 來裝載非關鍵微服務。
檢閱 AKS 的成本優化最佳做法。
若要估計所需資源的成本，請使用 AKS 計算機。
Azure 負載均衡器
您只需支付已設定的負載平衡和輸出規則數目。 輸入網路地址轉譯規則是免費的。 未設定任何規則時，標準 Load Balancer 不會每小時收費。 如需詳細資訊，請參閱 Azure Load Balancer 定價。
Azure Pipelines
此參考架構只會使用 Azure Pipelines。 Azure 會以個別服務的形式提供管線。 針對 CI/CD，每個月您有 1,800 分鐘的免費Microsoft裝載工作，每個月都有一個無限制的自我裝載工作。 額外的作業會產生更多成本。 如需詳細資訊，請參閱 Azure DevOps 服務定價。
Azure 監視器
針對 Azure 監視器 Log Analytics，您需支付數據擷取和保留費用。 如需詳細資訊，請參閱 Azure 監視器計量價格。
卓越營運
卓越營運涵蓋部署應用程式的作業程式，並讓它在生產環境中執行。 如需詳細資訊，請參閱 Operational Excellence的設計檢閱檢查清單。
此參考架構包含 Bicep 檔案，以布建雲端資源及其相依性。 您可以使用 Azure Pipelines 來部署這些 Bicep 檔案，並快速設定不同的環境，例如復寫生產案例。 此方法只會在需要時布建負載測試環境，以協助您節省成本。
請考慮遵循工作負載隔離準則來建構 Bicep 檔案。 工作負載通常定義為任意功能單位。 例如，您可以有叢集的個別 Bicep 檔案，然後有另一個相依服務的檔案。 您可以使用 Azure DevOps 來執行 CI/CD 與工作負載隔離，因為每個工作負載都是由自己的小組相關聯和管理。
部署此案例
若要部署此架構的 參考實作，請遵循 GitHub 存放庫中的步驟。 如需詳細資訊，請參閱 AKS 微服務參考實作。
貢獻者們
本文由 Microsoft 維護。 下列參與者撰寫本文。
主要作者：
- 法蘭西斯·西米·納扎雷斯 |資深技術專家
其他參與者：
- Paolo Salvatori |首席客戶工程師
- 亞歷山德羅·沃薩 |資深技術專家
若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。
下一步
- 搭配 AKS 使用服務主體
- 適用於雲端的Defender中的 容器保護
- 規劃適用於伺服器的Defender部署
- Azure 監視器中的 容器監視解決方案
- Microsoft Sentinel 或現有的 SIEM 解決方案
- 適用於雲端的Defender 或可透過 Azure Marketplace 取得的非Microsoft解決方案
- 使用 Azure Container Registry 工作將容器映像建置和維護自動化
相關資源
- 若要完成更進階的微服務範例，請參閱 進階 AKS 微服務架構。
- 若要瞭解如何測量此應用程式的效能，請參閱 效能微調案例：分散式商務交易。
- 微服務架構的 CI/CD
- Kubernetes 上微服務的 CI/CD