Azure Kubernetes Service 上的微服務架構

此架構會顯示部署至 Azure Kubernetes Service （AKS） 的微服務應用程式。 它描述基本 AKS 組態，可供您作為大部分部署的起點。 本文假設您已對 Kubernetes 有基本的瞭解。 它強調如何在 AKS 上管理微服務的基礎架構與開發者運營（DevOps）面向。 對於生產部署，此架構建議使用 Cilium 驅動的 Azure CNI 作為網路解決方案。 此服務透過基於擴展柏克萊封包過濾器（eBPF）的資料平面，提供提升的效能、內建網路政策強制及增強可觀察性。 如需如何設計微服務的詳細資訊，請參閱 微服務架構設計。

Architecture

Helm 是雲端原生運算基金會 （NCF） 的商標。 使用此標記時不會隱含任何背書。

下載此架構的 Visio 檔案。

關於基於 AKS 基線架構的更進階微服務範例，請參見 進階 AKS 微服務架構。

數據流

此要求流程會實作 「發行者-訂閱者」、 「競爭取用者」和 「網關路由」 雲端設計模式。

下列資料流程對應至上一個圖表：

1. 用戶端應用程式會透過 HTTPS 將 JSON 有效載荷傳送到負載平衡器（管理入口控制器）的公開完全限定網域名稱（FQDN），以排程無人機接載。

   • Managed 輸入控制器會將要求路由傳送至擷取微服務。

   • 擷取微服務會處理 Azure 服務總線佇列中的要求和佇列傳遞要求。

2. 工作流程微服務會採取以下步驟：

   • 從服務總線消息佇列取用訊息資訊

   • 向交付微服務發送 HTTPS 請求，該微服務將資料傳送至 Azure Managed Redis 中的外部資料儲存

   • 將 HTTPS 要求傳送至無人機排程器微服務

   • 向封包微服務發送 HTTPS 請求，該微服務將資料傳送至外部資料儲存 MongoDB 中

3. HTTPS GET 要求會傳回傳遞狀態。 此要求會透過受控輸入控制器傳遞至傳遞微服務。 然後交付微服務會讀取 Azure Managed Redis 的資料。

Components

• AKS 是一個託管的 Kubernetes 服務，負責託管並協調微服務容器。 在此架構中，AKS 提供執行時平台，用於部署、擴展及管理無人機配送應用程式的微服務。

• Azure CNI powered by Cilium 是推薦的網路解決方案，直接連接到 Azure 虛擬網路。 在此架構中，它將虛擬網路的 IP 位址分配給 pods，並提供內建的網路政策功能與流量可視性。

• 入口伺服器會向叢集內的服務揭露 HTTP 和 HTTPS 路由。 在此架構中，透過應用程式路由外掛使用 受管理的 NGINX 入口控制器 。 輸入控制器會實作微服務的 API 閘道 模式。

• 外部資料儲存庫，如 Azure SQL Database 或 Azure Cosmos DB，則被無狀態微服務用來撰寫資料及其他狀態資訊。 在此架構中， Azure Cosmos DB、 Azure Managed Redis、 Azure DocumentDB 與 Service Bus 作為資料儲存或狀態儲存場所。

• Microsoft Entra ID 是一項基於雲端的身份與存取管理服務，提供 AKS 叢集及已部署工作負載的認證與授權功能。 AKS 需要 Microsoft Entra ID 整合，才能提供 管理身份 以存取 Azure 容器登錄檔及配置 Azure 資源，如負載平衡器與管理磁碟。 每個部署在 AKS 叢集的工作負載都需要一個身份才能存取 Microsoft Entra 保護的資源，例如 Azure Key Vault 和 Microsoft Graph。 此架構使用 Microsoft Entra Workload ID 與 Kubernetes 整合，並為工作負載提供安全身份。 或者，你也可以使用管理身份或應用程式憑證來進行工作負載驗證。

• 容器登錄 檔是一種可儲存私有容器映像檔的管理服務，這些映像檔會部署到叢集中。 AKS 可以使用其Microsoft Entra 身分識別向 Container Registry 進行驗證。 微服務容器映像會建置並推送至 Container Registry。 在此架構中，容器登錄檔儲存部署至AKS叢集的微服務的私有容器映像檔。

