GKE Autopilot 聽起來超棒，但它的缺點你最好先知道

GKE Autopilot 幫你省掉一大堆維運雜事，團隊可以專心顧好應用程式本身。但從架構的角度看，這種「全託管」的方便，是拿一部分控制權跟彈性換來的。

第一次看 GKE Autopilot 的文宣，賣點確實很能打動人：不用選機型、不用管 node pool、自動擴縮、自動升級、Pod-level SLA、安全預設值（Workload Identity、Shielded Nodes 強制開啟）。2023 年 4 月之後 Google 甚至把 Autopilot 設成建立叢集的預設選項，擺明是要推你用。

方便從來不是免費的。這篇就從系統架構跟成本管控的角度，把選 Autopilot 之前你最好先想清楚的缺點整理出來。

---

一、成本結構的陷阱：Pay-per-Pod vs Pay-per-Node

這是最多團隊等到帳單來才驚覺的地雷。兩種模式的計費邏輯根本是兩回事：

模式	計費基準	你的優化空間
Standard	依照開出的 VM（節點）計費	可以透過高密度部署（Overcommit）把節點塞到 80-90% 使用率
Autopilot	一般用途 Pod 依宣告的 requests（vCPU / Memory / Storage）計費；選用特定機型系列或 GPU / TPU 等硬體的 Pod 改走 node-based 計費（付整台節點 + 管理費）	一般用途 Pod 幾乎沒有 bin-packing 空間

浪費的代價更高

在 Standard 上，你的 requests 只是 scheduler 放 Pod 的依據，實際計費是整台 VM。把 request 設寬鬆一點防 OOM，沒差，反正節點錢照付。

在 Autopilot 上，你宣告多少 request 就付多少錢。工程師為了保險把 memory request 從 256 MiB 設成 1 GiB，帳單就是直接乘以 4 倍。

最小資源限制

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（Envoy、log shipper）、或每分鐘執行幾秒的 CronJob，這些被墊到下限的資源全部要付錢。在 Standard 上你可以把 sidecar 設 10m CPU 沒人管你；在 Autopilot 上，不支援 bursting 的叢集會把它墊到 0.25 vCPU 然後照這個數字收錢。

成本交叉點

實際上，當叢集整體使用率衝過 65-70%，Standard 就會明顯比 Autopilot 便宜。白話講：如果你本來就會調 cluster autoscaler + VPA + node affinity，Standard 通常比較省。

---

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

為了維持多租戶的穩定與安全，Autopilot 預設啟用一長串限制。

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

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

Standard 你可以 SSH 進節點看 kubelet log、跑 journalctl 追問題。Autopilot 遇到 Pod 卡 ContainerCreating、節點大量 evict、DNS 偶發失敗時，你能做的只有看 Cloud Logging、開 support ticket、等 Google。對習慣 node-level debug 的 SRE，這是最大的心理門檻。

嚴格的 Security Context 限制

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

• 特權容器（privileged: true）
• 主機網路（hostNetwork）、hostPID、hostIPC
• 指定固定的 hostPort
• 大部分 hostPath 路徑（預設只開唯讀的 /var/log 給除錯用）
• 早期版本：自訂 MutatingWebhookConfiguration 改到 kube-system

這幾年 Autopilot 把「全面封死」鬆成了「預設封死、可申請放行」。透過 WorkloadAllowlist + AllowlistSynchronizer 機制：經 Google 驗證的合作夥伴 / 開源特權工作負載預設就能跑；自 GKE 1.35 起，符合資格的客戶連自家的特權工作負載也能加進 allowlist。hostPort 也支援由特定 controller（如 Agones、static Pod）申請隨機指派的通訊埠，只是 Deployment 這類受管控制器仍不行。所以如果你卡在「我的 agent 需要 privileged」，先別急著回 Standard——查一下它在不在 allowlist 清單裡。

對外暴露的方式也要留意：NodePort 型別的 Service，Autopilot 其實是支援的，但透過 NodePort 暴露的服務沒辦法從 VPC 外部（例如網際網路）存取。要對外開的話，請改用 LoadBalancer 或 Ingress（官方甚至建議用 NodePort 取代 hostPort）。

第三方工具相容性

這是最常見的踩雷點。如果你用的 DaemonSet 需要深度的 Linux capabilities，或要掛特定的 host 目錄，下面這些都得當心：

• 某些 APM / 資安代理（Falco、Sysdig 部分功能、舊版 Datadog agent）——其中經 Google 驗證的版本可能已在合作夥伴 allowlist 裡，先查再說
• 需要改 iptables 的 service mesh init container（要走 Google 認可的 Cilium / Dataplane V2）
• 自訂 CSI driver（要等 Google 認證）
• 需要操作 node 行為的 Operator（例如某些資料庫 operator 要調 sysctl）

選 Autopilot 前，把你現在所有的 DaemonSet 與 Pod Security Standard 需求列出來，一個一個對照官方的 allowlist 與限制表驗證能不能跑。

---

三、擴展延遲與「冷啟動」效應（Scaling Latency）

這一點對 latency-sensitive 的 workload 影響很直接。

動態配置的代價

• Standard：你可以刻意維持一個有閒置資源的 Node Pool（headroom）。流量突增或 CI/CD 觸發大量部署時，Pod 瞬間被調度上去。
• Autopilot：採用「Just-in-Time」方式。當叢集沒有空間容納新 Pod，Autopilot 即時配置新節點。Pod 會停在 Pending 狀態等底層 VM 開機完成——通常幾十秒到一兩分鐘。

這對哪些場景是痛點？

