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

Kubernetes 是 Google 開源給世界的禮物——而 GKE 是 Google 自家把它用得最好的地方。

你已經學過用 Compute Engine 部署 VM（GCP-103）、設計高可用架構（ACE-202）、選無伺服器平台（ACE-203）。這一篇來談容器編排，它是現在雲端應用最主流的部署方式。

GKE（Google Kubernetes Engine） 是 GCP 的託管 Kubernetes 服務。Kubernetes 本來就是 Google 做的，跑在 GKE 上自然最原生、也最穩。

這篇從 VM 為什麼進化到容器講起，帶你把 Standard 跟 Autopilot 怎麼選、Pod / Deployment / Service / Ingress / HPA 這五個核心概念、還有 Workload Identity 這個考試最愛考的安全做法一次搞定，最後再把 GKE 跟 Cloud Run、App Engine 的選型和成本優化也一併談清楚。

---

一、為什麼需要 Kubernetes？

從 VM 到容器的演進

傳統做法：VM 部署

開發者電腦 → 手動設定環境 → 部署到 VM → 祈禱「在我電腦上能跑就好」

問題：「明明在我本機可以跑，為什麼到 Production 就壞了？」

容器（Container）解決了環境一致性問題

應用程式 + 依賴套件 + 設定檔 → 打包成 Docker Image → 任何地方都一樣跑

容器讓「在我電腦可以跑」真正等於「在任何地方都可以跑」。

多容器的挑戰：為什麼需要 Kubernetes？

當你的應用從 1 個容器變成 10 個、100 個服務時，問題就來了：

挑戰	描述
服務發現	容器的 IP 會變動，其他服務怎麼找到它？
負載平衡	流量如何分配到多個容器副本？
自動恢復	容器掛掉了，誰來自動重啟？
滾動更新	如何不停機地更新新版本？
資源排程	哪個容器在哪台機器上跑最有效率？

Kubernetes 就是用來解決這些問題的容器編排系統。你可以把它想成「容器的作業系統」，負責管理一整個叢集（由多台機器組成）裡所有容器的生命週期。

GKE = Kubernetes 的全託管版本

自己架 Kubernetes 真的很麻煩，光是 Control Plane（控制平面，叢集的大腦）就要自己管，再加上網路設定、版本升級一大堆雜事——這些你不用懂內部細節，知道「有人要顧、而且很煩」就夠了。

簡單說，自己架要顧的那一大堆，它都幫你扛了：

• 自動安裝並維護 Control Plane（控制平面，叢集的大腦，負責排程與管理）
• 自動升級 Kubernetes 版本
• 整合 GCP 網路、儲存、IAM
• 內建監控（Cloud Monitoring + Cloud Logging）
• 自動修復不健康的節點

---

二、GKE 的兩種模式：Standard vs Autopilot

GKE 提供兩種運作模式，2023 年 4 月後 Autopilot 成為官方推薦的預設選項。

核心差異一眼看懂

比較面向	Standard	Autopilot
節點管理	你管理節點（VM）	Google 管理節點
計費方式	按節點（VM）計費	按 Pod 資源計費
設定彈性	完全控制（自定義核心、客製化驅動）	受限（但含常見 GPU，能滿足 90% 需求）
安全預設值	需手動設定	預設已強化
SSH 到節點	可以	不行
Spot Pod	支援	支援（60-91% 折扣）
適合對象	進階使用者、特殊需求	大多數生產場景

深入了解計費差異

Standard 計費邏輯：

你建立 3 個 n2-standard-4 節點（不管 Pod 用了多少資源）
費用 = 3 × n2-standard-4 的 VM 費用

就算節點只用了 30% 的資源，你還是得付 100% 的錢。

Autopilot 計費邏輯：

你的 Pod 申請了 1 vCPU + 4GB RAM
費用 = 實際使用的 CPU + 記憶體費用（按秒計算）

成本交叉點：當叢集整體資源使用率超過 60-70%，Standard 就開始比 Autopilot 便宜。但大多數工作負載其實到不了這個使用率，所以一般來說 Autopilot 反而更省錢。

Cluster 費用

無論 Standard 還是 Autopilot，每個叢集都有管理費：

• 每小時 $0.10（≈ NT$3/小時）
• GCP 提供每月約 $74.40 的免費額度（相當於一個免費叢集）

選擇建議

你的需求是...
    ↓
需要客製化驅動版本、還沒被 Autopilot 支援的新型硬體（高速 NVMe 之類）、自定義 Linux 核心？
    → Standard

需要 SSH 進節點做 debug？
    → Standard

