雲原生概念與 Kubernetes 架構指南 探索現代化開發容器化與微服務實踐的核心技術

什麼是雲原生 (Cloud Native)？

雲原生 (Cloud Native) 是一種構建與運行應用程式的方法論，旨在充分利用雲端計算模型的彈性、擴展性與靈活性。其核心由四大技術支柱組成：微服務 (Microservices)（將單體拆分為獨立服務）、容器化 (Containerization)（如 Docker，確保環境一致性）、持續交付 (CI/CD)（自動化發布流程）與 DevOps（加強開發與運維協作）。透過 Kubernetes (K8s) 等容器編排工具，雲原生架構能實現「不可變基礎設施」與「聲明式管理」，讓系統具備自動修復（Self-healing）與快速迭代的能力，是現代企業數位轉型與建構高可用性服務的關鍵基石。

在當代軟體開發浪潮中，雲原生概念已成為引領技術演進的核心思維。它不僅涵蓋了微服務架構設計的精髓，更將容器化技術推向主流，徹底改變了應用程式的打包與部署方式。

隨著 Kubernetes 入門門檻的降低，其強大的容器編排能力，使得 DevOps 實踐得以高效落地，實現從開發、測試到部署的全生命週期自動化。這股變革力量，正驅動著企業加速創新，構建更具彈性、可擴展與高效率的雲端應用。

雲原生 (Cloud Native)

雲原生 (Cloud Native) 是指在雲端原生架構上，規劃設計更方便擴展 (Scalable) 的軟體服務或應用。它的發展與軟體的開發、架構、運算和雲端儲存單元演進息息相關：

• 軟體開發: 瀑布式開發 -> 敏捷式開發 -> DevOps。
• 軟體架構: 單層式架構 -> 多層式架構 -> 微服務。
• 運算單元: 實體機 -> 虛擬機 -> 容器化 (Containerization)。
• 雲端儲存: 資料中心 -> 服務代管 -> 雲端 (公有、私有、混合)。

雲原生常見架構和技術包括：

• 微服務 (Microservice)
• 容器 (Container)
• 容器管理 (Kubernetes)
• 服務網格 (Service meshes)
• 不可變的基礎設施 (Immutable infrastructure)
• 聲明式 API (Declarative API)

Cloud Native Computing Foundation (CNCF) 定義了導入雲原生的主要五個步驟：容器化、CI/CD、編排與應用定義、可觀測性與分析、服務代理、發現、網格 (Service Mesh)。

微服務 (Microservice)

微服務其實就是將大型單體架構的服務，分別依照屬性或業務邏輯拆分部屬後的服務，透過雲端的架構可以更好的水平或垂直擴展並且進行迭代和更新。部署過後增加的複雜度是：

1. 更多服務間的溝通需要被連結。
2. 更多的服務生命週期需要被管理和監控。
3. 服務重啟的時候該怎麼做到 Zero Downtime。

通常一個微服務用觀念的角度看，主要會包含 Service 跟 Job 兩個部分：

• Service:
  • Non-Background Service: 不能死掉的服務。
  • Background Service: 像是監控之類的服務。
• Job:
  • One Time Job: 服務起來之後需要執行的。
  • Cron Job: 定時執行。

Service Cluster 的概念也蠻值得理解的，通常就是用來處理：

1. 增加高可用性 (High Availability) 或是備援。
2. 拿來做附載平衡 (Load Balancing)。
3. 增加平行運算的處理量。

常見的 HA 模式，需考量多台機器怎麼互相知道對方狀態以及能自動啟動或停止，停止後怎麼恢復相關的資料：

• Active/Passive Mode (AP) 或是 Active/Standby Mode (AS): 用途是 HA 一台起著一台待命。
• Active/Active Mode (AA): 用途是 Load Balancing 跟 AP 差別不大，問題是當 AA 有一台掛了之後只剩一台能不能撐住兩台的流量。

容器 (Container)

微服務不一定需要容器實現，但容器相對於虛擬機較輕量也更方便去封裝和部屬。容器是一個透過設定檔建置出來的映像檔運行起來的服務：

• Docker Container: Image 執行後會產生的執行環境。
• Image: 透過 IaC (Infrastructure as Code) 來定義服務執行環境所建置出來的映像檔。
• Repository: 存放 Image 的地方。

PS: Java EE Web 的容器是用來 deploy 各種 Web Application 用的，概念不太一樣。

