GKE 入門：在 Google Kubernetes Engine 上部署容器應用

手上有一個容器，不代表下一步就該建 Kubernetes 叢集。如果只是讓一個 HTTP API 上線，Cloud Run 往往更省維運力氣；如果團隊已經用 Kubernetes 管理部署、服務發現和排程，GKE 才開始有明確的理由。

這篇不從一長串產品功能背起。我們先弄懂 Pod、Deployment 和 Service 分別在做什麼，再部署一個小應用。跑通之後，回頭看 Standard、Autopilot、擴縮與工作負載身分要怎麼選。

GKE 管控制平面，應用還是你管

Kubernetes 的工作是維持你宣告的狀態。例如你說要兩個應用副本，它就會試著讓兩個 Pod 跑起來；其中一個失效，會重新建立。GKE 幫你管理 Kubernetes 控制平面，並整合 Google Cloud 的網路、儲存和監控。這不會替你決定程式是否健康、該給多少記憶體，或資料庫密碼要交給誰。

Standard 和 Autopilot 的主要差別是誰照顧工作節點：

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

Autopilot 不是「入門版 GKE」，Standard 也不自動代表效能比較好。GPU、特定機型等需求，Autopilot 也有支援的選項；要對照實際硬體、區域和設定。官方模式比較與Autopilot 概述比「GPU 就選 Standard」可靠。

費用也沒有固定的交叉點。GKE 定價目前把一般用途的 Autopilot 工作負載按 Pod 申請的資源計費；若指定特定硬體，可能改採節點型計費。Standard 則要估節點用量；兩者都還可能有叢集管理費、負載平衡器和網路費。別拿「節點使用率到 70% 就一定比較便宜」當作選型規則。先用自己的 Pod requests、運行時間與流量估價。

三個物件，先弄懂誰管誰

Pod 是 Kubernetes 執行容器的基本單位。它可能被重新建立，IP 也可能改變，所以不要把某個 Pod 的 IP 當成服務網址。

Deployment 說明應用要跑哪個映像、幾個副本，以及更新時怎麼替換。它會透過控制器維持預期數量，但「Pod 在跑」不等於「程式能接請求」。上線時還要配置合適的 readiness probe，讓未準備好的 Pod 不被當成可服務的端點；資料庫等有狀態工作負載也不該一律套用無狀態 Deployment 的做法。

Service 用標籤找到一組 Pod，提供穩定的存取方式。預設的 ClusterIP 供叢集內部使用；型別設成 LoadBalancer，GKE 會建立對應的雲端負載平衡資源，讓外部可以連進來。這個入口會產生費用，也可能讓原本不該公開的服務暴露在網路上。GKE 的 Service 網路說明值得在上線前看一次。

常見的三種 Service 類型，後一種都包含前一種的能力：

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

把這三個關係記成一句話就好：Deployment 管 Pod，Service 找 Pod。Ingress 或 Gateway 是再上一層的 HTTP 路由，不是 Pod 的替代品。

實作：部署一個小型 Web 服務

這個練習會建立叢集和對外的負載平衡器，會產生費用。請先確認專案已啟用計費、具備建立 GKE 叢集的權限，並在練習後清掉資源。下面用 asia-east1 示範；正式環境的區域應依使用者、資料位置、可用功能與費用決定。

先按官方建立 Autopilot 叢集的流程準備好專案，再執行：

gcloud services enable container.googleapis.com
gcloud container clusters create-auto hello-cluster --region=asia-east1
gcloud container clusters get-credentials hello-cluster --region=asia-east1

接著把這份設定存成 hello.yaml。範例映像是 Google Cloud 官方入門教學使用的 hello-app；示範副本數為兩個，Service 透過標籤 app: hello-server 找到它們。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello-server
  template:
    metadata:
      labels:
        app: hello-server
    spec:
      containers:
        - name: hello-app
          image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 250m
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /
              port: 8080
            periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: hello-server
spec:
  type: LoadBalancer
  selector:
    app: hello-server
  ports:
    - port: 80
      targetPort: 8080

kubectl apply -f hello.yaml
kubectl rollout status deployment/hello-server
kubectl get pods
kubectl get service hello-server

EXTERNAL-IP 可能要等幾分鐘才出現。拿到位址後用瀏覽器開啟 http://EXTERNAL-IP，應看到 hello-app 回應。這個練習用 HTTP 是為了看清 Service 的作用；正式對外網站還要規劃 HTTPS、網域、存取控制與監控。

如果 Pod 沒起來，先看 kubectl describe pod POD_NAME 裡的事件，再看 kubectl logs POD_NAME。若 Pod 正常卻連不到，檢查 Service 的 selector 是否和 Pod 標籤一致、targetPort 是否真的是容器監聽的埠。遇到問題先沿流量路徑查，別一開始就重建整個叢集。

練習結束可刪掉示範資源；gcloud container clusters delete 會刪除整個 hello-cluster，只在確認它是這次練習建立、沒有其他工作負載時執行：

kubectl delete service hello-server
gcloud container clusters delete hello-cluster --region=asia-east1

需要更多副本？先看 Pod，還是節點不夠