其他大多數情況（Web 應用、API、微服務）？
    → Autopilot（推薦）

📝 考場提點

Standard vs Autopilot 是 ACE 的高頻選型題，記住題目裡的關鍵字就能秒選。看到 自定義機器核心、SSH 進節點 debug、客製化驅動版本、特殊硬體（高速 NVMe 之類） → 選 Standard，因為這些都需要你直接掌控底層節點。注意 GPU 本身不是自動選 Standard 的訊號——Autopilot 已支援 L4、A100、H100 等常見 GPU，題目沒特別強調「客製化驅動」或「新型加速器」的話，Autopilot 就能滿足。看到 「最小化管理負擔」「大多數時間流量低」「自動擴縮」「Google 幫我管節點」 → 選 Autopilot。另外順手記一個常被當陷阱的點：Autopilot 一定是 regional（用 --region，不能用 zone），題目若強調跨區高可用又要少管理，答案多半就是它。

💡 補充：GKE Enterprise（原 Anthos） Google 在 2025 年 9 月收掉了獨立的 GKE Enterprise 付費層級，把 Fleet 管理、Config Sync、Policy Controller、Connect Gateway 這類多叢集治理功能都併回標準 GKE，免費內建，不用再額外升級付費層。如果你的組織要跨多個叢集、或混合雲環境統一管理，直接用標準 GKE 就有這些能力。目前仍需另外計費的是 Cloud Service Mesh、Backup for GKE、Multi-Cloud cluster management、Multi-cluster Gateway 這幾項比較進階的加值服務。ACE 考試通常不會考很深，但別再把「多叢集管理」直接跟「一定要額外付費」畫上等號。

---

三、Kubernetes 五大核心概念

動手之前先把這五個概念搞懂，不然你很容易淹沒在一堆設定檔裡。

3.1 Pod：最小部署單位

Pod 是 Kubernetes 中最小的可部署單位，通常包含一個容器（有時也有多個緊密相關的容器）。

# Pod 範例
apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
    - name: my-app
      image: nginx:1.27
      ports:
        - containerPort: 80

重要特性：

• Pod 有自己的 IP，但這個 IP 是臨時的（Pod 重啟後 IP 會變）
• Pod 是一次性的——不要直接建立單一 Pod，而是用 Deployment 管理
• 同一個 Pod 內的容器共用網路和儲存

3.2 Deployment：管理多個 Pod 副本

Deployment 負責「讓指定數量的 Pod 一直跑著」。

# Deployment 範例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3 # 要跑幾個副本
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: us-docker.pkg.dev/my-project/my-repo/my-app:v1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: '250m'
              memory: '256Mi'
            limits:
              cpu: '500m'
              memory: '512Mi'

Deployment 的能力：

• 如果有 Pod 掛掉，自動重新建立
• 滾動更新（Rolling Update）：逐步替換舊版 Pod，不中斷服務
• 回滾（Rollback）：如果新版有問題，一鍵回到上一版

# 更新 Deployment 的容器映像版本
kubectl set image deployment/my-app-deployment my-app=us-docker.pkg.dev/my-project/my-repo/my-app:v2.0

# 查看滾動更新狀態
kubectl rollout status deployment/my-app-deployment

# 回滾到上一版
kubectl rollout undo deployment/my-app-deployment

3.3 Service：讓 Pod 可以被找到

Pod 的 IP 會變，Service 提供一個穩定的 IP 和 DNS 名稱，讓其他服務能穩定連線。

# Service 範例
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app # 連接到標籤匹配的所有 Pod
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer # 對外公開

Service 類型：

類型	說明	使用場景
ClusterIP（預設）	只在叢集內部可存取	微服務間的內部通訊
NodePort	透過節點 IP + 埠號存取	測試環境、本地開發
LoadBalancer	建立 GCP Load Balancer，對外公開	生產環境的公開服務

3.4 Ingress：HTTP 流量的智慧路由

Service 的 LoadBalancer 類型每個 Service 都需要一個獨立的 Load Balancer（費用高）。

Ingress 提供一個入口，根據 URL 路徑或域名路由到不同 Service：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: 'gce' # 使用 GCP Load Balancer
spec:
  rules:
    - host: api.yourdomain.com
      http:
        paths:
          - path: /users
            pathType: Prefix
            backend:
              service:
                name: user-service
                port:
                  number: 80
          - path: /products
            pathType: Prefix
            backend:
              service:
                name: product-service
                port:
                  number: 80

優點：多個服務共用一個 Load Balancer，大幅降低費用。

