非技術咖眼中：Kubernetes爲何那麼重要？

簡介

Kubernetes旨在做爲你容器的管理層。然而，它的重點是無縫提供給你的應用程序真實實在的須要，知足你的應用程序所依賴的須要。舉個例子，這些應用所需就是由Kubernetes提供的：訪問與供應商無關的數據卷、負載均衡、冗餘控制、彈性擴容、滾動更新以及配置密鑰管理。

有了例如上述的性能和特色，再加上由Docker和容器自己運行時提供的打包件，管理應用程序的實踐（不是servers）纔開始經過使用Kubernetes展開。

Kubernetes的起源

Kubernetes的開始起源於谷歌，它在谷歌系統中有本身的起源：Borg和Omega。許多基於這些系統的設計和安裝的相同概念，已經做爲一個新的表現形式滲入Kubernetes，這個表現形式包括現今的標準，合併了不少谷歌在過去十年裏吸收到的實踐經驗教訓。

Kubernetes不是像不少人開場白講得那樣，是Borg或者Omega的「開源」版本；而是一個谷歌花了不少力氣來爲你的工做和服務建立的新管理工具。Kubernetes在谷歌是利用許多年的架構和實踐經驗開始的，可是由於它是開源項目，並且已經證實它能夠真正簡化開發、操做和管理職責，因此自從它的初始public版本在2014年6月提交後，就積累了愈來愈多的代碼提交貢獻。

這是Kubernetes自從2015年以來收到的代碼提交數量的一個截圖：

這些圖簡短地描述了一個真實的、合做的Kubernetes技術社區。

導言

就像咱們以前提到過的，有不少人以我的名義或者是company名義加入到Kubernentes。然而，真正的問題是，你有沒有像最初開始的那樣，按照谷歌的方式來運行你的應用程序和服務呢？

咱們如今瞭解到的是，Kubernetes不只僅只是一個容器管理系統，它也從內部查看了谷歌爲實踐每個服務和產品：從Gmail、搜索、地圖到GCE（服務產品清單還在持續增加），是如何運行他們的基礎設施的。

所以，Kubernetes也是運行谷歌的一種方式，因此本質上來講，你註冊就是爲了可以訪問一組指定的設計原則，這組原則會讓你的應用程序有效運做，像谷歌那樣輕鬆創建和管理您的應用程序。這並非說，底層系統例如OpenStack或者AWS處理IaaS資源，就不能用了，而是說這些系統都儘量作到最好，而Kubernetes就是爲帶來你的應用程序所須要的一切而生。最終，融合Kubernetes會建立一個良好組件的結合。

因此，若是你正在爲你的項目考慮Kubernetes，那麼你必須信任項目所呈現的基礎和範式，從Pod開始，而後剩下的concepts天然會跟過來。這將給用戶非凡的組合功能和靈活性，Kubernetes自己的視野在從新定義你的應用程序是如何構建的上體現了輔助做用。

Kubernetes爲何重要？

就像最近的關於Borg、Omega和Kubernetes的那篇論文裏提到的細節（論文戳這裏：Borg, Omega和Kubernetes：谷歌十幾年來從這三個容器管理系統中獲得的經驗教訓），Kubernetes幫助創建成套工具來輔助管理和縮放你的應用程序。

如下是Kubernetes如何讓改進應用程序開發的方法：

功能

• 容器將應用環境封裝，從應用程序開發者和基礎設施層面抽象掉不少機器和操做系統的細節。

• 管理API從面向機器轉到面向應用程序，程序部署和檢查極大提升，數據中心也由面向機器轉向面向應用程序。

• 應用程序API的轉換可讓團隊無需擔憂機器和操做系統的細節特性。

• 專一於機器上的應用程序，這也容許團隊以更靈活、更模塊化的方式來操做。

緣由是Kubrnetes是pod的常見使用模式實例，或者說是一個組件，是一個複雜應用程序中能夠編寫，運行以及被一個小團隊全權負責管理功能的組件。

甚至其它的Kubernetes旨在提升你的應用程序的組件，是創建在例如像ReplicationsSets，部署，服務之類的概念之上，所以，合併鞏固全部的應用程序需求，業務政策以及團隊，就變得簡單，能夠無縫銜接。你能夠探測不一樣的Kubernetes的概念，不只僅跟Pod互相做用，並且容許你爲你的應用在《用戶指南詞彙表》裏建立新功能。

不一樣人員的任務角色

Kubernetes也會經過吸引大量不一樣的任務角色來給你的company構架提供幫助。