部署檔裡的 replicas: 2 是固定副本數。如果流量有明顯高低峰，可以再設定 Horizontal Pod Autoscaler（HPA），依觀測到的指標調整副本數。以下指令的 70% 代表平均 CPU 使用量相對於 CPU request 的目標比例，不是「整台機器 CPU 到 70%」；範例 Deployment 已設定 CPU request，因此有計算基準。GKE HPA 文件也說明其他指標與限制。

kubectl autoscale deployment hello-server --cpu=70% --min=2 --max=5
kubectl get hpa

--cpu 是 kubectl 1.34 起的寫法，舊旗標 --cpu-percent=70 已開始棄用但仍可使用；手上的 kubectl 若不認得 --cpu，就改用舊旗標。% 不能省：--cpu=70 會被當成 70m（平均 70 milliCPU），不是 70%。GKE 官方文件的範例仍寫 --cpu-percent，兩種寫法都要認得。

HPA 增加的是 Pod 數；若節點放不下新 Pod，還需要節點容量跟上。Autopilot 會管理節點供應，Standard 則要檢查節點池與自動擴縮設定。Vertical Pod Autoscaler（VPA）處理的是單個 Pod 需要多少 CPU、記憶體，並非另一個「加副本」按鈕。先用實際流量和指標驗證，別因為文章給了 70 就直接套到正式環境。

更新版本時，可看 kubectl rollout status deployment/hello-server 是否完成；回退可用 kubectl rollout undo deployment/hello-server。但回退能否安全，還取決於資料庫變更、相容性和健康檢查。Kubernetes 能調整容器版本，不會替你逆轉資料變更。

對外入口：Service、Ingress 不要混著叫

上面的 LoadBalancer Service 適合看懂「一個服務對外開一個入口」。GKE 會替它建立 Layer 4 的網路負載平衡器。若要根據網址或網域把 HTTP(S) 請求送到不同 Service，則評估 GKE Ingress 或 Gateway API；Ingress 會建立 Layer 7 的應用程式負載平衡器。是否較省錢不能只看「幾個 Service 共用入口」，還要依負載平衡器資源和流量估價。

有個細節很容易被通用 Kubernetes 教材帶錯：Kubernetes 已棄用 kubernetes.io/ingress.class annotation，但 GKE Ingress 控制器目前仍用它辨識 gce 或 gce-internal。只設 spec.ingressClassName 不等於指定 GKE Ingress；官方控制器行為表列得很清楚。真的要設定入口時，先決定外部還是內部、憑證如何管理，再照該控制器文件寫設定。

Pod 要讀 Cloud Storage，別把 JSON 金鑰塞進映像

假設 hello-app 換成了圖片處理服務，需要讀某個 bucket。把服務帳號 JSON 金鑰放進容器映像或 Kubernetes Secret，會多出一把要分發、輪替和防洩漏的長效憑證。GKE 的 Workload Identity Federation（原 Workload Identity）讓 Kubernetes 工作負載用自己的身分向 Google Cloud API 取得授權，不必攜帶那把金鑰。

實作順序是：先確認叢集啟用 Workload Identity Federation；為應用建立專用的 Kubernetes ServiceAccount；在 Deployment 指定它；最後把讀取權限授在需要的資源範圍。現在可以直接把 IAM 權限授予工作負載身分；遇到服務限制時，也能選擇透過 IAM service account impersonation。官方設定指南把兩條路徑分開說明。不是每個情況都非得先建立一個 Google IAM 服務帳號再做 annotation。

授權完成後仍要測試「讀得到指定 bucket、讀不到其他 bucket」，而不是只看 Pod 會不會啟動。身分安全最容易被漏掉的地方，是角色授在整個專案，實際只需要一個儲存資源。

成本與選型，最後再一起算

GKE 的帳單不只有 Pod 或 VM：叢集管理、負載平衡器、儲存、網路，以及監控資料都可能計費。Autopilot 一般工作負載要注意 requests，因為過度申請會增加成本；而平台也可能依最小值與比例調整 requests。Standard 要看節點空間是否閒置、擴縮是否設好，還要算團隊維護節點的時間。這些比拿別人的每月帳單比較有用。

可中斷工作如批次處理，可評估 Spot Pod，但它可能隨時被終止，應先確認工作能重試。若真的要用 Autopilot Spot Pod，依官方設定在 Pod 的 nodeSelector 或 node affinity 指定 cloud.google.com/gke-spot=true。折扣和可用容量則要以當期價格與工作負載測試為準。

回到最初的問題：一個容器化 API，如果沒有 Kubernetes 的明確需求，可先試 Cloud Run；已有 Kubernetes 資源、部署流程或需要它的排程和網路能力，再試 GKE Autopilot；節點與底層環境需要更深控制，才往 Standard 比較。這不是三段「成熟度」，而是三種要自己承擔的維運範圍。ACE-203 的部署平台比較有更完整的取捨。

準備 ACE 時，先能說清四件事就夠：Pod 跑容器、Deployment 管副本、Service 提供穩定入口、HPA 依指標調副本。接著再分清 Autopilot 和 Standard 的節點責任，以及 Workload Identity Federation for GKE 為什麼能少用長效金鑰。題目一旦變成真實系統，記得把費用、故障情境與資料權限補上。

下一課 GCP-106：GCP 監控與日誌入門會接著看如何從指標與日誌找出服務問題。