上面範例用的 kubernetes.io/ingress.class: 'gce' 是舊式 annotation，目前仍可運作；新版 GKE 文件改推薦用 spec.ingressClassName 來指定。兩種寫法考試都可能看到，認得出 gce 代表「走 GCP 的 HTTP(S) Load Balancer」就夠了。

3.5 HPA：自動水平擴縮

Horizontal Pod Autoscaler (HPA) 根據 CPU 或記憶體使用率自動調整 Pod 副本數量：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70 # CPU 使用率超過 70% 就擴容

流量高峰時：HPA 自動新增 Pod 副本，最多到 10 個

離峰時：HPA 自動縮減 Pod 副本，最少保留 2 個

---

四、動手實作：建立 GKE 叢集並部署應用

Step 1：啟用必要 API

# 啟用 GKE API
gcloud services enable container.googleapis.com

Step 2：建立 GKE Autopilot 叢集

# 建立 Autopilot 叢集（推薦）
gcloud container clusters create-auto my-cluster \
    --region=asia-east1 \
    --release-channel=regular

# 建立 Standard 叢集（進階需求）
gcloud container clusters create my-cluster \
    --region=asia-east1 \
    --num-nodes=2 \
    --machine-type=e2-medium \
    --release-channel=regular

參數說明：

• --region=asia-east1：台灣最近的區域（Autopilot 必須用 region，而非 zone）
• --release-channel=regular：使用穩定但接近最新的 GKE 版本（推薦生產環境）

Step 3：取得叢集憑證

# 設定 kubectl 連線到這個叢集
gcloud container clusters get-credentials my-cluster \
    --region=asia-east1

# 驗證連線
kubectl get nodes

Step 4：部署應用程式

# 方法 1：用 kubectl apply 套用 YAML 設定檔
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

# 方法 2：直接用指令快速部署（適合測試）
kubectl create deployment hello-app \
    --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

# 對外公開服務（建立 Load Balancer）
kubectl expose deployment hello-app \
    --type=LoadBalancer \
    --port=80 \
    --target-port=8080

Step 5：查看部署狀態

# 查看所有 Pod 狀態
kubectl get pods

# 查看所有 Service（等待 EXTERNAL-IP 出現）
kubectl get services

# 查看 Deployment 詳細資訊
kubectl describe deployment hello-app

# 查看 Pod 的 log
kubectl logs -f pod-name

# 進入 Pod 的 shell（debug 用）
kubectl exec -it pod-name -- /bin/sh

Step 6：設定自動擴縮

# 建立 HPA（CPU 使用率超過 70% 就擴容）
kubectl autoscale deployment hello-app \
    --cpu-percent=70 \
    --min=2 \
    --max=10

# 查看 HPA 狀態
kubectl get hpa

---

五、Workload Identity：GKE 應用的安全認證

問題：GKE 中的應用如何存取 GCP 服務？

你的 GKE 應用（例如：讀取 Cloud Storage 的 API 服務）需要 GCP 的存取權限。

錯誤做法 ❌：把服務帳號 JSON 金鑰掛進 Pod

# 危險！金鑰可能洩漏、難以管理
env:
  - name: GOOGLE_APPLICATION_CREDENTIALS
    value: /secret/service-account-key.json

正確做法 ✅：使用 Workload Identity

Workload Identity 的運作原理

GKE Pod 使用 Kubernetes Service Account
    ↕ 綁定關係（IAM 政策）
Google IAM Service Account
    ↕ 自動取得短期 Token
GCP 資源（Cloud Storage、BigQuery、Pub/Sub...）

Pod 會自動拿到短期有效的 token，完全不用靜態金鑰。

設定 Workload Identity

# 1. 建立叢集時啟用 Workload Identity（Autopilot 預設已啟用）
gcloud container clusters update my-cluster \
    --workload-pool=my-project.svc.id.goog \
    --region=asia-east1

# 2. 建立 Kubernetes Service Account
kubectl create serviceaccount my-app-ksa \
    --namespace=default

# 3. 建立 Google IAM Service Account
gcloud iam service-accounts create my-app-sa \
    --display-name="My App Service Account"

# 4. 授予 IAM SA 所需權限（例如：讀取 Cloud Storage）
gcloud projects add-iam-policy-binding my-project \
    --member="serviceAccount:my-app-sa@my-project.iam.gserviceaccount.com" \
    --role="roles/storage.objectViewer"

# 5. 綁定 Kubernetes SA 和 Google IAM SA
gcloud iam service-accounts add-iam-policy-binding \
    my-app-sa@my-project.iam.gserviceaccount.com \
    --role="roles/iam.workloadIdentityUser" \
    --member="serviceAccount:my-project.svc.id.goog[default/my-app-ksa]"

