GKE Autopilot 教學―輕鬆管理 K8s，加快軟體開發流程

Google Kubernetes Engine（GKE）的 Autopilot 模式是什麼，和 Standard 模式有什麼不同？這次 Cloud Ace 的專業雲端架構師將透過 GKE Autopilot 教學實作示範它如何替工程師省下多餘的麻煩，更專注於軟體開發。

Google Kubernetes Engine Autopilot 模式教學說明

繼上次為大家解說了容器管理工具 Kubernetes（K8s）於 GCP 上的服務後，今天要帶大家透過 Google Kubernetes Engine（GKE）的 Autopilot 模式，實際操作被廣泛使用的三層式容器架構部署流程，並透過壓力測試工具模擬大流量狀態時，GKE Autopilot 模式的動態調配表現。在開始之前，還不知道 GKE 是什麼的朋友們可參考《【K8s 是什麼】比較 Docker 容器、K8s 和 GKE 的架構與優勢》快速了解雲端容器服務喔。

GKE Autopilot 模式介紹

GKE Autopilot 模式是 Google 歸納多年叢集（Cluster）管理經驗後，以期望能減少管理成本、優化服務效能作為出發點所設計的全託管式容器編排服務。除了 GKE Standard 模式所託管的 Cluster 外，Autopilot 模式也將 K8s 的運算資源節點（Node）加入託管服務的範疇中，使用戶能在不調配資源控管的情況下，專注於產品開發並提高生產價值。

GKE Autopilot Cluster 的三層式微服務架構

如下圖所示，本文將帶大家建立一個部署在 GKE Autopilot Cluster 的三層式服務系統，並整合使用 GCP 上的 HTTP(s) Load Balancer 與 Cloud SQL 服務，藉此展現 GKE 強大的網路整合能力。而為了體現 Autopilot 模式的 Node Auto Provisioning 功能，本次也會透過壓力測試來展示 Node 動態資源調配的表現。

GKE Autopilot 實作前置準備：容器服務上雲流程

本次的部署操作將會使用到多個範例程式碼，並完整呈現從建置 Docker Image、上傳至 Artifact Registry，到最後部署於 GKE Cluster 的過程。相關範例檔案大家可至 Github 連結複製並透過 Cloud Shell 執行，這邊就話不多說馬上開始吧！

部署檔案結構

大家下載完 Github 上的範例檔後，會看到下方的檔案結構。在這份檔案中，有兩個子目錄分別對應前端（nginx）與後端（api）服務，而子目錄中各別有著自己的程式碼與 Dockerfile 設定檔。讀者可將各別檔案內有附註修改的欄位調整成符合自己專案的設定。

project-folder
            |___nginx
                    > default.conf
                    > Dockerfile  
            |___api
                    > db.py
                    > main.py
                    > Dockerfile
                    > wsgi.ini
                    > requirements.txt
            > docker-compose.yaml
            > nginx.yaml
            > api_hpa.yaml

如上所提，此次會使用 Cloud SQL 作為資料庫，所以範例（db.py）裡使用的是 Cloud SQL 的 Internal IP，代表我們與雲端代管服務的溝通是透過內部網路連線，而這也是 GKE 相當便利的網路整合服務。這次不會帶大家建立 Cloud SQL，如欲自行建立，記得在建立時將 GKE Cluster 所在 VPC 與其連結，才能正常利用內網溝通。

而在主目錄下，分別有著對應前後端服務在部署時所需的 nginx.ymal、api_hpa.yaml 描述檔，與透過 Docker Compose 測試容器服務的 docker-compose.yaml 描述檔，讀者可自行於主機環境測試服務連線狀態時使用。

開通並註冊 Artifact Registry

了解完要操作的檔案內容後，我們接著要來創建 GCP 上用來存放容器映像檔的 Artifact Registry。按照慣例，我們需先啟動 Artifact Registry 的 API，才能使用其提供的服務。完成後透過以下步驟就能快速創建 Docker Image 專用的 Repository 了。

Artifact Registry 創建步驟：
1. 點選 CREATE REPOSITORY
2. 於 Format 選擇 Docker
3. Location Type 選擇 Region
4. Region 選擇 asia-east1 (Taiwan)
5. Encryption 選擇 Google-managed encryption key
6. 點擊 CREATE 完成創建

創建完 Docker Repository 後，我們還不能直接使用上傳 Image 的服務，必須先透過下方指令進行 gcloud CLI 的身份驗證，如此一來後面才能於 Cloud SDK 所在終端機使用 Docker 指令將 Image 上傳至 Artifact Registry 。

