企業級微服務中樞：AKS 與 Container Apps 怎麼選

我第一次陪團隊選 Azure 上的容器落腳處，會議開了兩個多小時，吵的其實不是技術規格。真正沒有共識的是一句話：這套系統之後由誰負責升級。

AKS 與 Container Apps 的分野，用一句話講就是 Kubernetes API 要不要交到你手上。這篇要把這條界線畫清楚，順便交代 2026 年這兩邊各自長成了什麼樣子。

選容器平台的第一個問題不是「哪個比較強」，而是「Kubernetes 這件事，你想不想每天面對它」。

先把問題換一種問法：你買的是控制權還是省事

微軟官方的容器服務選型指南把這件事講得很直白：AKS 是 IaaS 與 PaaS 的混合，偏向控制而不是簡單；Container Apps 則是蓋在 Kubernetes 之上的抽象層。

• AKS：拿得到 Kubernetes API server，可以裝 CNCF 生態系的任何東西，也要自己扛設定與治理。
• Container Apps：拿不到編排 API，但第七層輸入、流量切分、A / B 測試、生命週期管理都內建。
• 共同點：兩者都能跑同一個容器映像，所以「搬得動」通常不是問題，「搬完誰維運」才是。

AKS 這一側：叢集治理才是主要工作

AKS 幫你託管控制平面，健康監控與維護由 Azure 負責，你付的是跑應用的節點。但控制平面被管好，不等於叢集被治理好。

2026 年的 AKS 把選擇明確切成兩種模式。官方總覽頁在 2026 年 8 月的版本裡直接建議：多數新的工作負載用 AKS Automatic。

什麼時候仍然該選 Standard？官方給的理由很具體：自訂網路設定、Windows 節點池、Automatic 還沒開放的虛擬機規格，或是團隊已經有一整套建在手動叢集上的自動化。

叢集多起來之後：Fleet Manager

一個叢集靠人也管得動，十個就不行了。Azure Kubernetes Fleet Manager 的定位就是這件事：把散在不同區域與訂用帳戶的叢集納為成員叢集，集中治理。

• 更新執行與更新策略：把 Kubernetes 版本與節點映像的升級排成有先後順序的流程，並可掛上人工或自動的審批關卡。
• 自動升級設定檔：新版本一發布就自動觸發升級，不必有人盯著版本公告。
• 受管 Fleet 命名空間：讓應用團隊跨多個叢集拿到同一個命名空間，配額、網路政策與權限一起套用。
• 資源放置：部署一個中樞叢集，依叢集標籤與屬性把 Kubernetes 資源智慧地放到合適的成員叢集。

2026 年這一層明顯往外長。官方總覽頁在 2026 年 8 月的版本裡已經寫明成員叢集可以包含 Arc 連結的 Kubernetes 叢集，範圍跨到其他雲與地端。

Container Apps 這一側：KEDA 與 Dapr 撐起來的無伺服器容器

Container Apps 的定位是無伺服器容器平台：你交出容器映像與一份設定，平台負責其餘的事。官方列的常見用途是 API 端點、背景批次、事件處理與微服務。

它的伸縮能力直接建立在 KEDA 上。除了 HTTP 流量與 CPU、記憶體負載，你可以用任何 KEDA 支援的伸縮器當觸發條件，例如佇列長度或資料庫連線數。

微服務要跑起來，光有伸縮不夠。Container Apps 內建 Dapr，把服務探索、狀態管理、發布訂閱這些每個微服務專案都要重寫一次的東西變成平台能力。

運算形態：工作負載設定檔

Container Apps 的運算資源由工作負載設定檔決定。官方文件在 2026 年 6 月更新的版本裡，列出三種設定檔類型。

GPU 這一塊也已經長好。無伺服器 GPU 走 Consumption 設定檔，可以縮到零；需要專屬硬體的則走 Dedicated 的 GPU 設定檔，官方註明必須在建立環境時就配置好。

自動伸縮與流量切分：同一件事的兩種做法

Container Apps 用修訂版來管版本。每次改動產生一個新的修訂版，你再決定流量怎麼分配，藍綠部署與 A / B 測試就是設定值而不是專案。

下面是設定的結構示意，實際欄位以官方結構描述為準。

properties:
  configuration:
    ingress:
      traffic:
        - revisionName: app--rev-a
          weight: 90
        - revisionName: app--rev-b
          weight: 10
  template:
    scale:
      minReplicas: 0
      maxReplicas: 30
      rules:
        - name: queue-depth
          custom:
            type: azure-queue
            metadata: { queueLength: "..." }

選型界線：四個先問清楚的問題

1. 你需不需要 Kubernetes API：自訂控制器、網路政策、Operator，只要有一項是真的在用，答案就是 AKS。
2. 這台平台上要住幾個工作負載：官方指南建議 Container Apps 承載共用同一個安全邊界的單一工作負載；要讓不相關的元件共存，考慮 AKS。
3. 安全邊界要多細：Container Apps 的環境內通訊不受限、共用同一個 Log Analytics 工作區，沒有更細的存取控制機制。
4. 團隊願意扛多少維運：這題不要用理想值回答，用「下一次半夜升級誰起床」來回答。

2026 年這一年，兩邊各自往哪裡走

把 2026 年的公開資料排在一起看，方向其實蠻一致：AKS 往「幫你把最佳實務預設打開」走，Container Apps 往「更多硬體形態與更強的隔離」走。

• AKS Automatic 的受管系統節點池：把核心 Kubernetes 元件與應用工作負載分開，容量、修補與伸縮交給 Azure，於 2026 年 Build 宣布正式推出。
• Azure Container Linux：為大規模 Kubernetes 部署設計、減少設定漂移的精簡作業系統，同場宣布正式推出。
• AKS on Bare Metal：拿掉虛擬化層取得直接的硬體存取，針對大型模型訓練需要的高速互連，公開預覽。
• Fleet Manager 往混合與多雲延伸：集中化的政策執行、工作負載放置與分階段推出，跨到雲外的叢集。
• Container Apps 的機密運算：以硬體支援的信任執行環境形式提供，透過工作負載設定檔使用，2026 年 Build 宣布正式推出。