• Azure Pipelines 是 Azure DevOps 套件的一部分，並執行自動化建置、測試和部署。 在微服務環境中，強烈建議採用 持續整合與持續部署（CI/CD） 方法。 各種小組可以使用 Azure Pipelines 獨立建置和部署微服務至 AKS。 在此架構中，Azure Pipelines 建置並部署無人機傳遞微服務至 AKS。

• Helm 是一個用於 Kubernetes 的套件管理器，提供一種機制，將 Kubernetes 物件打包並標準化成一個單位，讓你可以發佈、部署、版本化和更新。 在此架構中，Helm 將無人機傳遞微服務打包部署至 AKS。

• Azure Monitor 是一個監控平台，負責收集並儲存 Azure 服務的指標與日誌、應用程式遙測資料，以及平台指標。 在此架構中，Azure Monitor 與 AKS 整合，從控制器、節點及容器收集指標。

• Application Insights 是一款監控微服務與容器的效能監控工具。 它能提供微服務的可觀察性，包括流量、端對端延遲及錯誤百分比。 它可以在單一應用程式地圖上顯示微服務的健康狀況及其間的關係。 在此架構中，Application Insights 監控無人機交付微服務的健康狀況與效能，並在應用地圖上顯示其關聯。

Alternatives

Azure Container Apps 是一個無伺服器管理平台，提供基於 Kubernetes 的體驗，且不需管理基礎設施。 當您不需要直接存取 Kubernetes 或其 API，且不需要控制叢集基礎結構時，它可作為裝載微服務的更簡單替代方案。

你可以用像 Application Gateway for Containers、Istio 入口閘道或非 Microsoft 解決方案這類替代方案，取代 AKS 的管理入口閘道。 如需詳細資訊，請參閱在 AKS 中輸入。

你可以將容器映像檔存放在非 Microsoft 的容器登錄檔，例如 Docker Hub。

在網路方面，雖然此架構推薦使用 Cilium 驅動的 Azure CNI ，以提升效能與內建政策執行，但針對特定情境，你也可以使用像 Azure CNI Overlay 這類替代網路解決方案。

對於必須維護狀態資訊的微服務， Dapr 提供一個抽象層來管理微服務狀態。

您可以使用 GitHub Actions 來建置和部署微服務，或選擇非Microsoft CI/CD 解決方案，例如 Jenkins。

您可以使用 Kiali等替代工具達成微服務可觀察性。

案例詳細資料

一家名為 Fabrikam 的虛構公司管理著一支無人機機隊。 企業會註冊此服務，而使用者可要求無人機收取貨物進行遞送。 當客戶排程取貨時，後端系統會指派無人機，並通知用戶預估的遞送時間。 當交付正在進行時，客戶可以使用持續更新的預估交貨時間來追蹤無人機的位置。

潛在的使用案例

從案例採用下列最佳做法，在 AKS 中建構複雜的微服務型應用程式：

• 複雜的 Web 應用程式
• 使用微服務設計原則所開發的商業規則

Considerations

這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework。

Design

此參考架構著重於微服務，但許多建議的做法適用於在AKS上執行的其他工作負載。

Microservices

微服務是鬆散結合、獨立部署的程式代碼單位。 微服務通常會透過定義完善的 API 進行通訊，而且可透過某種形式的服務探索來探索。 Kubernetes 服務物件是在 Kubernetes 中建立微服務模型的典型方式。

數據記憶體

在微服務架構中，服務不應該共用數據儲存解決方案。 每個服務都應該管理自己的數據集，以避免服務之間的隱藏相依性。 數據區隔有助於避免服務之間的非預期結合。 當服務共用相同的基礎數據架構時，可能會發生此程式。 當服務管理自己的數據存放區時，他們可以使用正確的數據存放區來符合其特定需求。 如需詳細資訊，請參閱 微服務的數據考慮。

避免將持續性數據儲存在本機叢集記憶體中，因為該方法會將數據系結至節點。 相反地，請使用外部服務，如 SQL Database 或 Azure Cosmos DB。 另一個選項是使用 Azure 磁碟記憶體或 Azure 檔案記憶體將永續性數據磁碟區掛接至解決方案。 如需詳細資訊，請參閱 AKS 中的應用程式適用的儲存體選項。

