進階 Azure Kubernetes Service （AKS） 微服務架構

此參考架構詳細說明在 Azure Kubernetes Services 上執行微服務時要考慮的數個組態。 主題包括設定網路原則、Pod 自動調整，以及跨微服務型應用程式的分散式追蹤。

此架構是以 AKS 基準架構為基礎，Microsoft Azure Kubernetes Service （AKS） 基礎結構的建議起點。 AKS 基準會詳細說明基礎結構功能，例如 Microsoft Entra 工作負載 ID、輸入和輸出限制、資源限制，以及其他安全的 AKS 基礎結構組態。 本檔未涵蓋這些基礎結構詳細數據。 建議您先熟悉 AKS 基準，再繼續進行微服務內容。

GitHub 提供此架構的參考實作。

架構

下載此架構的 Visio 檔案。

如果您想要從 AKS 上更基本的微服務範例開始，請參閱 AKS 上的微服務架構。

工作流程

此要求流程會實作 「發行者-訂閱者」、 「競爭取用者」和 「網關路由」 雲端設計模式。 傳訊流程會繼續進行，如下所示：

1. HTTPS 要求會提交以排程無人機取貨。 要求會透過 Azure 應用程式閘道 傳遞至擷取 Web 應用程式，以 AKS 中的叢集中微服務的形式執行。

2. 擷取 Web 應用程式會產生訊息，並將其傳送至 服務匯流排 消息佇列。

3. 後端系統會指派無人機，並通知使用者。 工作流程：

   • 從 服務匯流排 消息佇列取用訊息資訊。
   • 將 HTTPS 要求傳送至傳遞微服務，此微服務會將數據傳遞至 Azure Cache for Redis 外部資料記憶體。
   • 將 HTTPS 要求傳送至無人機排程器微服務。
   • 將 HTTPS 要求傳送至套件微服務，以將數據傳遞至 MongoDB 外部資料記憶體。

4. HTTPS GET 要求可用來傳回傳遞狀態。 此要求會透過 應用程式閘道 傳遞至傳遞微服務。

5. 傳遞微服務會從 Azure Cache for Redis 讀取數據。

元件

此架構會使用下列 Azure 元件：

Azure Kubernetes Service 是提供受控 Kubernetes 叢集的 Azure 供應專案。 使用 AKS 時，Kubernetes API 伺服器是由 Azure 管理。 Kubernetes 節點或節點集區可供存取，而且可由叢集操作員管理。

此架構中使用的 AKS 基礎結構功能包括：

• 系統與用戶節點集區分離
• 角色型存取控制的 AKS 受控Microsoft Entra ID （RBAC）
• Microsoft Entra 工作負載 ID (部分機器翻譯)
• AKS 的 Azure 原則 附加元件
• Azure 容器網络介面 （CNI）
• Azure 監視器容器深入解析

Azure 虛擬網絡 是隔離且高度安全的環境，可用於執行虛擬機（VM）和應用程式。 此參考架構會使用對等互連的中樞輪輻虛擬網路拓撲。 中樞虛擬網路會保存 Azure 防火牆和 Azure Bastion 子網。 輪輻虛擬網路會保存 AKS 系統和用戶節點集區子網和 Azure 應用程式閘道 子網。

Azure Private Link 會配置特定的私人IP位址，以從AKS系統和使用者節點集區子網內的私人端點存取 Azure Container Registry 和 金鑰保存庫。

Azure 應用程式閘道 Web 應用程式防火牆 （WAF） 會公開 HTTP（S） 路由至 AKS 叢集，並將 Web 流量負載平衡至 Web 應用程式。 此架構使用 Azure 應用程式閘道 輸入控制器 （AGIC） 作為 Kubernetes 輸入控制器。

Azure Bastion 提供安全的遠端桌面通訊協定 （RDP） 和安全殼層 （SSH） 透過使用安全套接字層 （SSL） 存取虛擬網路中的 VM，而不需要透過公用 IP 位址公開 VM。

Azure 防火牆 是保護所有 Azure 虛擬網絡 資源的網路安全性服務。 防火牆只允許已核准的服務和完整功能變數名稱 （FQDN） 作為輸出流量。