gcloud auth configure-docker asia-east1-docker.pkg.dev

如果不確定當前使用的終端機是否有對應的設定，可透過下方指令查詢當前 Docker 使用環境的認證狀態。這裡要注意當我們有多個 Region 的 Repository 時，會以 CredHelpers 物件的鍵值方式條列，只要確認我們希望上傳到的 Repository 有在其中即可。

cat ~/.docker/config.json

Docker Image 建置並上傳至 Artifact Registry

設置完相關認證後，接著就可以在作業的終端環境建置與上傳 Docker Image 了。建立 Docker Image 需透過設定 Dockerfile 達成，所以建議先將當前作業目錄切換為 Dockerfile 所在的目錄，並透過下方指令執行建置。要注意的是為了上傳至剛剛創建的 Repository，我們需將 Image 透過標籤的方式指定對應路徑，詳細格式如下，讀者可依自己的環境調整。

docker build -t asia-east1-docker.pkg.dev/<Project ID>/<Repo Name>/<Image Name>:<Version> .

創建完成的 Image 會帶有上傳目的地的路徑資訊與版本號，這時我們可透過下面的 push 指令將剛剛創建的 Image 上傳至先前建立的 Repository。其中一個蠻有趣的點是，由於 Docker Image 是以堆疊方式建構的，所以上傳時會看到 Image 一層一層地上傳，直到全體完成作業，因此如果其中有幾層已經上傳過的話，整體速度會快上許多。

docker push asia-east1-docker.pkg.dev/<Project ID>/<Repo Name>/<Image Name>:<Version> 

再來我們回到 Artifact Registry，可看到 Image 已成功上傳至 Repository，上面顯示了創建與更新的日期，代表每一次的上傳作業就像更新一樣不會完整覆蓋，而是在不同部分做版本紀錄。所以我們點擊進入 Image 時，會看到每個上傳版本都條列在清單上，方便我們版本回滾更新時使用。

GKE Autopilot 實作步驟一 ：建構 VPC-Native Autopilot Cluster

前面我們完成了容器服務部署的前置作業，所以接著就要來創建 Autopilot 模式的 GKE Cluster。在開啟 GKE API 後，我們可直接透過 Console UI 介面來創建 Autopilot Cluster。可以看到畫面上會提示 Autopilot 模式與 Standard 模式的差異，簡單來說兩者最大的差異就是計費方式，大家可以看到 Autopilot 模式是以 Pod 為計費單位，也就是所謂的用多少付多少。相對的 Standard 模式是依定義的 Node 數量計費，可以想見如果要精算使用費會有多複雜。

接著我們來設置 Autopilot Cluster，由於 Autopilot 要確保服務的 High Availability（HA），所以 Cluster 的類型至少需選擇單一 Region。網路的部分各位可自行選擇要 Public 或 Private Cluster，對應的影響是創建的 Node 是否有外部 IP，這裡建議使用 Private Cluster 以提高安全性。

而在選擇 Private Cluster 後，可勾選下方的允許透過外部 IP 存取 Control Plane，使用外部 IP 呼叫 Cluster 的 kubectl API 。接著大家可自定義 Control Plane 的使用網段，這裡要特別注意不要與當前使用的網段重疊，但既然我們本次的目的是體驗 Autopilot 全代管的服務，這裡可以留白讓 GKE 為我們設定。

為進一步確保 Cluster 的安全性，GKE 可使用白名單限縮外部存取的來源 IP。只要開啟 Control Plane 授權網路選項，輸入希望允許的 IP range 就完成了。而在 VPC 網路環境的設定上，由於這次示範的三層式網路架構會用到 Cloud SQL，所以要記得選取與 Cloud SQL 連結的 VPC 網路環境，確保能正確連線。最後有關 Pod 與 Service 的網段規劃，只要保持預設即可。

除了上述的設置，GKE 也提供自定義的維護時段設置，讓我們可以安排最不影響用戶的時段讓 GCP 的 Site Reliability Engineer（SRE）進行維護。最後，GKE 提供了與 GCP 雲端資安服務整合的客製化選項，讓我們的容器服務可透過 GCP Key Management Service（KMS）加密 K8s 的 Secret 與 Boot Disk，增加應用層級的資料安全性，這次先維持原樣即可。

