雲的革命（二）容器的來臨

容器的來臨

     要部署一個軟件，您不只須要軟件自己，還須要其依賴性。這意味着庫，解釋器，子包，編譯器，擴展等。您還須要其配置。設置，站點特定的詳細信息，許可證密鑰，數據庫密碼：將原始軟件轉換爲可用服務的全部內容。最早進的解決此問題的早期嘗試包括使用配置管理系統，例如Puppet或Ansible，其中包含用於安裝，運行，配置和更新運輸軟件的代碼。 或者，有些語言提供了本身的打包機制，如Java的JAR文件，Python等或Ruby的gems。可是，這些是特定於語言的，並不能徹底解決依賴性問題：例如，在運行JAR文件以前，仍須要安裝Java運行時。

     另外一種解決方案是omnibus軟件包，顧名思義，它試圖將應用程序所需的全部內容塞入單個文件中。 omn​​ibus軟件包包含軟件，其配置，相關軟件組件，其配置，依賴關係等。 （例如，Java omnibus包將包含Java運行時以及應用程序的全部JAR文件。） 一些供應商甚至更進一步，包括運行它所需的整個計算機系統，做爲虛擬機映像，但這些是龐大而笨拙的，構建和維護耗時，操做易碎，下載和部署速度慢，而且在性能和資源足跡方面效率極低。 從操做的角度來看，您不只須要管理這些不一樣類型的軟件包，還須要管理一組服務器來運行它們。 服務器須要進行配置，聯網，部署，配置，保持最新的安全補丁，監控，管理等。

     這一切都須要大量的時間，技能和精力，只需提供一個運行軟件的平臺。有沒有更好的方法？ 在盒子裏面思考 爲解決這些問題，科技行業借鑑了航運業的一個想法：集裝箱。在20世紀50年代，一位名叫馬爾科姆·麥克萊恩的卡車司機提出，不是費力地將貨物單獨地從卡車拖車上卸下來，而是將貨物運到港口並裝上船隻，卡車自己就能夠裝上船 - 或者更確切地說，卡車車身。

    卡車拖車本質上是車輪上的大金屬箱。若是您能夠將箱子 - 容器 - 與用於運輸它的輪子和底盤分開，那麼您能夠很容易地擡起，裝載，堆疊和卸載，而且能夠直接進入另外一艘船上或另外一輛卡車上。航程結束（1-3）。

放入軟件至容器

     軟件容器的概念徹底相同：標準的包裝和分發格式，通用且普遍，可大大提升承載能力，下降成本，實現規模經濟，易於處理。容器格式包含應用程序運行所需的全部內容，並將其烘焙到可由容器運行時執行的映像文件中。 這與虛擬機映像有何不一樣？這也包含應用程序須要運行的全部內容 - 但除此以外還有不少內容。典型的虛擬機映像大約爲1 GiB.1另外一方面，精心設計的容器映像可能要小一百倍。

    因爲虛擬機包含許多不相關的程序，庫以及應用程序永遠不會使用的東西，所以大部分空間都被浪費了。經過網絡傳輸VM映像遠比優化容器慢。 更糟糕的是，虛擬機是虛擬的：底層物理CPU有效地實現了虛擬機運行的模擬CPU。虛擬化層對性能產生了巨大的負面影響：在測試中，虛擬化工做負載比同等容器慢約30％。

    相比之下，容器直接在真實CPU上運行，沒有虛擬化開銷，就像普通的二進制可執行文件同樣。 並且由於容器只保存他們須要的文件，因此它們比VM圖像小得多。他們還使用了一種聰明的可尋址文件系統層技術，能夠在容器之間共享和重用。

    例如，若是你有兩個容器，每一個容器都來自相同的Debian Linux基礎映像，那麼基本映像只須要下載一次，每一個容器均可以簡單地引用它。 容器運行時將聚集全部必需的層，若是還沒有在本地緩存，則只下載一個層。這樣能夠很是有效地利用磁盤空間和網絡帶寬。

 即插即用應用程序

     容器不只是部署單位和包裝單位; 它也是重用的單元（相同的容器映像能夠用做許多不一樣服務的組件），擴展單元和資源分配單元（容器能夠在任何可用於其自身特定需求的足夠資源的狀況下運行）。

     開發人員再也不須要擔憂維護不一樣版本的軟件以在不一樣的Linux發行版上運行，針對不一樣的庫和語言版本，等等。 容器惟一依賴的是操做系統內核（例如Linux）。 只需在容器映像中提供應用程序，它就能夠在任何支持標準容器格式並具備兼容內核的平臺上運行。

     Kubernetes開發人員Brendan Burns和David Oppenheimer在他們的論文「基於容器的分佈式系統的設計模式」中採用了這種方式：

 經過密封，攜帶它們的依賴關係，並提供原子部署信號（「成功」/「失敗」），[容器]顯着改進了在數據中心或雲中部署軟件的先前技術水平。 但容器有可能不只僅是一個更好的部署工具 - 咱們相信它們註定會變得相似於面向對象軟件系統中的對象，所以將可以開發分佈式系統設計模式。帶寬。

 容器管絃樂隊

      運營團隊也發現容器大大簡化了他們的工做量。他們所要作的就是運行一個容器協調器，而不是必須維護各類機器，體系結構和操做系統的龐大空間，這是一個旨在將許多不一樣機器鏈接到一個集羣中的軟件：一種統一的計算基板，在用戶看來是一個很是強大的計算機，容器能夠在其上運行。

     術語編排和調度一般做爲同義詞鬆散地使用。可是，嚴格地說，在這種狀況下，編排意味着協調和排序不一樣的活動以服務於共同目標（如管絃樂隊中的音樂家）。調度意味着管理可用資源並分配能夠最有效地運行的工做負載。 （不要與在預設時間執行的預約做業意義上的計劃混淆。）

    第三個重要的活動是集羣管理：將多個物理或虛擬服務器鏈接成一個統一，可靠，容錯，明顯無縫的組。 術語容器協調器一般指的是負責調度，編排和集羣管理的單個服務。

