進階 Azure Kubernetes Service (AKS) 微服務架構

Azure 應用程式閘道
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure 虛擬網路

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

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

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

架構

Network diagram showing the hub-spoke network with two peered virtual networks and the Azure resources this implementation uses.

下載此架構的 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 基礎結構功能包括:

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 標籤的任何 Pod:backend 。 除非從具有符合 app.kubernetes.io/part-of 標籤的 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 微服務遙測追蹤所產生的應用程式相依性對應範例:

Example of an Application Insights dependency map for an AKS microservices application.

如需檢測通用語言以進行 Application Insights 整合之選項的詳細資訊,請參閱 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 會使用 儲存在 Microsoft Entra ID 中的工作負載身分識別 來驗證自己。 最好使用工作負載身分識別,因為它不需要用戶端密碼。

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

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

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

  • 並非所有 Azure 服務都支援使用 Microsoft Entra ID 進行資料平面驗證。 若要儲存這些服務的認證或應用程式秘密、針對協力廠商服務或 API 金鑰,請使用 Azure 金鑰保存庫。 Azure 金鑰保存庫提供集中式管理、存取控制、待用加密,以及稽核所有金鑰和秘密。

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

成本最佳化

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

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

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

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

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

下一步