本參考提供 Azure IoT 操作 在閒置（無活躍工作負載）部署時的基線資源消耗量。 利用這些設定檔來驗證你的硬體是否符合最低需求，並建立資源監控基準。
概觀
Azure IoT 操作 在多個 Kubernetes 命名空間部署多個元件。 總資源佔用取決於兩個因素：MQTT 中介 記憶體配置檔 （控制每個 pod 記憶體分配）以及 broker 基數 （前端複本數量、後端分割區數及冗餘因子，控制部署的 pod 數量）。 基數越高，表示 Pod 越多；而記憶體設定檔越高，則表示每個 Pod 使用更多記憶體。
在閒置的單節點叢集上測量了三種配置（無連接資產、無活躍資料流、近乎零流量）。 這些是 基準數字，不是最大值。 生產工作負載顯著增加消耗：
| 組態 | 記憶體設定檔 | Cardinality | 節點峰值記憶體 | Azure IoT 操作 Namespace Peak RSS | Pod RSS 峰值總計 | Pod 計數 |
|---|---|---|---|---|---|---|
| 組態 A | 微型 | 1 前端 1 個分割區 冗餘因子 2 |
~4,979 MiB | ~1,298 MiB | ~5,409 MiB | 55 |
| 設定B | 低 | 2 個前端 2 個分割區 冗餘因子 2 |
~5,130 MiB | ~1,559 MiB | ~5,695 MiB | 58 |
| 組態 C | 中等 | 2 個前端 2 個分割區 冗餘因子 2 |
~6,088 MiB | ~2,407 MiB | ~6,564 MiB | 58 |
Note
組態 A 和組態 B 之間的差異來自較高的基數 (更多代理 Pod) 以及不同的記憶體設定檔。 設定 B 與設定 C 的差異僅來自記憶體設定檔（相同基數、相同 Pod 數量）。 請參閱 生產部署範例 以了解載入情境。
命名空間明細
下表顯示三種配置在閒置時依命名空間劃分的峰值 RSS 記憶體：
| 命名空間 | 組態 A，極小 (MiB) | 組態 B，低 (MiB) | 組態 C，中等 (MiB) | Description |
|---|---|---|---|---|
| azure-iot-operations | 1,298 | 1,559 | 2,407 | Azure IoT 操作 核心服務（訊息代理程式、資料流、連接器、可觀察性） |
| azure-arc | 1,964 | 1,985 | 1,990 | Azure Arc 代理程式和控制器 |
| 認證經理 | 1,351 | 1,357 | 1,362 | 憑證管理 |
| 守門人系統 | 338 | 338 | 350 | 政策執行 |
| azure-extensions-usage-system | 279 | 277 | 278 | 計費操作員 |
| arc-workload-identity | 90 | 90 | 91 | 工作負載身份識別網路鉤子 |
| azure-secret-store | 87 | 88 | 87 | 秘密同步控制器 |
| 總計 | ~5,409 | ~5,695 | ~6,564 |
Note
- Azure Arc、cert-manager、gatekeeper 及其他基礎設施命名空間無論 broker 配置如何，都會消耗約 3.8-4.1 GB。 這項額外負荷是執行已啟用 Arc 並搭配 Azure IoT 操作 的叢集所需的固定成本。
-
只有
azure-iot-operations命名空間會隨記憶體配置檔和基數選擇而擴展，從 ~1.3 GB（微小、最小基數）到 ~2.4 GB（中等、較高基數）。 - 在尚未將任何工作負載納入考量前，請規劃至少保留6 GB 的記憶體供 Azure IoT 操作 基礎結構在閒置狀態下使用。
MQTT 代理伺服器 Pod 資源使用量
MQTT 代理伺服器是最大的可變元件。 不同組態之間的記憶體差異來自兩方面：記憶體設定檔 (每個 Pod 的分配量) 以及基數 (Pod 的數量)。 下表顯示各 pod 的閒置 RSS 值。 這些數字會隨著流量增加：
| Pod | 組態 A，極小 (MiB) | 組態 B，低 (MiB) | 組態 C，中等 (MiB) | Notes |
|---|---|---|---|---|
| aio-broker-frontend-0 | 二十九 | 33 | 169 | 每個 Pod 的記憶體會隨設定檔縮放 |
| aio-broker-frontend-1 | 無 | 33 | 169 | 在設定 A 中不存在（一個前端副本） |
| aio-broker-backend-1-0 | 41 | 66 | 211 | 每個 Pod 的記憶體會隨設定檔縮放 |
| aio-broker-backend-1-1 | 41 | 65 | 210 | 冗餘因子複本 |
| aio-broker-backend-2-0 | 無 | 66 | 212 | 配置 A（單一分割區）中不存在 |
| aio-broker-backend-2-1 | 無 | 65 | 211 | 配置 A（單一分割區）中不存在 |
| aio-broker-health-manager-0 | 41 | 41 | 42 | 跨設定檔的常數 |
| aio-broker-operator-0 | 60 | 60 | 56 | 跨設定檔的常數 |
| aio-broker-diagnostics-probe-0 | 24 | 43 | 43 | |
| aio-broker-diagnostics-service-0 | 49 | 66 | 66 | |
| aio-broker-authentication-0 | 24 | 24 | 24 | 跨設定檔的常數 |
| aio-broker-webhook-0 | 33 | 35 | 32 | 跨設定檔的常數 |
每個受測設定檔的代理組態
| Setting | 組態 A (極小) | 設定 B（低） | 組態 C (中等) |
|---|---|---|---|
| 前端複本 | 1 | 2 | 2 |
| 後端分割區 | 1 | 2 | 2 |
| 後端備援因素 | 2 | 2 | 2 |
| 代理 Pod 總數 | 10 | 13 | 13 |
| 每個 pod 的閒置前端記憶體 | ~29 MiB | ~33 MiB | ~169 MiB |
| 每個 pod 的閒置後端記憶體 | ~41 MiB | ~66 MiB | ~211 MiB |
| 訊息大小上限 | 4 MB | 16 MB | 64 MB |
其他 Azure IoT 操作 元件耗用量
這些元件無論記憶體配置或基數如何，閒置資源使用率都保持一致：
| 組件 | RSS 峰值 (MiB) | 峰值 CPU（核心） | Notes |
|---|---|---|---|
| adr-schema-registry (x2) | 每個 ~52 | 0.002 | 結構描述檔登錄 Pod |
| aio-akri-operator-0 | ~39 | 0.001 | Akri 裝置發現 |
| aio-akri-adr-service-0 | ~30 | 0.001 | Akri Azure Device Registry（ADR）服務 |
| aio-dataflow-dev-0 | ~67 | 0.002 | 資料流執行階段 |
| AIO-Dataflow-operator-0 | ~56 | 0.001 | 資料流程運算元 |
| AIO操作員 | ~114 | 0.003 | Azure IoT 操作 操作員 |
| aio-可觀測性 (x2) | ~每人125 | 0.005 | OpenTelemetry 收集器 |
| aio-observability-operator | ~106 | 0.003 | 可檢視性運算子 |
| aio-observability-cluster-metrics-agent | ~114 | 0.004 | 指標代理程式 |
| aio-wasm-graph-controller-0 | ~30 | 0.001 | WebAssembly（WASM）圖形控制器 |
CPU 耗用量
所有測試配置的 CPU 使用率在閒置時均為最小：
| 組態 | Azure IoT 操作 Namespace Peak CPU | 叢集總體 CPU 峰值 | 節點百分比 |
|---|---|---|---|
| Config A（超小型） | 0.025 個核心 | 0.099 個核心 | 1.3% |
| 設定 B（低） | 0.044 核心 | 0.104 核心數 | 1.3% |
| 設定 C（中等） | 0.048 個核心 | 0.093 個核心 | 1.2% |
閒置時 CPU 使用率幾乎可以忽略不計。 在生產負載下，預期 CPU 消耗會顯著增加，這與訊息吞吐量及設定的前端/後端工作者數量成正比。
硬體尺寸調整指導
根據這些閒置基線測量，以下最低硬體建議適用於單節點部署。 實際需求在正式執行流量底下更高：
| 記憶體設定檔 | 最小記憶體（含餘量） | 推薦記憶體 | 用例 |
|---|---|---|---|
| 小 | 8 GB | 8–10 GB | 流量低，封包小 |
| Low | 10 GB | 12–16 GB | 記憶體有限，封包小 |
| Medium | 12 GB | 16–32 GB | 中等流量與訊息大小 |
| 高 | 16 GB | 32+ GB | 高吞吐量，大型訊息 |
Important
這些建議已將約 4 GB 的固定基礎架構負荷（Azure Arc、cert-manager、gatekeeper）以及 Azure IoT 操作 元件的可變資源占用納入考量。 生產工作負載需要額外的餘裕以進行 MQTT 訊息緩衝、資料流程處理及 OPC UA 連接器活動。