網絡與網路政策

在 AKS 上部署生產微服務時，請使用 Cilium 驅動的 Azure CNI 作為網路解決方案。 此方法為微服務架構帶來多項好處：

• 效能與可擴展性： 基於 eBPF 的資料平面提升了服務路由效能，並支援較大型叢集，延遲較低，相較於傳統網路解決方案。

• 網路政策執行： Cilium 強制執行 Kubernetes NetworkPolicy 資源，無需像 Azure Network Policy Manager 或 Calico 這類獨立的網路政策引擎。 此整合簡化叢集配置並降低營運負擔。

• 可觀察性： eBPF 資料平面提供網路流量的可視化，包括網域名稱系統（DNS）查詢、Pod 與 Pod 之間的流量及服務與服務之間的通訊。 這種可視性有助於排除微服務互動問題並識別效能瓶頸。

• 彈性 IP 位址管理： 由 Cilium 驅動的 Azure CNI 支援根據您的工作負載網路架構需求，提供虛擬網路路由和覆蓋網絡的 Pod IP 位址分配模型。

當你為微服務實施網路政策時，應遵循零信任架構原則，明確定義哪些服務可以彼此通訊。 從「全部拒絕」政策開始，並選擇性地只允許微服務間必要的流量。 欲了解更多資訊，請參閱 AKS 網路政策的最佳實務。

API 閘道

API 閘道是一般 微服務設計模式。 API 閘道位於外部用戶端與微服務之間。 網關可作為反向 Proxy，並將要求從用戶端路由傳送至微服務。 API 閘道器也可能執行各種跨領域任務，如認證、安全套接字層（SSL）終止及速率限制。 如需詳細資訊，請參閱下列資源：

• 在微服務中使用 API 閘道

• 選擇 API 閘道技術

在 Kubernetes 中，輸入控制器主要處理 API 閘道的功能。 入口與入口控制器協同工作，執行以下動作：

• 將用戶端要求路由至正確的後端微服務。 此路由為用戶端提供單一端點，並協助將用戶端與服務分離。

• 將多個要求匯總成單一要求，以減少用戶端與後端之間的閒聊。

• 將功能從後端服務卸載，例如SSL終止、認證、IP位址限制或用戶端速率限制（稱為 限速）。

反向 Proxy 有輸入控制器，包括 NGINX、HAProxy、Traefik 和 Azure 應用程式閘道。 AKS 提供多個受控輸入選項。 你可以選擇由 管理型 NGINX 入口控制器 ，透過應用程式路由外掛或應用程式閘道（用於容器）來使用。 或者你也可以選擇 Istio 入口閘道器作為入口控制器。 如需詳細資訊，請參閱在 AKS 中輸入。

Kubernetes 已以更先進且多功能的閘道 API 取代了 Ingress 資源。 入口控制器和閘道 API 是管理流量路由與負載平衡的 Kubernetes 物件。 Gateway API 設計為通用、具表達力、可擴充性且角色導向，是一套現代化的 API，用於定義 Kubernetes 中第 4 級與第 7 級路由規則。

輸入控制器會以邊緣路由器或反向 Proxy 的形式運作。 反向 Proxy 伺服器是潛在的瓶頸或單一失敗點，因此我們建議您部署至少兩個複本，以協助確保高可用性。

何時選擇入口控制器或閘道 API

輸入資源適用於下列使用案例：

• 輸入控制器很容易設定，而且適合較小型且較不複雜的 Kubernetes 部署，可優先設定容易設定。

• 如果你目前在 Kubernetes 叢集中已配置 Ingress 控制器，且它們有效符合需求，你不需要立刻轉換到 Kubernetes Gateway API。

當以下因素適用時，請使用閘道 API：

• 當您處理複雜的路由設定、流量分割和進階流量管理策略時。 Kubernetes Gateway API 路由資源在這些情況下提供了所需的彈性。

• 如果網路需求需要客製化解決方案或整合非 Microsoft 外掛。Kubernetes Gateway API 基於自訂資源定義的方法，能提供更強的擴充性。

Reliability

可靠性有助於確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性的設計檢閱檢查清單。

分割微服務

使用命名空間來組織叢集中的服務。 Kubernetes 叢集中的每個物件都屬於命名空間。 最好使用命名空間來組織叢集中的資源。

