同是容器管理系統，Kubernetes為什麼那麼火？

店家小二發表於2018-12-13

Kubernetes允許使用者隨處部署雲原生應用程式，並以其偏好的方式對加以管理。 正如大多數現代軟體開發人員通過實踐所證明，容器技術確實能夠為使用者在物理及虛擬基礎設施之上執行雲原生應用程式提供更為理想的靈活性。容器技術能夠將多層服務打包為一款應用程式，並確保其能夠在不同計算環境之間往來移植，從而實現開發/測試，及生產性使用。
利用容器技術，使用者能夠更輕鬆地啟動應用程式例項，快速滿足峰值需求。另外，由於容器直接使用主機作業系統資源，體量較虛擬機器更輕，這意味著容器能夠高效發揮底層基礎設施的固有優勢。
說到這裡，容器的前途似乎一片光明。然而必須承認，儘管容器執行時API非常適合管理單個容器，但一旦面對著分佈在多臺主機上且擁有數百套容器的大規模應用程式時，這些API就會變得力不從心。在這種情況下，容器需要接受管理並有序接入外部環境，從而實現排程、負載均衡以及分配等任務——Kubernetes正是能夠實現上述目標的一款容器編排工具。   
作為一套用於容器化應用程式部署、擴充套件與管理工作的開源系統，Kubernetes能夠處理計算叢集上的容器排程與工作負載管理，確保其嚴格按照使用者的意願執行。
Kubernetes由谷歌公司構建，融入了其在生產環境內執行容器時積累下的大量專業知識與經驗。眾所周知，谷歌公司擁有眾多全球最為睿智且極具才華的軟體開發人員，亦執行著規模最大的軟體服務體系之一。這樣的體系儲備使得Kubernetes成為一套堅如磐石的平臺，能夠滿足幾乎一切組織機構的規模需求。
在今天的文章中，我們將具體探討Kubernetes的重要意義及其將給DevOps團隊帶來的深遠影響。1.面向當下的各類基礎設施框架時至今日，開發人員往往需要面向多套操作環境編寫應用程式，具體包括本地專用伺服器、虛擬化私有云以及AWS與Azure等公有云。
從傳統角度講，應用程式以及相關工具必須與其底層基礎設施緊密契合。雖然這種作法確實具備一定潛在優勢，但此類部署模型的實施成本亦相當昂貴。這意味著應用程式將在多個方面高度依賴於特定環境，包括與特定網路架構相關的效能特徵、遵循雲服務供應商提出的特定架構（例如專有編排技術）以及對特定後端儲存系統的依賴性等等。
PaaS嘗試解決這些問題，但隨之而來的代價則往往包括在程式語言，以及應用程式框架等領域施以嚴格要求。因此，對於多數開發團隊而言，PaaS通常並不適用。
Kubernetes通過為容器提供核心功能但又不施加強制性約束的方式解決了這種基礎設施鎖定難題。其通過將Kubernetes平臺之內的多項功能加以結合實現這專案標，包括Pods與Services等。2.通過模組化提升管理效果容器技術允許將各應用程式拆分成更小的部分，同時讓各部分擁有更為明確的功能關注點。該抽象層提供的獨立容器映象允許我們從根本上重新考量如何構建分散式應用程式。
另外，這種模組化方法亦使得開發團隊能夠著眼於小處、更為專注地實現功能開發，這意味著各團隊負責對應的特定容器即可。再有，其還允許使用者對依賴關係加以隔離，同時對小型元件更為廣泛地加以調優。
但這一切並不能單純通過容器技術實現，還需要配合一套用於對這些模組化元件加以整合與編排的系統。Kubernetes利用Pods機制實現這一目標。
所謂Pods，代表著能夠作為單一應用程式加以控制的一組容器集合。這些容器共享同樣的資源集，包括檔案系統、核心名稱空間以及IP地址等。通過這種容器協作方式，Kubernetes能夠有效避免將太多功能集中到單一容器映象這樣的錯誤實踐中。
Kubernetes中的Services概念用於將具備類似功能的多個Pods整合為一組。Services可輕鬆進行配置以實現其可發現性、可觀察性、橫向擴充套件以及負載均衡。3.實現軟體的規模化部署與更新Devops是一種新興方法，用於加快軟體構建、測試與釋出的整體過程。其結果是將軟體團隊的關注點由管理基礎設施轉向管理軟體的規模化部署與更新工作。
大多數基礎設施框架並不支援這一模式，但Kubernetes在這方面擁有出色的表現，特別是在KubernetesControllers的支援之下。歸功於這些控制器，使用者能夠輕鬆利用基礎設施管理整個應用程式生命週期。
部署控制器（Deployment Controller）能夠簡化多種複雜的管理任務，例如：
  • 可擴充套件性。軟體可以向外擴充套件跨越多個Pods實現初步部署，且相關部署可隨時進行規模伸縮。
  • 可見性。提供狀態查詢功能以判斷部署工人和的完成情況、當前執行狀態以及失敗問題。
  • 節約時間。使用者可隨時暫停部署並在稍後加以恢復。
  • 版本控制。利用新的應用程式映象版本對已部署Pods進行更新，並在發現當前版本存在不穩定問題時回滾至早期部署版本。

