GKE Autopilot 適合你的工作負載嗎？先看幾個限制

GKE Autopilot 會接手節點管理，讓團隊少處理一部分叢集維運。但如果工作負載需要特殊節點設定、權限或擴容速度，部署前就得確認限制能否接受。

Autopilot 省下管理 node pool 和安排節點升級等工作，也帶有安全預設值。這些便利很實際，但費用與可調整的設定，仍要拿自己的 Pod 需求試算。

下面從成本、權限與容量變化三個角度，檢查它是否適合目前的系統。

一、先看計費方式：Pay-per-Pod vs Pay-per-Node

Autopilot 和 Standard 的計費基礎不同，不能只拿叢集數量或節點數量直接比較：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

requests 設太寬，兩邊都會付出代價

Standard 主要按節點計費，但 requests 仍會影響排程：設得過高，同一台節點能放的 Pod 變少，可能得多開節點。它不是「反正節點錢照付，就可以隨便填」。

Autopilot 的一般用途 Pod 則直接按有效的 requests 收費。如果把 memory request 從 256 MiB 提到 1 GiB，記憶體這一項的計費量會提高；但整張帳單還包含 CPU、暫存儲存空間及其他費用，不能直接說總價變成四倍。先看監控數據與尖峰用量，再調整 requests 和 limits。計費細節以官方價格頁為準。

最小資源限制

Autopilot 對 Pod 有硬性的最低資源門檻，而門檻會隨叢集是否支援 bursting 而不同（GKE 1.30 起的叢集預設支援 bursting）：

• 一般 Pod：支援 bursting 的叢集是 50m vCPU + 52 MiB memory；不支援 bursting 的舊叢集才是 0.25 vCPU + 0.5 GiB
• DaemonSet Pod：依官方文件，最低約每 Pod 10 mCPU + 10 MiB memory（不支援 bursting 的叢集）或 1 mCPU + 2 MiB（支援 bursting 的叢集），遠低於一般 Pod 門檻
• Balanced compute class：0.25 vCPU + 0.5 GiB；Scale-Out：0.25 vCPU + 1 GiB；Performance / Accelerator：不強制最低 CPU / memory requests

如果有很多短任務或輕量 sidecar，要留意請求值是否被提高到最低門檻；不同 ComputeClass、叢集版本和 bursting 支援情況，門檻並不相同。別只看 YAML 原本填的數字，也要檢查 Pod 建立後的有效 requests。完整範圍見官方資源限制。

沒有通用的「幾成使用率就該換模式」

Standard 能否比較省，取決於節點裝箱、折扣、閒置容量與團隊維運成本；Autopilot 還要看 Pod 是否採用一般用途或指定硬體的計費方式。拿同一組工作負載的 requests、尖峰、副本數與執行時數分別試算，再比較帳單，會比套用固定的使用率門檻可靠。

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 24, "rankSpacing": 32}}}%%
flowchart TD
  START["盤點 requests、實際用量、<br/>尖峰與硬體需求"] --> PROFILE{"工作負載輪廓？"}
  PROFILE -->|"一般用途 Pod"| UTIL{"調準 requests 後，負載仍<br/>長時間穩定且利用率偏高？"}
  PROFILE -->|"指定 GPU／TPU／機型"| NODE["按整台節點與管理費估算，<br/>再依控制需求選模式"]
  UTIL -->|"否：小型或波動大"| AUTO_LOW["評估 Autopilot 的代管價值<br/>與 Pod requests 成本"]
  UTIL -->|"是"| SKILL{"團隊能維護 autoscaler、<br/>node pool 與 bin packing？"}
  SKILL -->|"否"| AUTO_TEAM["評估 Autopilot 的費用<br/>與較低維運負擔"]
  SKILL -->|"是"| STANDARD["同時估算 Standard 的節點裝箱成本"]

二、系統權限與底層控制力受限

Autopilot 預設限制部分節點操作與 Pod 權限。這不代表所有 DaemonSet 都不能跑，而是要先確認它實際需要哪些能力。

無法取得節點層級的控制權

• ❌ 不能 gcloud compute ssh 進節點
• ❌ 不能自訂節點的 OS image（Custom Node Image）
• ❌ 不能設定 unsafe sysctls（Autopilot 不開 allowed-unsafe-sysctls，只有 Kubernetes 預設那幾個 safe sysctls 還能用）
• ❌ 不能安裝自訂 CNI

