Google Cloud 前兩天推出了 GKE Autopilot，其官方部落格 Introducing GKE Autopilot: a revolution in managed Kubernetes[1] 稱之為革命性的託管 Kubernetes 服務。但其“革命性”的亮點都有哪些呢？

GKE Autopilot 亮點

推出 Autopilot 之後，GKE 支援兩種操作模式，包括標準模式和 Autopilot 模式。這兩者的主要區別在於 Autopilot 自動管理節點，而標準模式還需要使用者去管理節點。

GKE Autopilot 模式圖示如下：

GKE 標準模式圖示如下：

Autopilot 會預先配置和管理整個叢集的底層基礎架構，包括

根據工作負載要求獲取適合生產環境的叢集省去節點管理的開銷按實際使用的資源付費，如 vCPU、記憶體和磁碟使用量等內建 GKE 最佳實踐，提高安全性提高了工作負載可用性GKE Autopilot 限制

為了支援 Autopilot，並確保叢集功能不受被使用者操作破壞，Autopilot 也引入了很多限制，比如不支援 Google Group RBAC、Cloud Build、Cloud Run、Istio 等等。在具體的 Kubernetes 應用上，也引入了諸多的限制：

節點鎖定，節點對應的虛擬機器對使用者隱藏，並禁止對節點的特權操作，比如不允許使用 HostPort、HostNetwork 等，也不允許 HostPath 儲存卷的寫操作；不允許使用特權容器，容器內不允許 CAP_NET_RAW（ping 會失敗）。kube-system 名稱空間鎖定，mutating admission webhook 鎖定，很多依賴於 Webhook 的容器無法正常部署。為了確保根據資源請求進行自動擴充套件，所有容器強制增加資源請求配置。

GKE 叢集建立後，可以在其詳細資訊頁面看到其他禁止的特性：

更多的限制可以參考 GKE Autopilot 文件[2]。

小結

從 GKE Autopilot 的特性上可以看出，Autopilot 在託管 Kubernetes 控制平面的基礎上，把節點的管理也全部託管起來，實際上也就相當於是一個提供 Kubernetes API 的 PAAS 服務，或者也可以稱之為 Serverless Kubernetes。

因為需要託管並鎖定節點，為了避免使用者操作引發的問題，GKE Autopilot 也引入了很多 Kubernetes API 上的限制，並捨棄了原本豐富的功能特性。對使用者來說，很多已有的應用（比如 Helm Charts）可能都需要做一定的修改才可以在 GKE Autopilot 上面應用。

實際上，國內的幾大公有云也早已推出了類似的服務，但在實現方式上也有一些不同。比如阿里雲的 ASK 是基於 Virtual Node 實現的，相對於 GKE Autopilot 來說有更多的限制。

總之，同時託管節點和控制平面的好處是顯而易見的，節省了使用者的 SRE 和運維成本，但代價也是犧牲了靈活性。既然主流的公有云平臺都提供了類似的服務，提供更多的 Kubernetes 原生功能特性以及提供更豐富的靈活性就會具有更大的競爭優勢，未來我們應該會看到更多類似的演進。

參考資料

[1] Introducing GKE Autopilot: a revolution in managed Kubernetes: https://cloud.google.com/blog/products/containers-kubernetes/introducing-gke-autopilot

[2] GKE Autopilot 文件: https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview