先來張時代的眼淚

圖片來源(官網資料)

• 最原始的實體主機一台一台設定環境：純手工，因為硬體配置都是固定的，如果需求成長時，資源不夠時，只能進行實體機的升級(加ram或是加cpu)才能解決，而且有實體主機的維護成本。

• vm主機上面架設多台虛擬機：可透過快照機制進行大量主機複製，但是每台主機還是需要安裝os跟設定環境，優點在如果原本的host主機資源夠強大，可以一直開主機出去使用

• 容器化的時代：只要在實體機上面裝好container的runtime，執行一個一個獨立的container，因為container主身已經自帶好os，不需要再安裝os這條路，但是如果需要安裝一些套件還是需要在產生container時寫好shell，
  ，因為container主身可自帶os，不會被host的os綁住，but windows的container只能跑在window的container runtime上面，無法在linux的container runtime上面運行window container就是了。
  而使用容器化有以下好處理：

敏捷應用程式的創建和部署：與使用 VM 鏡像相比，提高了容器鏡像創建的簡便性和效率。
持續開發、集成和部署：通過快速簡單的回滾（由於鏡像不可變性），支援可靠且頻繁的 容器鏡像構建和部署。
關注開發與運維的分離：在構建/發佈時而不是在部署時創建應用程式容器鏡像， 從而將應用程式與基礎架構分離。
可觀察性：不僅可以顯示操作系統級別的資訊和指標，還可以顯示應用程式的運行狀況和其他指標信號。
跨開發、測試和生產的環境一致性：在攜帶型電腦上與在雲中相同地運行。
跨雲和操作系統發行版本的可移植性：可在Ubuntu、RHEL、CoreOS、本地、 Google Kubernetes Engine 和其他任何地方運行。
以應用程式為中心的管理：提高抽象級別，從在虛擬硬體上運行OS到使用邏輯資源在OS上運行應用程式。
鬆散耦合、分散式、彈性、解放的微服務：應用程式被分解成較小的獨立部分， 並且可以動態部署和管理 - 而不是在一台大型單機上整體運行。
資源隔離：可預測的應用程式性能。
資源利用：高效率和高密度。

其實說了那麼落落長
使用k8s不外是為了它的以下特性
1.load balancing：負載平衡如果沒有k8s進行處理的話，勢必需要自己開發服務或是程式進行load balaning，實不實用又是一回事，想喝牛奶沒有必要自己養頭牛，尤其又是軟體巨頭開源與各神人turning過專案。
2.Automated rollouts and rollbacks ：透過k8s進行部署服務，可以透過部署策略進行服務上下架的模式，不會讓服務需要中斷服務才能更新，相對的~如果遇到需要退版時，也不會需要先把連線踢掉才能進行退版，一切都在無痛中進行(相對也需要服務的無狀態化就是了)
3.Self-healing：自我健康檢查，當container異常時，k8s會自行進行重啟，不會讓服務中斷。

參考資料：
What is Kubernetes?