為什麼要學 Kubernetes？
2026年7月17日 下午6:11 · 閱讀 4 分鐘
系列文章： Kubernetes 筆記 （第 1 篇）
楔子
Kubernetes 內容龐雜，光是想跟著 官方文件 了解基礎就相當費時費力。就算苦心研究一陣子，仍可能依舊在五花八門的教學文海洋裡迷航著。
因此此次學習筆記會從結果出發，先試著理解 Kubernetes 能帶來的好處，想想看沒有 Kubernetes 的話會遇到哪些麻煩。未來學習 Kubernetes 細節內容時，就能回過頭來用這些優點做導引，學起來就比較不會感覺那麼雜亂無章。
為何要學 Kubernetes？
對 K8s 有興趣的人應該都已經有了容器部署（Container Deployment）的基本概念，為了一次開關多個容器，可能也撰寫過 docker-compose.yml。但若是系統的規模繼續增長呢？如果系統流量高低峰差異很大，那每個服務究竟需要部署幾個容器才夠？如果臨時有伺服器掛了，或是想進行系統版本升級，系統可以保持服務不中斷嗎？
The name Kubernetes originates from Greek, meaning helmsman or pilot.
「Kubernetes」原始詞義為「舵手」或是「領航員」，想傳達的便是它「指揮大量 Docker 容器」的角色。前述提到的難點，都能透過 Kubernetes 來幫我們自動解決（非常厲害..）。以下再介紹幾個 Kubernetes 做得到的事情。
多才多藝的 Kubernetes
負載平衡 Load Balancing
當網路流量很大時，Kubernetes 可以自動幫忙均分流量給不同容器，讓部署可以保持穩定。
滾動更新 Rolling Update
進行版本升級時（更新 image），Kubernetes 會逐一替換現有服務的舊 images，確保容器健康後才會更新下個容器，若不健康則進行回滾（Rollback），換回舊的健康 image。只要服務有兩台容器以上，即可在服務不斷的情況下完成系統更新。
水平擴展 Horizontal Scaling
只要告訴 Kubernetes 要監控的資源指標，Kubernetes 就能自動依據流量，隨時增減該服務部署的容器數目。（例如 CPU 用量 > 70% 時就增加容器，CPU 用量 < 40% 時就減少容器）
壞了請自己修 Self-Healing
只要告訴 Kubernetes「此服務我需要 3 台容器」，Kubernetes 就會 24 小時不斷電地檢查部署環境中是否存在 3 台健康容器。若有容器壞了，Kubernetes 就會嘗試透過重啟等方式修復，或是直接再開一台新的，以保持系統中隨時有 3 台健康容器在運作。
伺服器好多我不想記 Automatic Bin Packing
若伺服器不只一台，每次部署容器都必須決定該容器要部署在哪一台伺服器上。但在反覆地系統更新、擴展、容器修復之後，要搞清楚每台容器在哪就變成一件很繁瑣的事情。
Kubernetes 能透過監控每台伺服器現有的剩餘資源，自動將新容器部署到最合適的機器上。提高硬體資源使用效率，並除去人工管理的麻煩。
後續系列文的編排
Kubernetes 的強大功能，多虧的便是背後複雜的龐大系統架構設計與各種包裝，也是 Kubernetes 學習曲線令人望之卻步的緣由。與其嘗試直接理解 Kubernetes 的龐大系統細節，不仿先將專注力放在理解 K8s 在應用的最上層究竟幫我們做了什麼樣的抽象化。
因此在系列文中，筆者會將焦點放在如何使用實際部署時最常見的幾種「Kubernetes 物件」，例如 Deployment, StatefulSet, Service, PersistenceVolume, ConfigMap, Role 等等。而為了能夠靈活使用以上資源物件，也會介紹 Kubernetes 系統的基本架構與抽象化的運作邏輯。
相關參考資料