外部記憶體和其他元件：

Azure 金鑰保存庫 會儲存和管理 AKS 服務的安全性密鑰。

Azure Container Registry 會儲存可在 AKS 叢集中執行的私人容器映射。 AKS 會使用其Microsoft Entra 受控識別向 Container Registry 進行驗證。 您也可以使用其他容器登錄，例如 Docker Hub。

Azure Cosmos DB 會使用適用於 MongoDB 的開放原始碼 Azure Cosmos DB 來儲存數據。 微服務通常是無狀態的，並將其狀態寫入外部數據存放區。 Azure Cosmos DB 是 NoSQL 資料庫，具有適用於 MongoDB 和 Cassandra 的開放原始碼 API。

Azure 服務匯流排 提供可靠的雲端傳訊即服務和簡單的混合式整合。 服務匯流排 支援微服務應用程式通用的異步傳訊模式。

Azure Cache for Redis 會將快取層新增至應用程式架構，以改善大量流量負載的速度和效能。

Azure 監視器 會收集並儲存計量和記錄，包括應用程式遙測和服務計量。 您可以使用此資料來監視應用程式、設定警示和儀錶板，以及執行失敗的根本原因分析。

其他作業支援系統 （OSS） 元件：

Helm 是 Kubernetes 的套件管理員，可將 Kubernetes 對象組合成單一單位，您可以發佈、部署、版本和更新。

Azure 金鑰保存庫 秘密存放區 CSI 提供者、取得儲存在 Azure 金鑰保存庫 中的秘密，並使用秘密存放區 CSI 驅動程式介面將它們掛接至 Kubernetes Pod。

Flux 是 Kubernetes 的開放且可延伸的持續傳遞解決方案，由 GitOps Toolkit 提供。

案例詳細資料

上圖所示的 Fabrikam 無人機遞送運送應用程式範例會實作本文所討論的架構元件和做法。 在此範例中，虛構的公司 Fabrikam 管理無人機機隊。 企業會註冊此服務，而使用者可要求無人機收取貨物進行遞送。 當客戶排程取貨時，後端系統會指派無人機，並通知用戶預估的遞送時間。 在交付進行中時，客戶可以使用持續更新的ETA來追蹤無人機的位置。

潛在使用案例

此解決方案適用於飛機、航空航太和航空產業。

建議

部署進階 AKS 微服務架構時，實作這些建議。

應用程式閘道 輸入控制器 （AGIC）

API 閘道路由 是一般 微服務設計模式。 API 閘道可作為反向 Proxy，將要求從用戶端路由傳送至微服務。 Kubernetes 輸入資源和輸入控制器會透過下列方式處理大部分的 API 閘道功能：

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

• 將多個要求匯總成單一要求，以減少用戶端與後端之間的閒聊。
• 從後端服務卸除 SSL 終止、驗證、IP 限制和用戶端速率限制或節流等功能。

AKS 叢集的狀態會轉譯為 應用程式閘道 特定設定，並透過 Azure Resource Manager 套用。

外部輸入控制器可簡化 AKS 叢集中的流量擷取、改善安全性和效能，以及節省資源。 此架構會使用 Azure 應用程式閘道 輸入控制器 （AGIC） 進行輸入控制器。 使用 應用程式閘道 來處理所有流量，就不需要額外的負載平衡器。 由於 Pod 會針對 應用程式閘道 建立直接連線，因此會減少所需的躍點數目，進而提升效能。

應用程式閘道 具有內建的自動調整功能，與叢集中輸入控制器不同，如果輸入控制器耗用了不想要的計算資源數量，就必須相應放大。 應用程式閘道 可以執行第 7 層路由和 SSL 終止，並具有與內建 Web 應用程式防火牆 （WAF） 整合的端對端傳輸層安全性 （TLS）。

針對 AGIC 輸入選項，您必須在設定 AKS 叢集時啟用 CNI 網路，因為 應用程式閘道 會部署到 AKS 虛擬網路的子網。 多租使用者工作負載，或支援開發和測試環境的單一叢集，可能需要更多輸入控制器。