命名空間有助於防止命名衝突。 當多個團隊在同一叢集部署微服務，可能有數百個微服務時，要在單一命名空間中管理它們變得困難。 命名空間還能讓你執行以下操作：

• 將資源條件約束套用至命名空間，讓指派給該命名空間的 Pod 總數不能超過命名空間的資源配額。

• 在命名空間層級套用原則，包括角色型訪問控制 （RBAC） 和安全策略。

當多個團隊開發並部署微服務時，命名空間提供了方便的機制，用以控制每個團隊可部署的區域。 例如，Kubernetes RBAC 政策 只授予開發團隊 A 存取命名空間 A，而開發團隊 B 僅存取命名空間 B。

針對微服務架構，請考慮將微服務組織成限定內容，併為每個限定內容建立命名空間。 例如，所有與 訂單履行 有界上下文相關的微服務都可以進入相同的命名空間。 或者，為每個開發小組建立命名空間。

將公用程式服務放入自己的個別命名空間。 例如，你可以部署像 Elasticsearch 和 Prometheus 這類叢集監控工具到監控命名空間。

健康檢測

Kubernetes 定義 Pod 可以公開的三種健康情況探查類型：

• 整備探查： 告訴 Kubernetes Pod 是否準備好接受要求。

• Liveness 探查： 告訴 Kubernetes 是否應該移除 Pod 並啟動新的實例。

• 啟動探查： 告訴 Kubernetes 是否已啟動 Pod。

要理解探測，首先要了解 Kubernetes 中服務的工作原理。 服務具有符合一組零個或多個 Pod 的標籤選取器。 Kubernetes 會將流量平衡到符合選取器之 Pod 的流量。 只有成功啟動且狀況良好的 Pod 才會接收流量。 如果容器當機，Kubernetes 會終止 Pod 並排程取代。

有時候 pod 即使成功啟動，也還沒準備好接收流量。 例如，可能正在進行初始化任務，例如在容器中執行的應用程式將資料載入記憶體或讀取設定檔。 您可以針對這些緩慢啟動的容器使用啟動探查。 這種方法有助於防止 Kubernetes 在有機會完全初始化之前終止它們。

存活探針會檢查 Pod 是否正在運行但功能異常，需要重新啟動。 例如，如果一個容器處理 HTTP 請求，但突然停止回應且未當機，活度探測器會偵測此事件並觸發 pod 重新啟動。 如果您設定活躍度探查，它會注意到容器沒有回應時，並提示 Kubernetes 在容器重複失敗探查時重新啟動 Pod。

在設計微服務探測器時，請考慮以下幾點：

• 如果你的程式碼啟動時間很長，活度探測器可能會在啟動結束前回報失敗。 若要延遲活躍度探查的開始，請使用啟動探查，或使用具有活躍度探查的 initialDelaySeconds 設定。

• 只有在重新啟動Pod可能會將Pod還原為狀況良好的狀態時，才會協助進行活躍度探查。 你可以用活度探針來緩解記憶體洩漏或意外死鎖，但不要重啟你預期會再次失敗的 pod。

• 有時準備度探測會檢查依賴服務。 例如，如果 Pod 相依於資料庫，探查可能會檢查資料庫連線。 但這種做法可能會帶來意想不到的問題。 外部服務可能暫時無法使用。 此無法使用會導致服務中所有 Pod 的整備探查失敗，導致其從負載平衡中移除。 此移除會建立上游的級聯失敗。

  更好的方法是在您的服務內實作重試處理，讓您的服務能夠正確地從暫時性失敗中復原。 作為替代方案，Istio 服務網格可以實作重試處理、容錯及斷路器。 這種方法能打造具備韌性的架構，以應對微服務故障。

若要排除微服務健康問題，請使用 進階容器網路服務（Advanced Container Networking Services）中的網路可觀察性功能。 eBPF 資料平面能擷取微服務間的詳細網路流量資訊，協助您辨識連線問題、DNS 解析問題或可能影響服務健康的網路政策錯誤。

資源限制

資源爭用可能會影響服務的可用性。 定義容器 資源條件約束，讓單一容器無法壓倒叢集資源，例如記憶體和 CPU。 對於非容器資源，如執行緒或網路連線，可以考慮使用 Bulkhead 模式 來隔離資源。