依照上述步驟設置完 Autopilot Cluster 後，我們快速比較一下 Standard 與 Autopilot 模式建立的 Cluster。如下圖所示，創建 Standard Cluster 時必須選定要使用的 Node 資源，讓 GKE 為我們創建背後運行的 VM，在 Compute Engine 頁面可看到對應的資源被創建出來。

相對的，使用 Autopilot 模式時，創建完成的 Cluster 在沒有部署服務的情況下，並不會創建任何運算資源，且因為 Node 身為代管環節之一，所以服務部署後依然不會出現在專案的 Compute Engine 頁面中，也就不會混淆專案的資源管理作業。

GKE Autopilot 實作步驟二 ：存取 GKE Cluster 並部署服務

完成創建後，接著要來存取 Cluster 的 Control Plane 並部署該 Cluster。如同下列的 Cloud SDK 指令，我們需透過指定 Cluster 名稱與其所在 Region 來獲得存取憑證，之後才能透過 kubectl API 執行部署。這裡會透過 IAM 驗證用戶權限，所以讀者在執行指令前，記得先確認當前的用戶是否具有可操作 Cluster 的 IAM Roles。

gcloud container clusters get-credentials <ClusterName> --region=<Region>

獲取憑證後，我們就能直接透過 kubectl API 指定要部署的 YAML 描述檔。如同前述，各位可透過下列指令以先前下載的 nginx.yaml 與 api_hpa.yaml 檔進行部署。

kubectl apply -f <Filename>

但在執行前，需確認該描述檔內指定的 Image 已修改為前面上傳到 Artifact Registry 的 Image 名稱，完成後即可在 Console UI 上看到對應的服務被條列出來。值得一提的是，在這步可以看到 Autopilot Cluster 的 vCPU 與 Memory 確實增加了。

部署完成後，我們可透過 Postman 對我們剛剛建立的 Ingress IP 進行 API 測試。如下圖所示，我們以 HTTP 協定對 users 目錄進行 POST 請求，可以看到發出的資料被正常紀錄下來。接著透過 GET 請求對 users 目錄進行呼叫，就能看到存放在 Cloud SQL 的資料被條列出來，代表我們的部署作業成功了！

GKE Autopilot 實作步驟三 ：以 Siege 對 Autopilot Cluster 做壓力測試

接著我們要對 Cluster 進行壓力測試，看看 Autopilot 模式面對龐大流量的表現如何。這次選用的壓力測試工具是 Siege，這裡使用 500 個併發，在不設定次數的狀況下持續對我們的 API Server 發出請求，時間長達 653 秒。可以看到這近 10 萬次的請求成功率達到 99.94 ％，算是非常不錯的表現。

siege -c <Concurrent Counts> -v http://<External IP>/<API Path>

以 GKE Console UI 即時觀察服務狀態，可看到流量超出目前使用的資源時，透過先前設置的 HPA，GKE Deployment 會自動為我們擴展 Pod 數量。而同一時間，Autopilot 模式確保我們的 Node 有足夠的資源可提供給 Pod 擴展。

如果各位有注意到，Pod 擴展的期間由於 Autopilot Cluster 尚在準備新的 Node 資源，所以會看到 Does not have minimum availability 的錯誤訊息，這部分只需稍作等待即可，不用擔心。

流量恢復正常後，GKE Deployment 會自動將 Pod 縮減回原本的數量，而 Autopilot Cluster 也會將 Node 資源回復到初始狀態。比照前面的 Siege 壓力測試數據，可以看到在快速的流量變化下，Autopilot 模式會為我們處理好所有與 Node 相關的運算資源，讓用戶在無感的狀況下正常存取部署的服務。此外我們也僅需為實際有使用到的資源付費，再也不用擔心要如何預估 Node 資源才不會產生閒置虛耗的問題。

以上就是 GKE Autopilot 模式的教學實作，大家對文中內容有任何問題，或想看其他實作教學都可留言告訴我們。 最後，如果想更了解 GCP 或有技術服務相關需求也都歡迎聯絡我們獲得更進一步的資訊。

▋延伸閱讀：

・【K8s 是什麼】比較 Docker 容器、K8s 和 GKE 的架構與優勢
・【K8s 教學】第一次用 Google Kubernetes Engine 就上手
・[DevOps實作] 使用 Google Cloud 全代管服務達成 CI/CD
・[DevOps實作] GitLab部署asp.Net Core到 Kubernetes Engine 達成 CI/CD
・使用 Cloud Run 部署一個 API Server