零信任網路原則

網路原則會指定如何允許 AKS Pod 彼此通訊，以及與其他網路端點通訊。 根據預設，允許所有輸入和輸出流量來回 Pod。 在設計微服務彼此和其他端點通訊的方式時，請考慮遵循 零信任原則 ，其中存取任何服務、裝置、應用程式或數據存放庫需要明確設定。

實作零信任原則的其中一個策略是建立網路原則，以拒絕目標命名空間內所有 Pod 的所有輸入和輸出流量。 下列範例顯示會套用至後端開發命名空間中所有 Pod 的「拒絕所有原則」。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

一旦設定限制性原則，開始定義特定的網路規則，以允許流量進出微服務中的每個 Pod。 在下列範例中，網路原則會套用至後端開發命名空間中具有符合 app.kubernetes.io/component: backend的標籤的任何 Pod。 除非從具有符合 app.kubernetes.io/part-of: dronedelivery標籤的Pod來源，否則原則會拒絕任何流量。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/part-of: dronedelivery
    ports:
    - port: 80
      protocol: TCP

如需 Kubernetes 網路原則的詳細資訊，以及潛在預設原則的其他範例，請參閱 Kubernetes 檔中的網路原則。

資源配額

資源配額是系統管理員在開發小組或項目之間保留和限制資源的一種方式。 您可以在命名空間上設定資源配額，並使用它們來設定下列限制：

• 計算資源，例如 CPU 和記憶體或 GPU。
• 記憶體資源，包括指定儲存類別的磁碟區數目或磁碟空間量。
• 物件計數，例如可以建立的秘密、服務或作業數目上限。

一旦累計的資源要求總數或限制通過指派的配額，就不會再成功部署。

資源配額可確保指派給命名空間的 Pod 總數不能超過命名空間的資源配額。 前端無法耗盡資源的後端服務，反之亦然。

當您定義資源配額時，命名空間中建立的 Pod 都必須在其 Pod 規格中提供限制或要求。 如果未提供這些值，則會拒絕部署。

下列範例顯示可設定資源配額要求和限制的 Pod 規格：

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

如需資源配額的詳細資訊，請參閱：

• 強制執行資源配額
• 資源配額

自動調整

Kubernetes 支援 自動調整 ，以增加配置給部署的 Pod 數目，或增加叢集中的節點，以增加可用的計算資源總數。 自動調整是自我更正的自發回饋系統。 雖然您可以手動調整Pod和節點，但自動調整可將服務在高負載時變得資源耗盡的機會降到最低。 自動調整策略必須同時考慮Pod和節點。

叢集自動調整

叢集自動調整程式 （CA） 會調整節點數目。 假設 Pod 因為資源條件約束而無法排程;叢集自動調整程式會布建更多節點。 您可以定義最少的節點數目，讓 AKS 叢集和工作負載正常運作，以及大量流量的最大節點數目。 CA 會每隔幾秒鐘檢查擱置的 Pod 或空白節點，並適當地調整 AKS 叢集。

下列範例顯示 ARM 範本中的 CA 組態：

"autoScalerProfile": {
    "scan-interval": "10s",
    "scale-down-delay-after-add": "10m",
    "scale-down-delay-after-delete": "20s",
    "scale-down-delay-after-failure": "3m",
    "scale-down-unneeded-time": "10m",
    "scale-down-unready-time": "20m",
    "scale-down-utilization-threshold": "0.5",
    "max-graceful-termination-sec": "600",
    "balance-similar-node-groups": "false",
    "expander": "random",
    "skip-nodes-with-local-storage": "true",
    "skip-nodes-with-system-pods": "true",
    "max-empty-bulk-delete": "10",
    "max-total-unready-percentage": "45",
    "ok-total-unready-count": "3"
},

ARM 樣本中的下列幾行會設定 CA 的最小和最大節點範例：

"minCount": 2,
"maxCount": 5,

Pod 自動調整