容器管理 (Kubernetes)

Kubernetes 是管理容器與服務的開源平台，主要分 Control Plane 跟 Worker Node 兩大塊：

• Control Plane:

  • kube-apiserver: 對外窗口。
  • etcd: 紀錄狀態方便 failover。
  • kube-scheduler。
  • kube-controller-manager。
  • cloud-controller-manager。

• Worker Node:

  • kubelet、kube-proxy、container runtime。

Worker Node 用層級來看：

• Cluster: 多個 Node 的集合。
  • Node: 可以看成是某台 VM，Work Node 會負責把 Pod 跑起來。
    • Namespaces: 可以依照使用情境或產品別去分類及管理相關的 Deployment。
      • Deployment: 依照需求透過 ReplicaSet 描述 Pod 要開多少個怎麼去 Deploy。
        • Pod: 最小的 Deploy 單位，包含多個 container。
          • Container: Docker 的容器。

在管理 Pod 上通常會透過 Deployment 來進行部屬 Deployment -> ReplicaSet -> Pod，除此之外還有兩種部署 Pod 的方法：

• statefulset: 像是資料庫服務需要一對一的關係就適合使用。
• daemonset: 較偏系統面 (ex: 收 Log 的服務)，寫 AP 的較不需要處理。

一個 Kubernetes Components 主要包含 Pod 跟 Service 兩個部分：

• Pod: 最小的 Deploy 單位，描述服務是怎麼構成。包含 image 與 port。
• Service: 描述如何存取服務，Ingress -> Service -> Pod。包含 protocol、port、node port、target port (對應到 Pod 的 port)。

為什麼要使用 Kubernetes？

維護上需思考服務設計是否適合放在 k8s 上，例如 OOM 後會關掉並重啟，相關機制該怎麼設計？

• K8s 維運相關設定: 要給多少 CPU、MEM 才可以避免 OOM 的問題。
• Failover、debug: k8s 因為多了一層會增加 debug 的難易度。
• 升級與修補: Node 會需要常常更新，服務要怎麼做到 Zero Downtime。

K8s 部署的好處在於統一的管理介面，並且因為是 IaC 的關係，服務會更加安全。

• 資料備份與恢復: 方便程度：代管服務 > K8s > VM。
• 監控、觀測與警示: 方便程度：代管服務 > K8s > VM。

成本上需要考量執行成本、維護成本、人力成本。

• 最佳化: 通常實體機或是 VM 的最佳化都比較簡單調整，K8s 較複雜。
• 人力成本: 維護 K8s 需要理解服務、VM 與 K8s 本身。

服務網格與不可變基礎設施

服務網格 (Service meshes)

常見解決方案為 Istio，微服務啟動後會透過服務代理 (Sidecar Proxy) 處理。

• Container Network Interface (CNI): 管理分配 Pod IP 與網路限制。
• Software Defined Networking (SDN): 用軟體去管理網路決策，如 Nginx 就是很好的負載平衡軟體定義網路代理。

不可變的基礎設施 (Immutable infrastructure)

當服務被部屬後就不可被修改，若有需要更新都需要透過 YAML 檔來更新。

聲明式 API (Declarative API)

告訴電腦該完成什麼，顯示的是結果，所以每次修改都是透過 kubectl apply YAML 來驅動相關的改變。

FAQ：雲原生與 K8s 常見問題

Q1：我只是一個小專案，也需要導入 K8s 嗎？

A：不一定。 K8s 解決的是「大規模容器編排」的複雜度。如果您的專案只有少數幾個服務，直接使用 Docker Compose 或公有雲的 App Runner / Cloud Run 託管服務會更經濟實惠且維運壓力更小。

Q2：什麼是「不可變基礎設施 (Immutable Infrastructure)」？

A：這意謂著當服務部署後，我們絕不進入容器手動修改設定（如 SSH 進去改 Nginx Config）。如果有變更需求，應修改原始碼或 YAML 檔，建置新的 Image 並重新部署。這能確保環境的 100% 可重現性。

Q3：K8s 中的 Service 與 Ingress 有什麼區別？

A：Service 負責 Cluster 內部的負載平衡與服務發現（讓 Pod 互相找到對方）；而 Ingress 則是 Cluster 的「大門」，負責處理外部流量進入 Cluster 的路由規則（如網域名稱與路徑分發）。

• ← 上一篇
• 下一篇 →