跳至主要內容
Study Jam:雲端基礎實作 — 第 9/10 篇

部署應用到 Kubernetes

內文字級

部署應用到 Kubernetes
更新:2026-10-12

課程概述

容器映像已經做好,接下來怎麼讓它跑起來、接到流量,更新時又不把網站弄斷?這篇從建立 GKE 叢集開始,依序建立 Deployment 和 Service,再試一次滾動更新與回滾。官方課程的 Lab 則是 Docker 入門、GKE 快速入門,以及用 kubectl 建立 Pod、Service 與 Deployment;滾動更新與回滾的實作在下一門課 Manage Kubernetes in Google Cloud 的 Lab,本文先帶過。

Kubernetes 部署模型:Cluster 包含控制面與 Node Pool,Pod 分散排程到多個 Node;Deployment 維持所需副本,Service 將外部流量分配給 Ready Pod,Rolling Update 逐一替換,失敗時回滾舊映像

容器跑在 Pod 裡,Pod 被排到 Node 上,Node 則屬於叢集裡的節點池。Deployment 負責維持指定的副本數與版本,Service 提供固定入口。更新時先等新 Pod 準備好,再逐步移走舊 Pod;若新版本有問題,就把部署回滾。

你將學到

  • 建立與配置 GKE 叢集
  • 使用 kubectl 管理工作負載
  • 建立 Deployment 與 Service
  • 實作滾動更新與回滾
  • 理解 Pod、Node、Cluster 的關係

核心概念

Kubernetes 核心元件

Cluster(叢集)
  ├── Control Plane(控制面)— API Server、Scheduler、etcd
  └── Node Pool(節點池)
        └── Node(節點)
              └── Pod(容器組)
                    └── Container(容器)
kubectl apply 後的 Kubernetes 控制迴路:API Server 完成驗證與准入,Controller 建立 Pending Pod,Scheduler 選擇 Node,kubelet 啟動容器,Observed Status 再回饋控制器

kubectl 只把期望狀態送到 API Server;Controller 建立需要的 Pod,Scheduler 負責選 Node,真正讓容器啟動的是該 Node 上的 kubelet。狀態持續回報,控制器才能反覆修正實際狀態。

常用 kubectl 指令

# 建立 GKE 叢集
gcloud container clusters create my-cluster \
  --zone us-central1-a --num-nodes 3

# 取得叢集認證
gcloud container clusters get-credentials my-cluster --zone us-central1-a

# 部署應用
kubectl create deployment nginx --image=nginx:latest

# 暴露服務
kubectl expose deployment nginx --type=LoadBalancer --port=80

# 擴展副本數
kubectl scale deployment nginx --replicas=3

# 查看 Pod 狀態
kubectl get pods -o wide

# 滾動更新
kubectl set image deployment/nginx nginx=nginx:1.25

# 回滾
kubectl rollout undo deployment/nginx
查看流程與節點文字

箭頭表示流程方向;方括號與引號內是節點名稱,可搭配下方圖解閱讀。

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 24, "rankSpacing": 32}}}%%
flowchart TD
  SYMPTOM["先用 get pods/svc/endpointslices<br/>界定症狀與影響範圍"] --> STATE{"目前最明顯的症狀?"}
  STATE -->|"Pod Pending"| PENDING["describe Pod 與 Events<br/>查資源、配額、Taint 與 Node"]
  STATE -->|"CrashLoopBackOff"| CRASH["logs --previous + describe<br/>查命令、設定、Secret 與 OOM"]
  STATE -->|"Running 但 NotReady"| READY["檢查 Readiness Probe<br/>路徑、Port 與依賴服務"]
  STATE -->|"Service 沒有流量"| ROUTE["核對 Selector、EndpointSlice、<br/>port/targetPort 與 Load Balancer"]
先按狀態分流,再選 describe、logs 或網路物件,不必一開始就重建叢集。修正後回到 get 與 rollout status,確認期望狀態真的收斂。

Deployment YAML 範例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: us-central1-docker.pkg.dev/PROJECT/repo/app:v1
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: '250m'
              memory: '128Mi'
Kubernetes Service 依 selector 找到 app=web Pod,但 EndpointSlice 只收錄通過 Readiness Probe 的 Pod IP;啟動中或失敗 Pod 不接流量,滾動更新時 v2 Ready 後 v1 才退出

Label selector 找到候選 Pod,但 Readiness 才決定它能否進入 EndpointSlice 接收流量。滾動更新時先等 v2 通過 Readiness,再讓 v1 退出,可避免把請求送到仍在啟動或已故障的容器。

實作重點

  • GKE Autopilot 代管節點,適合想先專注在工作負載的團隊;建立前仍要確認計費方式
  • Standard 模式保留更多節點設定空間,適合需要自行控制節點的情況
  • 使用 Standard 建立叢集時,依應用的資源需求選機型,不要直接套用範例規格
  • Pod 起不來時,用 kubectl describe pod 來查問題出在哪

Skill Badge 指引

Lab 連結:Deploy Kubernetes Applications on Google Cloud(原名 Deploy to Kubernetes in Google Cloud)— 完成此 lab 可獲得 Skill Badge

延伸學習

Study Jam:雲端基礎實作 — 第 9 篇/共 10 篇 查看系列全覽 →

讀完後,留一個學習紀錄

試著用自己的話說出一個重點,以及你會如何運用。實作文章請先核對結果與清理資源,再標記為讀完。

文章進度以你確認讀完的標記為準,可隨時取消。舊版造訪紀錄保留,但不計入讀完;這份自評不代表已掌握內容。

留言討論

文章目錄與系列

徽章解鎖!