Standard 可以直接檢查節點作業系統與 kubelet；Autopilot 則沒有同樣的節點存取權。排查 Pod 啟動或網路問題時，仍可從 kubectl describe、事件、指標和 Cloud Logging 下手，但若問題只能靠節點層級工具定位，排查流程就會不同。先拿團隊常見的故障情境做一次演練。

嚴格的 Security Context 限制

Autopilot 預設會擋掉這些（注意是「預設」，不是「永遠」——下面講例外）：

• 特權容器（privileged: true）
• 主機網路（hostNetwork）、hostPID、hostIPC
• 指定固定的 hostPort
• 大部分 hostPath 路徑（預設只開唯讀的 /var/log 給除錯用）

部分經驗證的合作夥伴與開源工作負載，可透過 WorkloadAllowlist 使用原本受限的權限；符合資格的客戶也可為自有工作負載申請這項能力。不是把 privileged: true 加進 YAML 就會自動通過。若現有 agent 需要特權，先查官方 allowlist 說明，再用測試叢集驗證版本與設定。

對外提供服務時，也別把 hostPort、NodePort 與 LoadBalancer 混為一談。Autopilot 支援 NodePort Service，但它不等於從網際網路公開服務；若需要外部入口，要按協定與路由需求選 LoadBalancer Service 或 Ingress。

第三方工具相容性

如果目前有 DaemonSet 或第三方 agent，先盤點它是否依賴：

• 特權模式、額外 Linux capabilities 或主機網路
• 特定 hostPath、核心參數或節點檔案
• 自訂網路或儲存元件所需的節點存取

同一類工具的不同版本可能需要不同權限。把正在使用的映像版本和部署設定拿去測試，比只憑產品名稱判斷能不能跑可靠。

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 24, "rankSpacing": 32}}}%%
flowchart TD
  INVENTORY["列出 DaemonSet、SecurityContext、<br/>hostPath、hostNetwork 與 capabilities"] --> NEED{"是否需要節點級<br/>或特權能力？"}
  NEED -->|"否"| BASE["在測試叢集驗證功能、網路、<br/>儲存與可觀測性；通過才 Pilot"]
  NEED -->|"是"| SUPPORTED{"符合 WorkloadAllowlist，<br/>或能改用受支援方案？"}
  SUPPORTED -->|"是"| PRIV["設定 allowlist 或替代方案，<br/>完成測試後才進入 Pilot"]
  SUPPORTED -->|"否"| STANDARD["改用 GKE Standard"]

三、擴容時，新 Pod 要等多久？

HPA 建立副本，不代表副本已經接得住流量。先分清楚等待是發生在排程、節點容量，還是容器本身的啟動。

動態配置的代價

• Standard：團隊可以在節點池預留容量。Pod 不必等新節點時，排程通常較快，但閒置容量也會計費；容器啟動與健康檢查仍要時間。
• Autopilot：GKE 會依 Pod 需求調整容量。一般用途工作負載可能透過動態調整現有節點或預先配置的容量擴展，不一定每次都要等新 VM；若仍需新增節點，Pod 就會等待節點就緒。官方容量說明列出這兩種路徑。

這對哪些場景是痛點？

• 促銷或活動開始時，流量在短時間內暴增的 API
• 必須在限定時間內啟動的推論或事件處理工作
• 啟動時間會直接影響工作等待時間的 CI/CD runner

若實測顯示等待節點是瓶頸，可以評估預留容量的做法，例如低優先級的 placeholder Pod；它會產生成本，也要驗證驅逐後的行為。如果瓶頸在映像下載或應用程式啟動，預留節點就不會解決問題。

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 24, "rankSpacing": 32}}}%%
flowchart TD
  SPIKE["流量突增，HPA／Job controller<br/>建立新 Pod"] --> CAPACITY{"叢集現有容量<br/>能否容納？"}
  CAPACITY -->|"能"| FAST["排程並啟動容器"]
  CAPACITY -->|"不能"| WAIT["動態調整容量或新增節點 →<br/>排程 → 容器 Ready"]
  BALLOON["低優先級 balloon Pod<br/>預留 headroom"] -. "尖峰時被驅逐" .-> CAPACITY
  FAST --> SLO{"啟動延遲符合 SLO？"}
  WAIT --> SLO
  SLO -->|"是"| KEEP["保留目前策略"]
  SLO -->|"否"| CHOOSE["增加預熱容量、調整架構，<br/>或改用可控 headroom 的 Standard"]

四、特殊硬體與功能先查支援範圍

硬體需求要寫到具體規格

