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 上自然最原生、也最穩。

你將學到：

• ✅ 為什麼需要 Kubernetes（從 VM 到容器到容器編排）
• ✅ GKE Standard vs Autopilot：如何選擇？
• ✅ Kubernetes 五大核心概念（Pod、Deployment、Service、Ingress、HPA）
• ✅ 建立 GKE Cluster 並部署第一個應用
• ✅ Workload Identity：容器的安全認證最佳實踐
• ✅ GKE vs Cloud Run vs App Engine 選型決策
• ✅ 成本優化與 ACE 考試重點

---

一、為什麼需要 Kubernetes？

從 VM 到容器的演進

傳統做法：VM 部署

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

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

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

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

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

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

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

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

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

GKE = Kubernetes 的全託管版本

自己架 Kubernetes 真的很麻煩（Control Plane 管理、etcd、API Server、網路設定…一大堆）。

GKE 幫你做了什麼：

• ✅ 自動安裝並維護 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 的免費額度（相當於一個免費叢集）

選擇建議

你的需求是...
    ↓
需要特殊硬體（GPU、高速 NVMe）、自定義 Linux 核心？
    → Standard

需要 SSH 進節點做 debug？
    → Standard

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

💡 補充：GKE Enterprise GKE Enterprise 是付費加值方案，提供多叢集管理、Fleet 管理、Config Sync、Policy Controller 這類企業級功能。如果你的組織要跨多個叢集、或混合雲環境統一管理，它就派得上用場。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，大幅降低費用。

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 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 可能隨時中斷它們（中斷前有 30 秒通知）：

# 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，節省最高 55%。

---

八、常用 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 模式？

• ✅ 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 是 GCP 上能做最多事、也最靈活的應用部署平台。把它摸熟，你手上就有了現代微服務架構最核心的工具。

關鍵重點回顧：

概念	要記住的重點
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 完整比較。