使用 資源配額 來限制命名空間所允許的資源總數。 此限制確保前端服務不會消耗後端服務所需的資源，後端服務也不會消耗前端服務所需的資源。 資源配額可協助將相同叢集中的資源配置給多個微服務開發小組。

安全性

安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 如需詳細資訊，請參閱 安全性的設計檢閱檢查清單。

TLS 和 SSL 加密

在許多實作中，輸入控制器會用於 SSL 終止。 作為部署入口控制器的一部分，您必須建立或匯入傳輸層安全（TLS）憑證。 僅針對開發和測試目的使用自我簽署憑證。 如需詳細資訊，請參閱 使用應用程式路由附加元件設定自定義功能變數名稱和 SSL 憑證。

針對生產工作負載，請從受信任的證書頒發機構單位取得已簽署的憑證。

你也可能需要根據組織政策輪換證書。 您可以使用 Key Vault 來輪替微服務使用的憑證。 欲了解更多資訊，請參閱 「在金鑰庫中配置憑證自動輪換」。

網路分段與政策

透過使用 Kubernetes NetworkPolicy 資源，實現微服務間的網路分割。 當你使用 Cilium 驅動的 Azure CNI 時，eBPF 資料平面會強制執行網路政策。

請遵循以下微服務架構中網路政策的最佳實務：

• 應用零信任原則。 從命名空間層級的「deny-all」網路政策開始，明確只允許微服務間必要的流量。

• 根據有界上下文進行劃分。 在微服務架構中，為每個有界上下文建立命名空間，並套用網路政策來控制這些上下文間的流量。

• 控制出站流量 使用網路政策限制微服務的外出流量，僅限於核准的外部服務與端點。

• 監控政策成效。 利用 Cilium eBPF 資料平面的可觀察功能監控網路政策執行，並識別可能顯示設定錯誤或安全問題的阻塞流量。

RBAC

當多個小組同時開發和部署微服務時，AKS RBAC 機制可以提供使用者動作的細微控制和篩選。 您可以使用 Kubernetes RBAC 或 Azure RBAC 搭配 Microsoft Entra ID 來控制叢集資源的存取。 如需詳細資訊，請參閱 AKS的存取和身分識別選項。

驗證和授權

微服務可以要求取用的服務或使用者使用憑證、認證和 RBAC 機制來驗證和授權微服務的存取權。 你可以使用 Microsoft Entra ID 來實作 OAuth 2.0 令牌來授權。 像 Istio 服務網格 這樣的服務網格也為微服務提供授權與認證機制，包括 OAuth 令牌驗證與基於令牌路由。

秘密管理和應用程式認證

應用程式和服務通常需要憑證，才能連接外部服務，如 Azure Storage 或 SQL Database。 挑戰在於如何保護這些憑證並防止外洩。

針對 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 驅動程式的 Key Vault 提供者。 Pod 透過使用工作負載標識或使用者指定或系統指派的管理身份來自我驗證。 欲了解更多資訊，請參閱 「將您的 Azure 身份提供者連結至 AKS 中的 Key Vault Secrets Store CSI 驅動程式」。

• HashiCorp Vault： Microsoft Entra 管理身份識別使 Kubernetes 應用程式能夠使用 HashiCorp Vault 進行身份驗證。 您可以 將儲存庫部署至 Kubernetes。 請考慮在與應用程式叢集不同的專用叢集中執行它。

• Kubernetes 秘密： 另一個選項是使用 Kubernetes 秘密。 此選項是最容易設定但最不安全的選項。 祕密儲存在 etcd，這是一種分散式的鍵值儲存系統。 AKS 會在待用時加密 etcd。 Microsoft管理加密金鑰。

使用像 Key Vault 這樣的解決方案，可以獲得以下優勢：

• 集中控制秘密
• 靜止敏感資料的加密
• 集中式金鑰管理
• 秘密的訪問控制
• 金鑰生命周期管理
• Auditing

此架構會使用微服務的受控識別來向 Key Vault 進行驗證並存取秘密。

容器與協調器安全性

以下建議的做法可以幫助你保護煙囊和容器：