集裝箱化（使用容器做爲部署和運行軟件的標準方法）提供明顯的優點，事實上的標準容器格式使各類規模經濟成爲可能。可是容器的普遍採用仍然存在一個問題：缺少標準的容器編排系統。

     只要用於調度和編排容器的幾種不一樣工具在市場上競爭，企業就不肯意對使用哪一種技術進行昂貴的投注。但全部這一切都將改變。

Kubernetes

      谷歌長期以來一直在爲生產工做負載運行容器。 幾乎全部Google服務都以容器形式運行：Gmail，Google搜索，Google地圖，Google App Engine等。 因爲當時沒有合適的容器編排系統，谷歌被迫發明一個。

     從博格到Kubernetes

     爲了解決在數百萬臺服務器上全球範圍內運行大量服務的問題，Google開發了一個名爲Borg的私有內部容器編排系統。Borg本質上是一個集中管理系統，它分配和調度容器以在服務器池上運行。雖然很是強大，但博格與谷歌本身的內部和專有技術緊密相連，難以擴展，不可能向公衆發佈。

     2014年，Google根據從博格及其繼任者歐米茄得到的經驗教訓，建立了一個名爲Kubernetes的開源項目（來自希臘語，意思是「舵手，飛行員」），該項目將開發一個每一個人均可以使用的容器協調器。Kubernetes的崛起是曇花一現。雖然其餘容器編排系統在Kubernetes以前就已存在，但它們是與供應商相關的商業產品，這一直是其普遍採用的障礙。隨着真正的免費和開源容器協調器的出現，容器和Kubernetes的採用開始以驚人的速度增加。

     到2017年末，管絃樂隊戰爭結束了，Kubernetes贏了。雖然其餘系統仍在使用，但從如今開始，但願將基礎設施轉移到容器的公司只須要針對一個平臺：Kubernetes。

     是什麼讓Kubernetes如此寶貴？

     Kelsey Hightower是Google的員工開發人員，Kubernetes Up＆Running（O'Reilly）的合着者，以及Kubernetes社區的全能傳奇人物，他這樣作：Kubernetes完成了最好的系統管理員所作的事情：自動化，故障轉移，集中式日誌記錄，監控。它須要咱們在DevOps社區中學到的東西，並使其成爲默認的，開箱即用。

凱爾西海托爾許多傳統的系統管理員任務（如升級服務器，安裝安全補丁，配置網絡和運行備份）都不是雲本地世界關注的問題。 Kubernetes能夠爲您自動執行這些操做，以便您的團隊能夠集中精力完成其核心工做。

     其中一些功能（如負載平衡和自動擴展）內置於Kubernetes核心中;其餘由附加組件，擴展程序和使用Kubernetes API的第三方工具提供。 Kubernetes生態系統很大，而且一直在增加。