Autopilot 能透過內建或自訂 ComputeClass 選擇部分硬體，不是只能跑一般用途 Pod。但如果你需要指定機型、CPU 平台、GPU 數量或 local SSD 配置，就要逐項核對ComputeClass 支援範圍，也別忘了確認區域、配額和計費模式。

Standard 讓團隊直接管理 node pool，節點設定的控制範圍較大；代價是容量、升級和故障處理也要自己承擔更多。若需要的設定在 Autopilot 中無法提供，再考慮 Standard。

GPU / TPU 不要靠舊清單判斷

Autopilot 已支援多種加速器，但型號、可選數量、最低 GKE 版本與區域會變動。部署前按實際模型需求查GPU 支援表及對應 TPU 文件，再確認配額。不要因為要用 GPU 就直接排除 Autopilot，也不要預設新型號一定已在目標區域可用。

預覽功能逐項確認

若系統依賴特定 Kubernetes 預覽功能、CSI driver 或網路元件，請查該功能目前支援的叢集模式、版本與限制。「Standard 先有、Autopilot 後有」不能當成通則；真正要比的是你準備部署的那項功能。

五、其他你該注意的細節

日誌費用與可觀測性

Autopilot 不支援 --logging=NONE；系統日誌會收集，工作負載日誌則可視需求調整。兩種模式都可以透過排除篩選器減少送進 Cloud Logging 的量。先量測現有系統與應用程式日誌的每天資料量、保留需求，再估算成本；別只憑「中型叢集」猜每月帳單。排除過多日誌也會讓事故排查變難，設定前可對照官方日誌說明。

版本升級控制權較少

Autopilot 會自動升級控制平面與節點，不能永久關閉。你仍可透過 release channel、maintenance window 和 exclusion 管理時間，但要核對可延後的範圍與期限。如果工作負載對 Kubernetes 版本特別敏感，測試升級相容性會比單純延後升級重要。詳見官方升級說明。

叢集位置與跨 Zone 流量

新建 Autopilot 叢集採 regional 模式。規劃開發或正式環境時，除了控制平面可用性，也要看 Pod 與資料庫、儲存資源各在哪個 Zone；跨 Zone 通訊可能增加延遲和網路費用。若團隊明確需要 zonal 叢集，就把 Standard 納入比較。

總結：該如何選擇？

什麼情況適合先試 Autopilot？

如果服務不需要碰節點，團隊也希望少花時間管理 node pool，可以先用 Autopilot 做測試部署。檢查重點是：

• Pod 的 requests 與 ComputeClass 是否符合效能和預算
• 現有 agent、網路及儲存元件能否通過權限限制
• 尖峰時的新副本能否在服務要求的時間內就緒

這些條件通過後，Autopilot 減少節點維運的好處才有辦法和實際成本一起衡量。

什麼情況要比較 Standard？

1. 必要的節點權限、硬體或網路設定，無法在 Autopilot 中使用或取得 allowlist。
2. 實測擴容時間不符要求，而且團隊需要直接控制預留節點容量。
3. 依相同流量與服務要求試算後，Standard 的節點配置與維運成本更合適。
4. 組織需要直接管理 node pool 設定與升級流程。

做決定前的最後一輪檢查

Autopilot 和 Standard 不是「省事」與「省錢」的固定對應。先用一個代表性的服務試部署，記下請求值、實際用量、新 Pod 就緒時間及遇到的權限限制；接著把同樣的負載放進兩種模式的成本估算。

至少回答這幾題：

1. 現有 DaemonSet 與 Pod 需要哪些節點權限？有沒有對應的 allowlist 或替代方式？
2. 輕量 Pod 的有效 requests 是多少？尖峰副本數與執行時數又是多少？
3. 目標區域、硬體、配額和計費模式能否滿足需求？
4. 流量上來時，從建立 Pod 到 Ready 的時間是否符合 SLO？

如果其中一題還沒有實測數字，就先把它列為試行要驗證的假設，別急著替整個平台選邊站。

延伸閱讀

• GKE 入門：在 Google Kubernetes Engine 上部署容器應用（本站；從 Pod、Deployment、Service 講起，附 Standard 與 Autopilot 的簡要對照）
• Autopilot overview（官方文件）
• Autopilot 最低與最高資源 requests（各 compute class 門檻與 bursting 差異）
• 在 Autopilot 執行特權工作負載（WorkloadAllowlist 機制）
• Autopilot 安全限制（sysctls、hostPath、NodePort 等預設限制）
• Autopilot GPU 支援（支援機型與最低版本）
• Autopilot compute classes（內建 ComputeClass 的適用範圍）