水準 Pod 自動調整程式 （HPA） 會根據觀察到的 CPU、記憶體或自定義計量來調整 Pod。 若要設定水準 Pod 調整，您可以在 Kubernetes 部署 Pod 規格中指定目標計量和最小和最大複本數目。負載測試您的服務，以判斷這些數位。

CA 和 HPA 可一起運作良好，因此請在 AKS 叢集中啟用這兩個自動調整程式選項。 HPA 會調整應用程式，而 CA 會調整基礎結構。

下列範例會設定 HPA 的資源計量：

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 60

HPA 會查看執行中 Pod 的實際資源或其他計量，但 CA 會為尚未排程的 Pod 布建節點。 因此，CA 會查看要求的資源，如 Pod 規格中所指定。使用負載測試來微調這些值。

健康情況探查

Kubernetes 會將流量負載平衡到符合服務標籤選取器的 Pod。 只有成功啟動且狀況良好的 Pod 才會接收流量。 如果容器當機，Kubernetes 會移除 Pod 並排程取代。

在 Kubernetes 中，Pod 可以公開兩種類型的健康情況探查：

• 活躍度探查會告訴 Kubernetes Pod 是否成功啟動且狀況良好。
• 整 備探查 會告訴 Kubernetes Pod 是否準備好接受要求。

活躍度探查會處理仍在執行但狀況不良且應該回收的Pod。 例如，如果服務 HTTP 要求的容器停止回應，則容器不會當機，但會停止提供要求。 HTTP 活躍度探查會停止回應，這會通知 Kubernetes 重新啟動 Pod。

有時候，即使 Pod 已成功啟動，Pod 可能尚未準備好接收流量。 例如，在容器中執行的應用程式可能會執行初始化工作。 整備探查指出 Pod 是否已準備好接收流量。

微服務應該在其程式代碼中公開端點，以利健康情況探查，並特別針對其執行的檢查量身打造延遲和逾時。 HPA 公式索引鍵幾乎完全不在 Pod 上的就緒階段，因此健康情況探查存在且準確至關重要。

監視

在微服務應用程式中， 應用程式效能管理 （APM） 監視對於偵測異常、診斷問題以及快速瞭解服務之間的相依性而言非常重要。 Application Insights 是 Azure 監視器的一部分，可為以 .NET Core、Node.js、Java 和其他許多應用程式語言撰寫的即時應用程式提供 APM 監視。

Application Insights：

• 記錄 HTTP 要求，包括延遲和結果碼。
• 默認會啟用分散式追蹤。
• 在追蹤中包含作業標識碼，因此您可以比對特定作業的所有追蹤。
• 追蹤中通常包含其他內容資訊。

若要將服務遙測與 Kubernetes 世界的內容化，請將 Azure 監視器遙測與 AKS 整合，以從控制器、節點和容器以及容器和節點記錄收集計量。 如果您使用 .NET，Application Insights for Kubernetes 連結庫會使用映射、容器、節點、Pod、卷標和副本集信息來擴充 Application Insights 遙測。

下圖顯示 Application Insights 針對 AKS 微服務遙測追蹤所產生的應用程式相依性對應範例：

如需檢測通用語言以進行ApplicationInsights整合之選項的詳細資訊，請參閱 Kubernetes 的應用程式監視。

考量

這些考量能實作 Azure Well-Architected Framework 的要素，其為一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework (部分機器翻譯)。

延展性

規劃延展性時，請考慮下列幾點。

• 請勿合併複本數目的自動調整和命令式或宣告式管理。 用戶和自動調整程式都嘗試修改複本數目可能會導致非預期的行為。 啟用 HPA 時，請將複本數目縮減為您想要部署的最小數目。

• Pod 自動調整的副作用是，當相應放大和相應縮小事件發生時，可能會經常建立或收回 Pod。 若要減輕這些影響：

  • 使用整備探查，讓 Kubernetes 知道新 Pod 何時準備好接受流量。
  • 使用 Pod 中斷預算來限制一次可從服務收回多少 Pod。

• 建立叢集之後，您無法變更 VM 大小，因此當您建立叢集時，初始容量規劃為代理程式節點選擇適當的 VM 大小。