• 開發者（developers）：不只能夠建立通用的應用，他們還可使用集羣本質的屬性來完成任何應用的特定需求。

  在使用案例之中，devs想要把一個特定的Node做爲目標，或者將一組Nodes做爲目標，表示不一樣的硬件細節的特定標籤能夠用於我的Pod調度。也就是，若是你想要在AMD CPU（而不是Intel）架構上運行你的應用程序，或者你但願利用GPU，甚至是有大數量的RAM的Node。

  消耗各類不一樣的機器在不只在Kubernetes上是可能的，並且它事實上將全部的機器都拉平衡，而且將他們呈現爲一個通用的計算資源。

  這不只由你的應用程序體現了Pets vs. Cattle的意識形態，你的機器也是。

 

• 運維（Devops）：Kubernetes概念，好比像Deployments，replicaSets，Services等等，全部這些都會幫助減輕運維，確保每一個應用都有一個描述性的系列業務政策，並且這些規格都是隨時實施和維護的。

 

• 管理員（Admins）：做爲Kubernetes的一部分，admins能夠經過使用例如像Heapster或者cAdvisor同樣的工具來得到訪問權和流程容器資源，一樣的，檢查集羣的事件，API請求，監測數據，和利用Kubedash作分析。 

 

這些不一樣的軟件度量不只提供檢測Kubernetes集羣服務，並且還提供一個對這些應用程序自身的細粒度理解，由於他們都是單獨控制的。若是不把一些複雜沉重的安裝留給用戶的話，不少在其餘系統裏的應用程序層面的分析是不可能完成的。這些在Kubernetes上的本地功能說明了項目的努力不只是針對你的應用程序的增加，並且這個水準的信息是一個爲你的應用程序肯定的需求，你不應本身建立這個功能，而是該功能應該被經過系統提交給你。

• 其餘：最近，許多不一樣的任務角色能夠跟Kubernetes互相做用，在基礎水準上，經過利用dashboard將你的集羣可視化，同時運行措施：好比建立一個新的資源，好比爲對資源利用標籤進行查詢，好比檢查或生成報告。

 

總體狀況

爲了幫助你們理解Kubernetes大框架是如何運做，咱們來展現的一些圖，能夠幫助你們更好的理解這個項目。

就像James Burker說的：

只有你知道本身去過哪裏，你纔會知道你想去往哪裏

基於這個話，咱們要考慮Kubernetes的鼻祖就是Borg以及它和Borg的極大淵源。從這句話出發，咱們能夠考慮該如何有組織的思考集羣。

讓咱們先來看一些從Borg的論文裏讀到的狀況，這不只可讓咱們一窺Borg是如何配置的，還可讓咱們知道一樣的模型是如何應用到Kubernetes上面的。

這裏咱們能夠看到咱們的首要雲架構從上面看是怎麼樣的。

（圖：跨數據中心的Borg部署）

若是咱們進一步放大，咱們能夠檢測到每一個在數據中心的建設包括了至少一個Borg集羣，它被分紅了約10000個機器：

（圖：Borg系統裏的一個集羣）

再進一步觀察這個「細胞」，咱們能夠一睹控制檯的組件和工人／Nodes的不一樣，以及Kubernetes Pods和Borg裏十分相像，對於任何應用程序後者在整個過程當中的服務，是惟一的原子單元。

（圖：Borg系統裏面一個數據中內心的一個cell，即Borg系統裏一個集羣）

可能就像你如今注意到的那樣，這裏有不少平行的Borg組件，還有如今存在於Kubernetes之中的，特別是1:1相對應的集羣和Pods——這些類似點會讓你在思考聯合Kubernetes配置的時候更快想明白。

雖然Kubernetes目前還不能像Borg那樣每一個集羣規模達到10000個節點，可是它最近已經優化到能夠容許集羣支持最多1000個Nodes和30000個pods，並且99%的API能夠在1秒內呼叫回應，還有99%的Pods（已經有先拉下來的鏡像）在5秒內開啓——鉅額收益表明規模增加10倍，據報道稱根據谷歌的內部人士稱，實際是增加將近14倍。

Kubernetes固然是爲「黃金時間段」準備的，不只是由於許多company都在生產過程當中使用，並且還單純由於它的性能和規模。

結論

咱們但願你可以有更好的理解在現今的軟件發展時代「Kubernents爲何重要」的緣由，也但願你可以更好理解如何組織以及構架你的集羣來使之整合。

去接受Kubernetes的規範，可能一開始看起來像是消防水龍帶但本質上是深思熟慮以後的設計原則，這原則不只爲軟件開發展現適當的方法考慮，還爲每個從ops到管理系統的不論重要仍是輔助的應用程序組件都考慮到了。

 

原文連接：https://corekube.com/2016/03/31/why-does-k8s-matter/#rd?sukey=3903d1d3b699c208f53dd1dab8476f062eee0ab269220e5d359eed2fec6c01f84dec4ba556f14646103f9a9b57aef343

（若是須要轉載，請聯繫咱們哦，尊重知識產權人人有責；）