另外，Kubernetes還能夠顯著簡化多種特定部署操作，這一點對於現代應用程式開發者而言極具現實意義。其中具體包括：

  • 自動橫向擴充套件。Kubernetes autoscalers能夠自動根據特定資源的使用量對Pods的部署數量進行調整（在已定義的限制範圍內）。
  • 滾動更新。Kubernetes採取“滾動方式”實現編排，且可跨越部署範圍內的全部Pods。這些滾更新可進行編排，並以預定義方式配合當前可能尚不可用的Pods數量以及暫時存在的閒置Pods數量。
  • 金絲雀部署。作為一項實用性模式，我們在部署新版本之前，通常需要以實驗性方式在生產環境中進行試部署，同時保證新舊版本並行運作。在確定一切正常後，逐步提升新部署規模並同步降低原有部署版本規模。
  • 與存在強烈專用屬性的傳統方案不同，Kubernetes能夠為廣泛的應用型別提供支援。它不會限定應用程式框架（例如Wildfly）、指定受支援語言執行時（Java、Python與Ruby等）、僅適用於12因素應用程式或者區分“應用程式”與“服務”。相反，Kubernetes支援極為廣泛的工作負載型別，其中包括無狀態、有狀態以及資料處理型工作負載。如果應用程式能夠在容器內執行，其即可在Kubernetes上正常起效。

4.為雲原生應用奠定基礎鑑於當前容器技術獲得的高度關注，越來越多管理與編排工具開始陸續出現。目前流行的方案包括Apache Mesos with Marathon、Docker Swarm、AWS EC2 Container Service（簡稱ECS）以及HasiCorp的Nomad。
當然各類方案皆擁有自己的特色與優勢。Docker Swarm能夠與Docker執行時緊密對接，幫助使用者更輕鬆地由Docker過渡至Swarm；Mesos with Marathon不僅限於容器範疇，亦可部署各種型別的其它應用程式；AWS ECS可供AWS使用者輕鬆訪問。
然而，Kubernetes叢集能夠執行在EC2之上，並與AWS旗下的各類服務實現對接，具體包括Amazon彈性塊儲存（Elastic Block Storage）、彈性負載均衡（Elastic LoadBalancing）、自動規模伸縮組（Auto Scaling Groups）等。
這些框架在功能與特性方面存在大量交集，不過憑藉著自身架構、創新成果以及龐大的開源技術社群等優勢，Kubernetes仍然保持著極高人氣。
Kubernetes的出現標誌著DevOps的發展迎來突破，因為其允許開發者充分滿足現代軟體的開發要求。在缺少Kubernetes的情況下，開發團隊常常被迫自行編寫軟體部署、擴充套件及更新工作流。部分企業甚至會建立大型團隊單獨處理此類任務。Kubernetes能夠幫助我們充分發揮容器技術的既有優勢，同時構建起能夠在任意環境下執行的雲原生應用程式，而不再需要受縛於雲特定要求。
總結而言，Kubernetes代表著我們長久以來一直期待的高效應用程式開發與操作模式。

本文轉移K8S技術社群-同是容器管理系統，Kubernetes為什麼那麼火？

相關文章