• 多租使用者或其他進階工作負載可能會有需要更多且可能較小子網的節點集區隔離需求。 如需使用唯一子網建立節點集區的詳細資訊，請參閱 新增具有唯一子網的節點集區。 組織有不同的中樞輪輻實作標準。 請務必遵循您的組織指導方針。

管理能力

規劃管理性時，請考慮下列幾點。

• 透過自動化部署管線管理 AKS 叢集基礎結構。 此架構的參考實作提供 GitHub Actions 工作流程，您可以在建置管線時參考該工作流程。

• 工作流程檔案只會將基礎結構，而不是工作負載部署到已經存在的虛擬網路，並Microsoft Entra 組態。 分別部署基礎結構和工作負載可讓您解決不同的生命週期和作業考慮。

• 假設您的工作流程是一種機制，以在發生區域失敗時部署到另一個區域。 建置管線，讓您可以在具有參數和輸入變更的新區域中部署新的叢集。

安全性

安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊，請參閱安全性要素的概觀。

規劃安全性時，請考慮下列幾點。

• AKS Pod 會使用 儲存在 entra 識別符Microsoft工作負載身分識別 來驗證自己。 最好使用工作負載身分識別，因為它不需要客戶端密碼。

• 使用受控識別，執行中的程式可以快速取得 Azure Resource Manager OAuth 2.0 令牌;不需要密碼或 連接字串。 在 AKS 中，您可以使用 Microsoft Entra 工作負載 ID 將身分識別指派給個別 Pod。

• 微服務應用程式中的每個服務都應該指派唯一的工作負載身分識別，以利進行最低許可權的 RBAC 指派。 您應該只將身分識別指派給需要它們的服務。

• 如果應用程式元件需要 Kubernetes API 存取，請確定應用程式 Pod 已設定為使用具有適當範圍 API 存取的服務帳戶。 如需設定和管理 Kubernetes 服務帳戶的詳細資訊，請參閱 管理 Kubernetes 服務帳戶。

• 並非所有 Azure 服務都支援使用 Microsoft Entra 標識碼進行數據平面驗證。 若要儲存這些服務的認證或應用程式秘密、針對第三方服務或 API 金鑰，請使用 Azure 金鑰保存庫。 Azure 金鑰保存庫 提供集中式管理、訪問控制、待用加密，以及稽核所有密鑰和秘密。

• 在 AKS 中，您可以將一或多個秘密從 金鑰保存庫 掛接為磁碟區。 然後，Pod 可以讀取 金鑰保存庫 秘密，就像一般磁碟區一樣。 如需詳細資訊，請參閱 GitHub 上的 secrets-store-csi-driver-provider-azure 專案。

成本最佳化

成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化要素的概觀。

• Microsoft Azure Well-Architected Framework 中的成本一節說明成本考慮。 使用 Azure 定價計算機來預估特定案例的成本。

• AKS 沒有與 Kubernetes 叢集部署、管理和作業相關聯的成本。 您只需支付叢集耗用的 VM 實例、記憶體和網路資源。 叢集自動調整可藉由移除空白或未使用的節點，大幅降低叢集的成本。

• 若要估計所需資源的成本，請參閱 容器服務計算機。

• 請考慮針對 Kubernetes 特定建構的細微叢集基礎結構成本配置啟用 AKS 成本分析 。

下一步

• Azure Kubernetes Service 簡介
• 什麼是 Azure 虛擬網絡？
• 什麼是 Azure Private Link？
• 什麼是 Azure 應用程式閘道?
• 何謂 Azure Bastion？
• 關於 Azure Key Vault
• Azure Container Registry 簡介
• 歡迎使用 Azure Cosmos DB
• Azure 監視器概觀

相關資源

• Azure Kubernetes Service (AKS) 叢集的基準架構
• 使用 Kubernetes 在 Azure 上設計、建置及操作微服務
• AKS 上的微服務架構
• 在 AKS 中監視微服務架構
• 效能調整案例：分散式商務交易
• 在 Kubernetes 上建置微服務的 CI/CD 管線