• 監視威脅。 使用適用於容器的 Defender Microsoft 或非Microsoft功能來監視威脅。 如果您在虛擬機 （VM） 上裝載容器，請使用 Microsoft Defender for Servers 或非Microsoft功能。 您也可以將 Azure Monitor 中的容器監控系統 日誌整合至 Microsoft Sentinel 或現有的安全資訊與事件管理（SIEM）解決方案。

• 監控漏洞。 使用適用於雲端的Defender Microsoft 或非Microsoft解決方案，持續監視映像和執行容器中的已知弱點。

• 自動化映像修補。 使用 容器登錄任務 來自動化映像補丁。 容器映像是從圖層建置而來。 基底層包括作業系統映像與應用程式框架映像，如 ASP.NET Core 或 Node.js。 基底映像通常是從應用程式開發人員建立上游，而其他項目維護者會加以維護。 當這些映像檔被上游修補時，你必須更新、測試並重新部署自己的映像檔，以避免留下已知的安全漏洞。 容器登錄任務可以幫助自動化這個流程。

• 將映像儲存在受信任的私人登錄中。 使用受信任的私有登錄檔，如 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 定價計算機來預估成本。

針對此架構中使用的部分服務，請考慮下列幾點。

AKS

• 在 免費方案中，AKS 在 Kubernetes 叢集的部署、管理和運作中不需額外付費。 您只需支付 Kubernetes 叢集取用的 VM 實例、記憶體和網路資源。

• 考慮使用 水平 Pod 自動調整器 (Horizontal Pod Autoscaler，HPA)，根據負載自動縮減或擴展微服務。

• 設定 叢集自動調整器（CA） 根據負載調整節點的擴展或縮減。

• 請考慮使用 現成節點 來裝載非關鍵微服務。

• 檢閱 AKS 的成本優化最佳做法。

• 若要估計所需資源的成本，請使用 AKS 計算機。

Azure Load Balancer

您只需支付已設定的負載平衡和輸出規則數目。 輸入網路地址轉譯規則是免費的。 未設定任何規則時，標準 Load Balancer 不會每小時收費。 如需詳細資訊，請參閱 Azure Load Balancer 定價。

Azure Pipelines

此參考架構使用 Azure Pipelines 進行 CI/CD 任務。 Azure 會以個別服務的形式提供管線。 針對 CI/CD，每個月您有 1,800 分鐘的免費Microsoft裝載工作，每個月都有一個無限制的自我裝載工作。 額外的作業會產生更多成本。 如需詳細資訊，請參閱 Azure DevOps 服務定價。

Azure 監視器

對於日誌分析，您將需付費以用於資料匯入和保留。 如需詳細資訊，請參閱 Azure 監視器計量價格。

卓越營運

卓越營運涵蓋部署應用程式的作業程式，並讓它在生產環境中執行。 如需詳細資訊，請參閱 Operational Excellence的設計檢閱檢查清單。

此參考架構包含 Bicep 檔案，以布建雲端資源及其相依性。 你可以使用 Azure Pipelines 部署這些 Bicep 檔案，並快速設定不同環境，例如複製生產環境。 此方法只會在需要時布建負載測試環境，以協助您節省成本。

請考慮遵循工作負載隔離準則來建構 Bicep 檔案。 工作負載通常定義為任意功能單位。 例如，您可以有叢集的個別 Bicep 檔案，然後有另一個相依服務的檔案。 您可以使用 Azure DevOps 來執行 CI/CD 與工作負載隔離，因為每個工作負載都是由自己的小組相關聯和管理。

Contributors

本文由 Microsoft 維護。 下列參與者撰寫本文。

主要作者：

• 法蘭西斯·西米·納扎雷斯 |資深技術專家

其他貢獻者：

• 亞歷山德羅·沃扎 |高級技術專家

若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。

後續步驟

• 搭配 AKS 使用服務主體
• 適用於雲端的Defender中的 容器保護
• 規劃適用於伺服器的Defender部署
• Azure Monitor 中的容器監控解決方案
• Microsoft Sentinel
• 雲端防護者 (Defender for Cloud)
• 透過使用 Container Registry 任務自動化容器映像建置與維護

相關資源

• 進階 AKS 微服務架構。
• 微服務架構的 CI/CD
• Kubernetes 上微服務的 CI/CD