Cloud Native 技術棧入門：Kubernetes、容器化與 API Gateway【2025】

你決定導入 Cloud Native 架構，但面對 Kubernetes、Buildpacks、API Gateway、Storage 這些術語，不知道從何下手。這篇文章會幫你理清 Cloud Native 技術棧的核心元件，讓你知道每個元件的角色和選型考量。

Cloud Native 技術棧不是把工具隨便湊在一起。每個元件都有它的定位，彼此協作才能發揮最大效益。讀完這篇，你會對整個技術棧有完整的認識。

---

Cloud Native 技術棧概覽

一個完整的 Cloud Native 技術棧通常包含以下層次：

┌─────────────────────────────────────────────────────┐
│  應用層 Application                                  │
│  ├─ 微服務 Microservices                            │
│  └─ API Gateway                                     │
├─────────────────────────────────────────────────────┤
│  編排層 Orchestration                               │
│  └─ Kubernetes                                      │
├─────────────────────────────────────────────────────┤
│  容器層 Container                                    │
│  ├─ Container Runtime (containerd)                  │
│  └─ Container Image (OCI)                           │
├─────────────────────────────────────────────────────┤
│  基礎設施層 Infrastructure                           │
│  ├─ Storage                                         │
│  ├─ Network                                         │
│  └─ Compute                                         │
└─────────────────────────────────────────────────────┘

每一層都有對應的技術選項。接下來我們逐一介紹核心元件。

想了解 Cloud Native 基本概念？請先閱讀 Cloud Native 完整指南。

---

Kubernetes 核心概念

K8s 是什麼？為何成為標準？

Kubernetes（K8s） 是 Google 於 2014 年開源的容器編排平台。它的設計靈感來自 Google 內部使用超過 15 年的 Borg 系統。

為什麼 Kubernetes 成為事實標準？

1. Google 背書：由大規模生產環境驗證過的架構
2. CNCF 託管：中立治理，不被單一廠商綁定
3. 生態系完整：1,000+ 個相關工具和插件
4. 雲端支援：AWS、GCP、Azure 都提供託管服務

目前 Kubernetes 在容器編排市場的市佔率超過 80%。

K8s 架構組成

Kubernetes 叢集由兩種節點組成：

Control Plane（控制平面）

元件	功能
kube-apiserver	API 入口，所有操作都經過這裡
etcd	分散式鍵值儲存，存放叢集狀態
kube-scheduler	決定 Pod 要跑在哪個節點
kube-controller-manager	執行控制迴圈，維護期望狀態

Worker Node（工作節點）

元件	功能
kubelet	管理節點上的 Pod
kube-proxy	處理網路規則和負載平衡
Container Runtime	執行容器（containerd、CRI-O）

K8s 核心物件

Pod

Pod 是 K8s 最小的部署單位。一個 Pod 可以包含一個或多個容器，共享網路和儲存。

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: my-app:v1.0.0
    ports:
    - containerPort: 8080

Deployment

Deployment 管理 Pod 的副本數和更新策略。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3  # 維持 3 個副本
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app:v1.0.0

Service

Service 提供穩定的網路端點，讓其他服務可以存取 Pod。

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

ConfigMap 和 Secret

ConfigMap 存放設定資料，Secret 存放敏感資訊。兩者都可以注入到 Pod 中。

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  API_ENDPOINT: "https://api.example.com"

這種做法符合 12 Factor 的 Config 原則：設定和程式碼分離。

K8s 部署模式

自建叢集 vs 託管服務

面向	自建（kubeadm）	託管（EKS/GKE/AKS）
Control Plane 管理	自己負責	雲端商負責
升級複雜度	高	低
成本	較低（但需要人力）	較高（但省人力）
客製化程度	高	中

建議：

• 中小團隊：用託管服務，專注在應用開發
• 大型企業：可考慮自建，但要有專責 SRE 團隊

K8s 很強大，但設定錯了反而更燒錢。預約架構諮詢，讓專家幫你評估最適合的部署方式。

---

容器化與 Cloud Native Buildpacks

容器化基礎

容器化是 Cloud Native 的基礎。容器把應用程式和依賴打包在一起，確保在任何環境都能一致執行。

容器 vs 虛擬機器

面向	虛擬機器	容器
啟動時間	分鐘級	秒級
資源佔用	GB 級	MB 級
隔離層級	完整 OS	程序級
映像大小	數 GB	數十 MB 到數百 MB

OCI 標準

OCI（Open Container Initiative）定義了容器映像和執行時期的標準。遵循 OCI 標準的映像可以在任何相容的執行環境運行（Docker、containerd、CRI-O）。