# 6. 為 Kubernetes SA 加上 annotation
kubectl annotate serviceaccount my-app-ksa \
    --namespace=default \
    iam.gke.io/gcp-service-account=my-app-sa@my-project.iam.gserviceaccount.com

# 7. 在 Deployment 中指定使用這個 Service Account
spec:
  template:
    spec:
      serviceAccountName: my-app-ksa # 使用綁定了 IAM SA 的 KSA
      containers:
        - name: my-app
          image: ...

📝 考場提點

只要題目問「GKE 上的應用要怎麼安全存取 Cloud Storage / BigQuery / Pub/Sub」，正解幾乎永遠是 Workload Identity（把 Kubernetes SA 綁定到 Google IAM SA）。陷阱選項一定會出現「把 service account 的 JSON 金鑰塞進 Secret 或環境變數」——看到就刪掉，靜態金鑰會洩漏又難輪替，正是 Workload Identity 要解決的問題。順便把 Service 類型也一起記熟，這兩塊常綁在同一題裡考：只在叢集內互打 → ClusterIP；要對外公開 → LoadBalancer；多個服務想共用一個 Load Balancer 省錢、按網址路由 → Ingress。

---

六、GKE vs Cloud Run vs App Engine：選型決策

這是 ACE 考試中常出現的比較題。

場景	推薦選擇	理由
複雜微服務架構，需要細緻控制	GKE	完整 Kubernetes 生態系
簡單 API、Webhook，需要 scale to zero	Cloud Run	最簡單、最省錢（閒置不付費）
傳統 Web 應用、不想管容器	App Engine Standard	直接部署程式碼，最簡單
有狀態應用（資料庫、訊息佇列）	GKE	支援 Persistent Volume
需要 GPU 加速的 ML 推論	GKE	完整 GPU 節點支援
處理突發性短暫任務	Cloud Run Jobs	按用量付費，適合批次工作
現有 Kubernetes 設定檔	GKE	無需改寫，直接遷移

真的不知道選哪個的話，照這個順序往下試就對了：

• 不確定 → 先試 Cloud Run（最簡單、最省錢，閒置不收費）
• Cloud Run 不夠用 → 換 GKE Autopilot
• 還要特殊硬體或深度客製化 → 才上 GKE Standard

---

七、成本優化策略

7.1 使用 Spot Pod（大幅降低成本）

Spot Pod 可以享受 60-91% 的折扣，但 GCP 可能隨時中斷它們。被搶占時你會收到中斷通知，不過 Spot Pod 真正能用的寬限期上限只有 15 秒（terminationGracePeriodSeconds 最多 15s），時間很短，所以工作一定要設計成「被砍掉也能重跑」：

# Autopilot 中使用 Spot Pod
spec:
  template:
    metadata:
      annotations:
        cloud.google.com/spot: 'true'

適合場景：批次處理、資料分析、CI/CD 任務——這些工作即使中斷也能重試。

不適合場景：生產環境的 Web 服務、資料庫。

7.2 設定合理的 Resource Requests

Autopilot 按照 Pod 申請的資源計費，所以設定合理的 requests 很重要：

resources:
  requests:
    cpu: '250m' # 0.25 vCPU（不要申請超過需求）
    memory: '256Mi'
  limits:
    cpu: '500m'
    memory: '512Mi'

7.3 使用 Vertical Pod Autoscaler（VPA）建議

VPA 可以分析歷史使用量，建議最佳的 resource requests 設定，幫你避免過度申請或申請不足。

7.4 善用 Committed Use Discounts

如果長期使用 GKE Standard，可以購買 1 年或 3 年的 Committed Use Discount（CUD，承諾用量折扣），節省最高約 55%（記憶體優化機型最高 70%；GKE Standard 走 Compute Engine 的 resource-based CUD 費率，實際折扣會隨機型與承諾年限變動）。

---

八、常用 kubectl 指令速查

# === 查看資源 ===
kubectl get pods                        # 查看所有 Pod
kubectl get pods -n kube-system         # 查看系統命名空間的 Pod
kubectl get deployments                 # 查看所有 Deployment
kubectl get services                    # 查看所有 Service
kubectl get nodes                       # 查看所有節點
kubectl get all                         # 查看所有資源

# === 詳細資訊 ===
kubectl describe pod my-pod             # Pod 的詳細資訊（含 Events）
kubectl logs my-pod                     # 查看 Pod 日誌
kubectl logs -f my-pod                  # 即時追蹤 Pod 日誌
kubectl logs my-pod --previous          # 查看前一個容器的日誌（Pod 重啟後）

