這一次我們探討的主題是 企業部署 Kubernetes 的終極目標是什麼 。
Kubernetes，是一個開源的，用於管理雲平臺中多個 主機 上的 容器化的應用 。Kubernetes 這個名稱中間有 8 個字母，所以也簡稱為 K8S 。
答案其實不復雜，企業部署 K8S 的終極目標是 節約運營成本 。與此同時，也順帶兼顧到了工程層面自動化的推動。
資源消耗層面
以前的部署，我們是在一臺機器上部署，或者安裝多個虛擬機再部署。虛擬機提供了一套完全隔離的環境，每個虛擬機都有一個屬於自己的內核，這些都屬於重型資源消耗；
而時下所提倡的 K8S，就囊括了一項很重要的容器技術，它調用的是同一個內核，同一個操作系統，也不存在開機、關機的概念，可以採用進程的方式來快速啟動，這在整體上資源消耗就非常少。
組織架構的關注點分離
無論是企業內部，還是雲端服務的部署，成功運行一個應用，交付給業務部門並最終服務於用戶，這是開發者和運維團隊的共同目標。
但他們也有個人目標和驅動因素，熱衷於創造新功能的開發者，通常並不想成為底層操作系統和網絡的維護者，而是交由運維團隊或者系統管理員來做。
運維團隊肯定會負責硬件基礎設施，以及工程化層面的部署流程，但是他們對開發出來的應用程序之間的依賴關係，以及在基礎設施發生改變時，對應用程序可能造成的影響就有些拿捏不準，甚至力有未逮。
這個問題 Google 在好多年前就意識到了，而且也解決了。然後 Google 就把 K8S 開源了，它的強項在於，對硬件資源做了一層抽象（或者說是接口），然後自身會暴露成為一個資源平臺，讓開發者和運維者在這個平臺可以愉快的做組合遊戲，那用來盛放組合元素的實體就叫容器。像這個容器在設計之初，就考慮了跨機連接的需求，讓服務間的通信更便利，這就為時下的微服務又奠定了平臺基礎。
有了以上的抽象平臺，開發者可以自己配置和部署應用程序，而不需要系統管理員經手；作為系統管理員只要聚焦於，確保底層基礎設施運轉正常就可以。
那麼，作為軟件架構師在設計一套系統或者框架時，我們往往都會考慮採用關注點分離這個原則，讓特定問題得以凸顯，然後有針對性的解決。
現在我們昇華一下，在組織架構層面，或者說在敏捷團隊的實踐裡，是不是也可以做關注點分離呢？在我看來呢，K8S 平臺其實就是踐行了 關注點分離，它可以讓開發者和運維人員各司其職，然後再以 Devops 這樣一個流程理念來強化融合，確保溝通順暢。
閱讀更多 RobinTalk 的文章