Cloud Native Buildpacks 介紹

Cloud Native Buildpacks（CNB） 是 CNCF 專案，可以自動把程式碼轉換成容器映像，不需要手寫 Dockerfile。

傳統做法 vs Buildpacks

面向	Dockerfile	Buildpacks
需要的知識	了解基礎映像、分層優化	只要會寫程式
安全更新	手動更新基礎映像	自動 rebase
建置快取	手動優化層順序	自動處理
多語言支援	每種語言寫不同 Dockerfile	自動偵測語言

使用範例

# 安裝 pack CLI
brew install buildpacks/tap/pack

# 建置映像（自動偵測語言）
pack build my-app --builder paketobuildpacks/builder:base

# 完成！不需要 Dockerfile
docker run -p 8080:8080 my-app

Buildpacks 如何運作

1. 偵測（Detect）：Buildpack 檢查程式碼，判斷是否適用
2. 建置（Build）：執行相關建置步驟（安裝依賴、編譯等）
3. 產出（Export）：輸出符合 OCI 標準的容器映像

常用 Buildpack

語言	Buildpack
Java	Paketo Java Buildpack
Node.js	Paketo Node.js Buildpack
Go	Paketo Go Buildpack
Python	Paketo Python Buildpack
.NET	Paketo .NET Core Buildpack

容器映像最佳實踐

1. 使用多階段建置

# 建置階段
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# 執行階段
FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]

2. 選擇適當的基礎映像

選項	大小	安全性	適用場景
Alpine	最小	需注意 musl 相容性	簡單應用
Distroless	小	高（無 shell）	生產環境
Official	中	中	開發和測試

3. 掃描安全漏洞

# 使用 Trivy 掃描映像
trivy image my-app:v1.0.0

---

API Gateway 在 Cloud Native 中的角色

什麼是 Cloud Native API Gateway？

API Gateway 是微服務架構中的統一入口。所有外部請求先經過 API Gateway，再分發到後端服務。

API Gateway 的職責：

• 路由：根據 URL 路徑分發請求
• 認證授權：驗證 JWT、API Key
• 限流：保護後端服務不被過載
• 監控：收集請求指標
• 轉換：請求/回應格式轉換

API Gateway vs Ingress Controller

面向	Ingress Controller	API Gateway
L7 路由	基本支援	進階支援
認證授權	有限	完整
限流	有限	完整
插件生態	較少	豐富
定位	K8s 入口	API 管理

主流 API Gateway 比較

Kong

• 基於 OpenResty（Nginx + Lua）
• 最成熟的開源 API Gateway
• 豐富的插件生態系
• 有企業版和開源版

# Kong Ingress Controller 範例
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-api
  annotations:
    konghq.com/strip-path: "true"
    konghq.com/plugins: rate-limiting
spec:
  ingressClassName: kong
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /users
        pathType: Prefix
        backend:
          service:
            name: user-service
            port:
              number: 80

Ambassador / Emissary-Ingress

• 基於 Envoy
• Kubernetes 原生設計
• 使用 CRD 設定
• 適合 K8s 環境

Apache APISIX

• 高效能（基於 Nginx）
• 動態設定（不需重啟）
• 豐富的插件
• 中國團隊開發，文件有中文

Traefik

• 自動服務發現
• 設定簡單
• 適合中小型專案
• 內建 Let's Encrypt 整合

API Gateway 選型建議

需求	推薦
企業級功能、成熟度	Kong
K8s 原生、Envoy 生態	Emissary-Ingress
高效能、豐富插件	APISIX
簡單易用、自動發現	Traefik

選型考量因素：

1. 團隊熟悉度：選擇團隊能維護的工具
2. 效能需求：高流量選 APISIX 或 Kong
3. 功能需求：需要 OAuth、限流等進階功能？
4. 生態整合：和現有監控、日誌系統的整合

---

Cloud Native Storage 儲存方案

K8s 儲存概念

Kubernetes 的儲存抽象層：

Volume

Volume 是 Pod 層級的儲存，生命週期和 Pod 綁定。

Persistent Volume（PV）

PV 是叢集層級的儲存資源，獨立於 Pod 存在。

Persistent Volume Claim（PVC）

PVC 是使用者對儲存的請求，K8s 會自動配對適合的 PV。

Storage Class

Storage Class 定義儲存的類型和參數，支援動態配置。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "10000"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

雲原生儲存方案比較

Rook-Ceph

• 基於 Ceph 分散式儲存
• 支援區塊、檔案、物件三種儲存
• 功能最完整，但複雜度高
• 適合大規模部署

