要真正了解 Kubernetes，我們需要討論從傳統部署到 Kubernetes (K8s) 部署的演進過程，探討前人在這個過程中遇到的困難，以及 Kubernetes 所承載的願景。

部署技術的演進

傳統部署

在早期，應用程式部署主要依賴於實體伺服器：

• 獨立伺服器：每個應用程式運行在專用的物理伺服器上。這樣的方式導致資源浪費，因為不同應用程式的資源需求不同，且伺服器通常不能滿負荷運行。
• 手動部署：需要手動安裝和配置軟體，過程繁瑣且容易出錯。應用程式升級和維護也非常困難。

虛擬化

為了提高資源利用率，虛擬化技術開始被廣泛採用：

• 虛擬機 (VM)：在單個物理伺服器上運行多個虛擬機，每個虛擬機都有自己的操作系統和資源。這樣可以更有效地利用硬體資源，並提高應用程式的隔離性和安全性。
• 虛擬機管理工具：如 VMware、Hyper-V 等工具幫助自動化部分部署流程，但仍需要較多的手動干預。

配置管理工具

為了簡化和自動化部署流程，配置管理工具被引入：Ansible、Puppet、Chef 等這些工具幫助自動化配置和部署過程，減少了手動操作，並提高了一致性和可重現性。

容器化

隨著 Docker 在 2013 年的出現，容器技術變得流行。容器比虛擬機更輕量，啟動速度快，資源利用率高，且能提供類似的隔離性。透過將應用程式及其依賴打包成容器，確保在任何環境下都能一致運行。

雖然容器化解決了應用程式的一致性問題，但隨著應用程式規模的擴大，如何管理大量的容器成為新的挑戰。單個應用程式可能需要多個容器，這些容器需要協同工作、彈性擴展、健康檢查、負載均衡等功能。手動管理這些容器非常困難，因此需要一個自動化的解決方案來編排容器。

Kubernetes (K8s)

Google 多年來在內部使用 Borg 系統來管理其大規模的應用程式和服務。2014 年，Google 將其經驗公開並開源了一個新的容器編排系統，這就是 Kubernetes。它的名字來自希臘語，意為「舵手」或「導航員」，寓意幫助管理和導航應用程式的運行。

Google 與 Linux 基金會合作組建了 Cloud Native Computing Foundation (CNCF) 並將 Kubernetes 作為種子技術來提供。越來越多的企業採用容器技術，Kubernetes 成為事實上的標準。它提供了自動化部署、擴展和運維的能力，並且具有很強的彈性和擴展性。Kubernetes 的社群非常活躍，持續為其開發新功能和改進性能。

Kubernetes 作為一個強大的容器編排平台，徹底改變了如今的部署方式。

為什麼要使用 Kubernetes？

1. 自動化管理：Kubernetes 能自動處理容器的部署、維護、擴展和故障恢復，減少了手動操作和錯誤。
2. 彈性擴展：根據應用程式的需求，自動擴展或縮減容器數量，確保資源的高效利用。
3. 服務發現和負載均衡：自動將流量分配到健康的容器，確保應用程式的穩定運行。
4. 自動恢復：容器故障時，Kubernetes 能自動重啟或重新部署，確保應用程式的高可用性。
5. 持續部署和回滾：支持藍綠部署、金絲雀發布等，讓應用程式更新更平滑、更安全。
6. 資源隔離和管理：通過命名空間和資源配額等功能，實現不同應用程式和團隊之間的隔離和資源控制。
7. 廣泛支持和生態系統：Kubernetes 被眾多雲服務提供商支持，有豐富的插件和擴展，能與現有的 DevOps 工具鏈無縫集成。

小結

Kubernetes 旨在提供「跨主機叢集的自動部署、擴充以及執行應用程式容器的平台」

我認為這句話足以代表著如今使用 K8s 的原因。

作為 AWS 平台的重度使用者，在接觸 Kubernetes 之前，我的部署設計主要停留在容器化階段。在日常工作中，設計部署、制定監控方案、服務之間的耦合，以及將這些元素整合成一個可行的流程，已經讓我感到非常困難。如果再需要將架構轉移或混合使用現有或未來的雲端服務，簡直就是一場災難。Kubernetes 的出現，就像一種標準化的規範，為我提供了更靈活、高效的解決方案。

參考

• Docker 與 VM — 應用程式部署技術之間的差異-AWS (amazon.com)
• Kubernetes - 維基百科，自由的百科全書 (wikipedia.org)
• Introduction to Kubernetes on vSphere (Part 1) (cloudthat.com)