前言：為何企業要容器化
容器化（Containerization）已從新創公司的技術實驗，演進為企業 IT 現代化的核心路徑。驅動這股趨勢的核心原因有三：
- 環境一致性：「在我電腦上可以跑」的問題透過容器映像得以根絕，開發、測試、生產環境完全一致。
- 資源效率：容器共用 OS Kernel，啟動時間以秒計，單台實體機可運行數十至數百個容器，資源利用率大幅提升。
- 部署速度：結合 CI/CD 流水線，從程式碼提交到生產環境部署可縮短至數分鐘，支援企業的快速迭代需求。
然而，容器技術的複雜度隨規模增長而急速上升。管理數百個容器時，需要自動化排程、服務發現、負載均衡、滾動升級、自我修復等能力——這正是 Kubernetes（K8s）誕生的原因。
一、容器 vs VM：適用場景比較
容器並非要取代虛擬機（VM），而是與 VM 互補，各有其適用場景：
| 維度 | 虛擬機（VM） | 容器（Container） |
|---|---|---|
| 隔離層級 | OS 層級隔離（Hypervisor） | 程序層級隔離（Namespace / cgroup） |
| 啟動時間 | 分鐘級 | 秒級（甚至毫秒） |
| 資源占用 | 較高（含完整 Guest OS） | 較低（共用 Host OS Kernel） |
| 安全隔離 | 強（適合多租戶） | 較弱（需額外強化） |
| 適用場景 | 傳統應用、強隔離需求、有狀態服務 | 微服務、CI/CD、無狀態服務 |
實務上，企業通常採用混合架構：在 VM 上執行容器（K8s Worker Node 本身是 VM），兼顧隔離性與資源效率。
二、Kubernetes 架構概覽
Control Plane（控制平面）
Control Plane 負責整個叢集的管理決策，主要元件包含：
- kube-apiserver：K8s 的 API 閘道，所有操作均透過 API Server 進行
- etcd：分散式 Key-Value 儲存，保存叢集所有狀態資料（高可用叢集需 3 或 5 個 etcd 節點）
- kube-scheduler：依資源需求、親和性規則等條件，決定 Pod 排程至哪個 Worker Node
- kube-controller-manager：運行各種控制迴圈（Deployment Controller、Node Controller 等），確保實際狀態符合期望狀態
Worker Node（工作節點）
Worker Node 是實際執行應用程式容器的主機，主要元件包含：
- kubelet：Node Agent，負責 Pod 生命週期管理，與 API Server 溝通
- kube-proxy：維護網路規則，實現 Service 的負載均衡與 Pod 到 Pod 通訊
- Container Runtime：容器執行環境（containerd / CRI-O），負責 Pull Image、啟動容器
etcd 的重要性
etcd 是 K8s 的「大腦記憶」，所有叢集狀態均存於此。etcd 損壞等同叢集狀態全部遺失，因此必須：定期備份 etcd 資料（建議每小時）、高可用叢集使用奇數節點（3 或 5）、etcd 節點使用高效能 SSD。
三、企業 K8s 部署模式
| 模式 | 自建（On-Prem） | 雲端代管（Managed K8s） | 混合部署 |
|---|---|---|---|
| 代表方案 | kubeadm / RKE2 / OpenShift | AKS / EKS / GKE | Azure Arc / Anthos |
| Control Plane 管理 | 自行維護 | 雲端廠商代管 | 雲端廠商代管 |
| 升級複雜度 | 高 | 低（一鍵升級） | 中 |
| 資料主權 | 完全自控 | 依雲端廠商 | 本地資料可自控 |
| 適合場景 | 合規嚴格、已有機房資源 | 快速上線、彈性擴展 | 部分工作負載上雲 |
| 初期成本 | 高（硬體 + 人力） | 低（按用量計費） | 中 |
四、儲存規劃
容器本身是無狀態的，但企業應用往往需要持久化儲存（資料庫、檔案系統等）。K8s 提供以下儲存抽象：
- PersistentVolume（PV）：叢集管理員預先建立的儲存資源，可對應 NFS、iSCSI、雲端 Block Storage 等
- PersistentVolumeClaim（PVC）：Pod 宣告所需的儲存規格，K8s 自動綁定合適的 PV
- StorageClass：定義儲存的「類型」（如 SSD、HDD、NFS），搭配 CSI Driver 實現動態 PV 配置（Dynamic Provisioning）
- CSI Driver：Container Storage Interface，是儲存廠商（如 Pure Storage、NetApp、Ceph）與 K8s 的標準介面
企業建議使用動態配置搭配 StorageClass，避免手動管理 PV 的繁瑣工作。資料庫等高 I/O 工作負載應使用 SSD StorageClass 並配置適當的 IOPS 限制。
五、網路設計：CNI 選型
CNI（Container Network Interface）決定 Pod 之間的通訊方式。主流選項比較：
- Calico：使用 BGP 路由，效能優異，支援豐富的 NetworkPolicy，企業環境最常見選擇。適合需要精細網路存取控制的場景。
- Cilium：基於 eBPF 技術，提供比 iptables 更高效的封包處理，同時具備 L7 層的應用程式感知能力。適合高效能需求與進階可觀測性需求。
- Flannel：設計簡單，易於設定，適合開發/測試環境或小型叢集。不支援 NetworkPolicy，不建議用於生產環境。
多數企業生產環境建議選用 Calico 或 Cilium，前者成熟穩定，後者效能更優且可觀測性更強。
六、安全強化
RBAC（角色型存取控制）
最小權限原則：每個服務帳號（ServiceAccount）僅授予執行任務所需的最小權限。禁止使用 cluster-admin 角色於一般工作負載。定期稽核 ClusterRoleBinding，移除不必要的高權限綁定。
Pod Security
使用 Pod Security Admission（PSA）強制 Pod 遵循安全標準：禁止以 root 身份執行、禁止 privileged 容器、強制唯讀 root 檔案系統（僅限可唯讀的工作負載）。
Network Policy
預設情況下，K8s 允許所有 Pod 互相通訊。應建立 NetworkPolicy 實現微分段：每個命名空間（Namespace）設定「預設拒絕全部進出流量」，再明確允許必要的通訊路徑。
Container Image 掃描
在 CI/CD 流水線中整合 Image 掃描工具（如 Trivy、Snyk、Anchore），確保推送至 Registry 的 Image 不含已知 CVE 漏洞。建立 Admission Controller 阻止使用含高危漏洞 Image 的部署。
七、CI/CD 整合
GitOps 方法論
GitOps 以 Git 儲存庫作為叢集狀態的唯一事實來源（Single Source of Truth）。所有的 K8s Manifest、Helm Chart、Kustomize 設定均版本化存於 Git，透過 Pull Request 流程管控變更，具備完整的審計軌跡與回滾能力。
ArgoCD
ArgoCD 是最主流的 GitOps 工具，自動偵測 Git 儲存庫的變更並同步至 K8s 叢集。提供直覺的 Web UI 顯示應用程式部署狀態，支援多叢集管理，適合企業採用。
Jenkins / Jenkins X
傳統 Jenkins 仍被大量企業使用，可透過 Kubernetes Plugin 將 Jenkins Agent 動態建立為 Pod，按需擴縮容。Jenkins X 則針對雲端原生開發流程進行優化，內建 GitOps 支援。
八、企業導入路線圖（4 階段）
容器化轉型建議採用漸進式路線圖，避免一次全面遷移帶來的風險。以下是凱茂資訊建議的四階段規劃。
第一階段：評估與試驗（1–3 個月）
盤點現有應用程式，評估容器化適合度（12-Factor App 符合度）。選擇 1–2 個非關鍵應用進行 Pilot。建立開發/測試 K8s 叢集，讓工程團隊熟悉工具鏈。
第二階段：基礎設施建置（2–4 個月）
建立生產級 K8s 叢集（含 HA Control Plane）。建置 Container Registry、CI/CD 流水線、Observability Stack（Prometheus + Grafana + Loki）。制定安全基線（RBAC、NetworkPolicy、Image 掃描）。
第三階段：漸進遷移（3–9 個月）
依優先順序逐步將現有應用容器化並遷入 K8s。無狀態應用優先，有狀態服務（資料庫等）最後處理或維持 VM 運行。建立藍綠部署/金絲雀發布能力，降低遷移風險。
第四階段：成熟最佳化（持續進行）
導入 GitOps 實現宣告式管理。建立 HPA（水平自動擴縮）與 VPA（垂直自動擴縮）策略。定期安全審查與 K8s 版本升級（建議每年升級，K8s 每 4 個月釋出新版本）。
重點摘要
- K8s 適合微服務（5+ 個服務）、需自動擴展的場景
- 單體應用/小規模不需要 K8s，Docker Compose 就夠
- 中小企業用託管服務（AKS/EKS/GKE），免自建控制平面
- K8s 學習曲線陡峭，導入前確認團隊有足夠能力
容器化轉型需要技術深度與實務經驗，歡迎與我們討論適合您企業的導入路線圖。
預約容器化評估 →