Longhorn

• Rancher 開發的輕量儲存方案
• 安裝簡單，UI 友善
• 支援備份和災難復原
• 適合中小型叢集

OpenEBS

• 容器原生儲存
• 多種儲存引擎選擇
• 效能和可靠性平衡
• 適合通用場景

比較總表

方案	複雜度	功能	效能	適用規模
Rook-Ceph	高	最完整	高	大型
Longhorn	低	中等	中	中小型
OpenEBS	中	靈活	中高	通用

儲存選型建議

選擇雲端託管儲存的情況：

• 使用託管 K8s（EKS、GKE、AKS）
• 不想管理儲存基礎設施
• 需要高可用性和備份

選擇自建儲存的情況：

• 地端部署
• 需要避免雲端鎖定
• 有特殊效能或功能需求

想了解雲原生資料庫？請參考 Cloud Native Database 選型指南。

---

技術棧整合架構圖

一個典型的 Cloud Native 技術棧整合架構：

                        ┌────────────────────┐
                        │   Load Balancer    │
                        │   (Cloud LB)       │
                        └─────────┬──────────┘
                                  │
                        ┌─────────▼──────────┐
                        │   API Gateway      │
                        │   (Kong/APISIX)    │
                        └─────────┬──────────┘
                                  │
        ┌─────────────────────────┼─────────────────────────┐
        │                         │                         │
┌───────▼───────┐       ┌────────▼────────┐       ┌────────▼────────┐
│ User Service  │       │ Order Service   │       │ Payment Service │
│ (Deployment)  │       │ (Deployment)    │       │ (Deployment)    │
└───────┬───────┘       └────────┬────────┘       └────────┬────────┘
        │                        │                         │
        │               ┌────────▼────────┐               │
        │               │  Message Queue  │               │
        │               │  (NATS/Kafka)   │               │
        │               └─────────────────┘               │
        │                                                  │
┌───────▼───────┐                                 ┌───────▼───────┐
│   PostgreSQL  │                                 │     Redis     │
│   (PVC)       │                                 │   (PVC)       │
└───────────────┘                                 └───────────────┘

流量路徑：

1. 外部請求到達 Load Balancer
2. API Gateway 處理認證、路由、限流
3. 請求分發到對應的微服務
4. 微服務透過 Message Queue 非同步通訊
5. 資料儲存在資料庫，快取存在 Redis

K8s 上的 AI 工作流程？請參考 Cloud Native AI，了解 MLOps 和 Kubeflow。

---

FAQ

Q1: 學 Kubernetes 要先學 Docker 嗎？

建議先學。Docker 讓你理解容器的基本概念（映像、容器、Dockerfile）。這些概念在 Kubernetes 中都會用到。

Q2: API Gateway 和 Service Mesh 有什麼差別？

API Gateway 處理「南北向」流量（外部到內部），Service Mesh 處理「東西向」流量（服務間通訊）。兩者可以並存。

Q3: 一定要用 Cloud Native Storage 嗎？

不一定。如果你用雲端託管的 Kubernetes，可以直接用雲端的儲存服務（EBS、Persistent Disk）。自建儲存主要用於地端部署或避免雲端鎖定。

Q4: Buildpacks 可以取代 Dockerfile 嗎？

對於標準的應用程式，Buildpacks 可以完全取代 Dockerfile，而且更容易維護。但如果有特殊需求（自訂基礎映像、複雜建置步驟），可能還是需要 Dockerfile。

Q5: 小團隊適合用這整套技術棧嗎？

不一定要全用。可以從 Docker + 託管 Kubernetes 開始，API Gateway 用雲端服務（API Gateway、Cloud Endpoints），儲存用雲端服務。隨著需求成長再逐步補齊。

---

下一步

Cloud Native 技術棧的元件很多，不需要一次學完。建議：

1. 先掌握 Kubernetes 核心概念
2. 學會容器化你的應用
3. 根據需求選擇 API Gateway
4. 最後再考慮儲存和其他進階元件

延伸閱讀：

• 回到核心概念：Cloud Native 完整指南
• 學習架構原則：12 Factor App 完整解析
• 了解安全議題：Cloud Native Security 完整指南
• 探索雲原生資料庫：Cloud Native Database 選型指南

Cloud Native 技術棧看起來很複雜？預約免費諮詢，讓我們幫你規劃適合團隊的技術選型。

---

參考資料

• Kubernetes Documentation
• Cloud Native Buildpacks
• CNCF Landscape - API Gateway
• CNCF Landscape - Storage
• Kong Documentation
• Longhorn Documentation