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）計費 | 幾乎沒有 bin-packing 空間 |
浪費的代價更高
在 Standard 上，你的 requests 只是 scheduler 放 Pod 的依據，實際計費是整台 VM。把 request 設寬鬆一點防 OOM，沒差，反正節點錢照付。
在 Autopilot 上，你宣告多少 request 就付多少錢。工程師為了保險把 memory request 從 256 MiB 設成 1 GiB，帳單就是直接乘以 4 倍。
最小資源限制
Autopilot 對 Pod 有硬性的最低資源門檻：
- 一般 Pod：0.25 vCPU + 0.5 GiB memory
- DaemonSet Pod：依官方文件，最低約每 Pod 10 mCPU + 10 MiB memory（不支援 bursting 的叢集）或 1 mCPU + 2 MiB（支援 bursting 的叢集），遠低於一般 Pod 門檻
- Balanced / Performance compute class：門檻更高
如果你跑大量極度輕量的微服務、sidecar（Envoy、log shipper）、或每分鐘執行幾秒的 CronJob，這些被墊到下限的資源全部要付錢。在 Standard 上你可以把 sidecar 設 10m CPU 沒人管你；在 Autopilot 上，系統悄悄墊到 0.25 vCPU 然後照這個數字收錢。
成本交叉點
實際上，當叢集整體使用率衝過 65-70%，Standard 就會明顯比 Autopilot 便宜。白話講：如果你本來就會調 cluster autoscaler + VPA + node affinity，Standard 通常比較省。
二、系統權限與底層控制力受限
為了維持多租戶的穩定與安全，Autopilot 預設啟用一長串限制。
無法取得節點層級的控制權
- ❌ 不能
gcloud compute ssh進節點 - ❌ 不能自訂節點的 OS image（Custom Node Image）
- ❌ 不能修改 kernel 參數（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）、主機通訊埠（hostPort）、hostPID、hostIPC - 掛載大部分
hostPath路徑 - 早期版本：自訂
MutatingWebhookConfiguration改到kube-system
對外暴露的方式也要留意：NodePort 型別的 Service，Autopilot 其實是支援的，但透過 NodePort 暴露的服務沒辦法從 VPC 外部（例如網際網路）存取。要對外開的話，請改用 LoadBalancer 或 Ingress（官方甚至建議用 NodePort 取代 hostPort）。
第三方工具相容性
這是最常見的踩雷點。如果你用的 DaemonSet 需要深度的 Linux capabilities，或要掛特定的 host 目錄，下面這些都得當心：
- 某些 APM / 資安代理（Falco、Sysdig 部分功能、舊版 Datadog agent）
- 需要改 iptables 的 service mesh init container（要走 Google 認可的 Cilium dataplane v2）
- 自訂 CSI driver（要等 Google 認證）
- 需要操作 node 行為的 Operator（例如某些資料庫 operator 要調 sysctl）
選 Autopilot 前，把你現在所有的 DaemonSet 與 PSP / Pod Security Standard 需求列出來，一個一個驗證能不能跑。
三、擴展延遲與「冷啟動」效應（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 年，A100、H100、L4、部分 TPU Autopilot 都已支援，但新硬體通常 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 叢集強制啟用 Cloud Logging 跟 Cloud Monitoring 的 system component logs，關不掉。一個中型叢集，每月光 log ingestion 就能輕鬆吃掉幾百到上千美金。Standard 還可以選擇性關掉 workload logs 來省錢，Autopilot 這扇門直接是焊死的。
版本升級控制權較少
Autopilot 一樣可以選 release channel、設 maintenance window 跟 exclusion，但節點升級是 Google 說了算。如果你有「就是不想升」的合規工作負載，這種你管不到的地方，就是實打實的風險。
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 是必須的妥協的情境
- 需要運行極度特製化的 DaemonSet 或核心級別權限（privileged、hostPath、hostNetwork）
- 應用程式有極端流量峰谷，且對擴容冷啟動時間零容忍
- 團隊有能力做深度資源最佳化，希望透過高密度 bin-packing 極致壓縮帳單
- 需要最新 GPU / TPU / 冷門 CPU 機型，或 Alpha / Beta 功能
- 合規要求你必須控制版本、控制 node-level 設定
一句話結論
Autopilot 不是「更好的 GKE」，它是「不同取捨的 GKE」。 它把「管節點的麻煩」換成「失去細節控制權」。對 80% 的 workload 這筆交易很划算，對剩下 20% 的 workload 會讓你痛到換回 Standard。
選之前花 30 分鐘檢查這 5 題：
- 我的 DaemonSet 裡有沒有
privileged/hostPath/hostNetwork？ - 我的叢集使用率預期會超過 65% 嗎？
- 我有沒有需要 < 100m CPU 的 sidecar 或 CronJob？
- 我需要最新 GPU / TPU 或特殊 CPU 平台嗎？
- 我的 workload 能接受 Pod 啟動多等 60 秒嗎？
這五題答完，Autopilot 適不適合你，心裡就有答案了。
延伸閱讀
- GKE 入門：Standard vs Autopilot 完整比較（本站）
- Autopilot overview（官方文件）
- Autopilot workload configuration limits（被禁用功能完整表格）
- Autopilot compute classes（選機型的唯一介面）