Kubernetes讓部署變得簡單

     因爲這些緣由，Ops工做人員喜歡Kubernetes，但開發人員也有一些顯着的優點。 Kubernetes大大減小了部署所需的時間和精力。零停機部署很常見，由於Kubernetes默認會進行滾動更新（使用新版本啓動容器，等待它們變得健康，而後關閉舊版本）。

     Kubernetes還提供了一些工具來幫助您實施持續部署實踐，例如canary部署：逐個推出一個服務器的更新，以便及早發現問題（請參閱「Canary Deployments」）。另外一種常見的作法是藍綠色部署：並行啓動新版本的系統，並在流量徹底啓動並運行後將流量切換到它（請參閱「藍/綠部署」）。

     需求高峯將再也不下降您的服務，由於Kubernetes支持自動縮放。例如，若是容器的CPU利用率達到必定水平，Kubernetes能夠繼續添加容器的新副本，直到利用率低於閾值。當需求降低時，Kubernetes將再次縮減副本，釋放羣集容量以運行其餘工做負載。

     因爲Kubernetes內置了冗餘和故障轉移功能，所以您的應用程序將更加可靠和靈活。一些託管服務甚至能夠根據需求上下調整Kubernetes集羣自己，這樣您就不會爲任何特定時刻所需的集羣付費（參見「自動調節」）。

    該公司也會喜歡Kubernetes，由於它能夠下降基礎設施成本並更好地利用一組資源。傳統服務器，甚至是雲服務器，大多數時候都處於空閒狀態。處理需求高峯所需的過剩產能在正常狀況下基本上被浪費了。

     Kubernetes利用浪費的容量並使用它來運行工做負載，所以您能夠實現更高的機器利用率 - 而且您也能夠免費得到擴展，負載平衡和故障轉移。雖然其中一些功能（如自動擴展）在Kubernetes以前可用，但它們始終與特定的雲提供商或服務相關聯。 Kubernetes與提供程序無關：一旦定義了您使用的資源，就能夠在任何Kubernetes集羣上運行它們，而無論底層雲提供程序如何。

     這並不意味着Kubernetes將你限制在最低的標準。 Kubernetes將您的資源映射到適當的供應商特定功能：例如，Google Cloud上的負載均衡，Kubernetes服務將建立Google Cloud負載均衡器，在Amazon上它將建立AWS負載平衡   

正如容器是一種定義軟件的可移植方式同樣，Kubernetes資源提供了該軟件應如何運行的可移植定義。

 Kubernetes會消失嗎？

     奇怪的是，儘管Kubernetes目前使人興奮，但在將來幾年咱們可能不會談論它。曾經是新的和革命性的許多東西如今都是計算結構的一部分，咱們並無真正考慮它們：微處理器，鼠標，互聯網。

     Kubernetes也可能會消失併成爲管道的一部分。這很無聊：一旦你瞭解了將你的應用程序部署到Kubernetes須要瞭解的內容，你或多或少都會完成。 Kubernetes的將來極可能主要在於託管服務領域。虛擬化曾經是一項使人興奮的新技術，如今已經成爲一種實用工具。大多數人從雲提供商處租用虛擬機，而不是運行本身的虛擬化平臺，例如vSphere或Hyper-V。

一樣地，咱們認爲Kubernetes將成爲管道的標準部分，你不會再知道它了。 Kubernetes並非所有， 將來的基礎設施是否徹底基於Kubernetes？可能不是。首先，有些東西不適合                  Kubernetes（例如數據庫）： 在容器中編排軟件涉及啓動新的可互換實例，而無需在它們之間進行協調。但數據庫副本不可互換;它們每一個都具備惟一的狀態，部署數據庫副本須要與其餘節點協調，以確保模式更改等同時發生在任何地方： Sean Loiselle（蟑螂實驗室）

    儘管在Kubernetes中運行具備企業級可靠性的數據庫等狀態工做負載是徹底可能的，但它須要大量的時間和工程投入，這對您的公司來講可能沒有意義（參見「運行較少的軟件」）。相反，使用託管服務一般更具成本效益。 其次，有些東西實際上並不須要Kubernetes，而且能夠運行在有時稱爲無服務器平臺，更好的命名功能即服務或FaaS平臺上。

雲功能和全功能

     例如，AWS Lambda是一個FaaS平臺，容許您運行用Go，Python，Java，Node.js，C＃和其餘語言編寫的代碼，而無需編譯或部署應用程序。亞馬遜爲您作到了這一切。 由於您須要以100毫秒的增量爲執行時間付費，因此FaaS模型很是適合僅在您須要時運行的計算，而不是支付雲服務器，不管您是否正在使用它，它都會一直運行或不。 在某些方面，這些雲功能比容器更方便（儘管一些FaaS平臺也能夠運行容器）。但它們最適合於簡短的獨立做業（例如AWS Lambda將功能限制爲運行時間的15分鐘，以及大約50 MiB的已部署文件），尤爲是那些與現有云計算服務集成的服務，例如Microsoft Cognitive Services或Google Cloud Vision API。

    爲何咱們不喜歡將此模型稱爲無服務器？嗯，它不是：它只是別人的服務器。關鍵是您沒必要配置和維護該服務器;雲提供商會爲您處理。

    並不是全部工做負載都適合在FaaS平臺上運行，但它仍然可能成爲將來雲原生應用程序的關鍵技術。 雲功能也不限於Lambda或Azure功能等公共FaaS平臺：若是您已經擁有Kubernetes集羣並但願在其上運行FaaS應用程序，OpenFaaS和其餘開源項目就能夠實現這一點。這種功能和容器的混合有時被稱爲funtainers，咱們以爲這個名字頗有吸引力。

     Kubernetes的一個更復雜的軟件交付平臺，包括容器和雲功能，稱爲Knative，目前正在積極開發中（參見「Knative」）。這是一個很是有前途的項目，這可能意味着未來容器和功能之間的區別可能會模糊或消失。