• 對延遲極度敏感的 SaaS 服務（需要毫秒到秒級擴容）
• 實時推論、event-driven 批次觸發 job
• CI/CD runner（每個 job 都等 1 分鐘很浪費）
• 突發流量（促銷、病毒行銷、API burst）

緩解方式：用 balloon pod（低優先級的 placeholder Pod 先佔住節點空間，真 Pod 一來就驅逐它）。不過這招在 Standard 上做起來更直接，也更好控。

---

四、特定硬體與進階功能的支援度

硬體選擇缺乏彈性

Autopilot 支援設定 Compute Class（General-purpose、Balanced、Scale-Out、Performance、Accelerator），但在 Standard 中，你可以精細到：

• 指定 CPU 平台（Intel Skylake vs AMD Milan vs ARM Tau）
• 選擇冷門或剛上市的執行個體規格
• 自訂 local SSD 配置

GPU / TPU 支援慢半拍

截至 2026 年中，Autopilot 的 GPU 支援其實已經相當完整：T4、L4、A100（40 GB / 80 GB）、H100、H200、B200，以及 TPU v6e、TPU7x 等都已支援。但每張新卡通常有最低 GKE 版本門檻，而且最新硬體仍是 Standard 先、Autopilot 後。如果你的 workload 踩在剛上市新硬體的浪頭上（LLM 訓練、高頻運算），那段空窗期 Standard 的靈活度是 Autopilot 給不了的。

Alpha / Beta 功能滯後

GCP 每次推出新的 Kubernetes 功能或網路元件，幾乎都是 Standard 先開放。Autopilot 通常要等到該功能完全 GA（General Availability），而且符合它的安全模型之後，才會跟上。

• 某些新的 CSI driver、網路 policy engine：先 Standard 後 Autopilot
• 早期：PodSecurityPolicy、NodeLocal DNSCache 都曾有落差

---

五、其他你該注意的細節

Cloud Operations 強制開啟

Autopilot 叢集的 system component logs（系統元件日誌）強制送進 Cloud Logging，關不掉；workload logs 倒是可以用 --logging=SYSTEM 關掉省錢。真正的差別在於：Standard 連系統日誌都能一起關（--logging=NONE），Autopilot 的系統日誌這扇門是焊死的。一個中型叢集光 log ingestion，每月就能輕鬆吃掉幾百到上千美金，而系統日誌這塊你在 Autopilot 上省不掉。

版本升級控制權較少

Autopilot 一樣可以選 release channel、設 maintenance window 跟 exclusion，所以升級的「時機」你還有得談；但節點自動升級本身關不掉。如果你有「就是不想升」的合規工作負載，這種你只能延、不能拒的地方，就是實打實的風險。

Regional Only

Autopilot 只能建 regional cluster（control plane 跨 3 個 zone）。通常是好事，但：

• 某些 dev / test 叢集你其實只想要 zonal（省錢、快）
• 跨 zone 的 Pod scheduling 會帶來跨 zone 流量費

---

總結：該如何選擇？

用 Autopilot 是極佳選擇的情境

如果你的團隊重心放在業務邏輯（例如快速迭代各種 SaaS 專案或自動化工作流），應用程式又大多是標準的無狀態服務，也沒有特殊的底層權限需求，那大概符合下面這幾點：

• ✅ 團隊沒有專職 SRE，K8s 知識普通
• ✅ 典型 web app / API / worker workload
• ✅ 使用 Google 原生生態（Cloud SQL、Pub/Sub、Cloud Build）
• ✅ 不需要第三方 agent 深度整合節點
• ✅ 叢集使用率偏低（< 60%）

Autopilot 直接幫你省掉管 Node 的時間，對大多數團隊來說，這個好處遠遠蓋過它的缺點。

GKE Standard 是必要妥協的情境

1. 需要運行極度特製化的 DaemonSet 或核心級別權限（privileged、hostPath、hostNetwork）
2. 應用程式有極端流量峰谷，且對擴容冷啟動時間零容忍
3. 團隊有能力做深度資源最佳化，希望透過高密度 bin-packing 極致壓縮帳單
4. 需要最新 GPU / TPU / 冷門 CPU 機型，或 Alpha / Beta 功能
5. 合規要求你必須控制版本、控制 node-level 設定

一句話結論

Autopilot 不是「更好的 GKE」，是「不同取捨的 GKE」。它把「管節點的麻煩」換成「放掉一部分細節控制權」。對大多數標準 workload 這筆交易很划算；但如果你正好踩在它讓你放掉的那部分上，痛起來會痛到想換回 Standard。

選之前花 30 分鐘檢查這 5 題：

1. 我的 DaemonSet 裡有沒有 privileged / hostPath / hostNetwork？（有的話，再查一下它在不在 Autopilot 的 allowlist 裡）
2. 我的叢集使用率預期會超過 65% 嗎？
3. 我有沒有需要 < 100m CPU 的 sidecar 或 CronJob？
4. 我需要最新 GPU / TPU 或特殊 CPU 平台嗎？
5. 我的 workload 能接受 Pod 啟動多等 60 秒嗎？

這五題答完，Autopilot 適不適合你，心裡就有答案了。

---

延伸閱讀

• GKE 入門：Standard vs Autopilot 完整比較（本站）
• Autopilot overview（官方文件）
• Autopilot 最低與最高資源 requests（各 compute class 門檻與 bursting 差異）
• 在 Autopilot 執行特權工作負載（WorkloadAllowlist 機制）
• Autopilot 安全限制（sysctls、hostPath、NodePort 等預設限制）
• Autopilot GPU 支援（支援機型與最低版本）
• Autopilot compute classes（選機型的唯一介面）