# === 操作 ===
kubectl apply -f manifest.yaml          # 套用 YAML 設定
kubectl delete -f manifest.yaml         # 刪除 YAML 中的資源
kubectl delete pod my-pod               # 刪除特定 Pod
kubectl scale deployment my-app --replicas=5   # 手動調整副本數

# === Debug ===
kubectl exec -it my-pod -- /bin/sh      # 進入 Pod 的 shell
kubectl port-forward pod/my-pod 8080:80 # 把 Pod 的 80 埠轉到本機 8080

# === Namespace ===
kubectl get ns                          # 查看所有 Namespace
kubectl create namespace my-namespace   # 建立 Namespace
kubectl -n my-namespace get pods        # 在特定 Namespace 查看 Pod

---

九、ACE 考試重點提示

常見考題類型

類型 1：Standard vs Autopilot 選擇

題目：你的應用需要使用 NVIDIA GPU 加速機器學習推論，應使用哪種 GKE 模式？

• ✅ 視需求而定：Autopilot 目前已支援常見的 GPU（如 L4、A100、H100），Google 會自動裝好驅動程式，多數 ML 推論場景直接用 Autopilot 就夠。真正需要換成 GKE Standard 的情況是要客製化驅動版本、用還沒被 Autopilot 支援的新型加速器，或需要對節點做更深的底層控制。

題目：你希望最小化管理負擔，讓應用自動擴縮，大多數時間流量較低。應使用哪種 GKE 模式？

• ✅ GKE Autopilot

類型 2：Service 類型選擇

題目：你的後端微服務只需要被同一叢集內的其他服務存取。應使用哪種 Service 類型？

• ✅ ClusterIP（預設，叢集內部存取）

題目：你需要讓全球使用者能從網際網路存取你的 Web 應用。應使用哪種 Service 類型？

• ✅ LoadBalancer（建立 GCP Load Balancer）

類型 3：Workload Identity

題目：你的 GKE 應用需要存取 Cloud Storage。最安全的做法是？

• ❌ 把服務帳號 JSON 金鑰存在 Kubernetes Secret
• ✅ 使用 Workload Identity 綁定 Kubernetes SA 和 Google IAM SA

類型 4：HPA 設定

題目：你的應用在流量高峰時 CPU 使用率飆升到 95%，需要自動擴縮。應設定什麼？

• ✅ Horizontal Pod Autoscaler（HPA），設定 CPU 使用率閾值

---

十、總結

GKE 在考試裡最常跟 Cloud Run、App Engine 綁在一起出選型題，把第六節那張對照表記熟，這類題基本上就拿得到分。剩下的高頻考點就是這節下面這張表——選型關鍵字、Workload Identity、Service 類型，掃過去確認自己每個都答得出來再去考。

關鍵重點回顧：

概念	要記住的重點
GKE Autopilot	2023 年後的推薦模式，按 Pod 資源計費，Google 管理節點
GKE Standard	需要特殊硬體或深度控制時使用，按 VM 計費
Pod	最小部署單位，IP 是臨時的
Deployment	管理 Pod 副本數量，支援滾動更新和回滾
Service	提供穩定的 IP/DNS，ClusterIP（內部）/ LoadBalancer（對外）
Ingress	多服務共用一個 Load Balancer，按 URL 路由
HPA	根據 CPU/記憶體自動調整 Pod 數量
Workload Identity	不需要 JSON 金鑰，最安全的 GCP 存取方式

下一步行動

1. 動手實作：申請 GCP 免費試用，建立第一個 Autopilot 叢集
2. 部署真實應用：把你的 Web 應用容器化，部署到 GKE
3. 設定監控：啟用 Cloud Monitoring 查看容器指標
4. 深入 Kubernetes：學習 StatefulSet、ConfigMap、Secret 等進階概念

系列文章連結

• 📖 上一篇：ACE-205: 企業級資安防護：GCP 安全架構與合規指南
• 📖 相關閱讀：ACE-203: 無伺服器時代：App Engine、Cloud Run 與 GKE 選型策略
• 📖 進階延伸：ACE-202: 打造不當機的系統：GCP 高可用架構設計實戰

---

延伸閱讀

• GKE 官方文件
• GKE Autopilot 概述
• Workload Identity 設定指南
• GKE 定價說明
• Kubernetes 官方文件
• Google Cloud Skills Boost - GKE 學習路徑

---

下一課 GCP-106：監控與日誌入門——Cloud Monitoring & Logging 完全指南，學習如何觀察和診斷你的 GCP 服務。

📖 延伸閱讀：想比較三大雲端的 K8s 服務？參考 GKE vs EKS vs AKS 完整比較。