什麼是K8s？業務流程如何重新定義數據中心
經過四年多一點的時間，這個誕生於谷歌內部容器管理工作的項目已經顛覆了VMware、微軟、Oracle以及其他所有可能成為數據中心之王的公司的最佳計劃。到底是什麼改變了一切?
Kubernetes是什麼?
對於那些在操作系統是所有軟件所依賴的平臺的時代，建立數據中心的目的和功能的概念的人來說，Kubernetes的目的並不是顯而易見的。Kubernetes是軟件資源的大規模持續重新調整的產物，這些資源共同構成了網絡應用程序。該對齊以稱為工作負載的概念為中心，該概念是由多個處理器中的一個或多個應用程序或一個或多個服務執行的作業的廣義概念。
工作量是一項工作——例如，管理供應鏈、監督物流、跟蹤庫存、促進證券市場。Kubernetes已經成為現代的工作控制系統。
"你可以把Kubernetes看作是一個應用程序模式的平臺，"谷歌軟件工程師Janet Kuo在2017年Kubecon會議上的指導課程中解釋道。這些模式使您的應用程序易於部署、運行和保持運行。"
虛擬機的優點正在衰退
越來越多的數據中心基礎設施致力於關注工作負載的健康狀況，而不是服務器的健康狀況。無論是物理處理器還是虛擬機，服務器都可能出現故障。該故障對這些工作負載的可用性和功能的影響應該小於最小值——它們根本不應該受到影響。
直到2016年，開源社區已經提出了一些方法來編排工作負載以獲得最大可用性。在很短的時間內，Kubernetes成為投資於開源的企業的選擇。原因可以寫一整本書，如果寫得足夠好，它可以被改編成藝術劇院的電影之一，贏得評論家的好評，但從來不會贏得奧斯卡獎。
也許，這是唯一的原因：谷歌推動Linux基金會建立雲計算基金會（CNCF）的早期舉措給了Kubernetes足夠的時間來在最廣泛的人群中有機地培養出一個追隨者。整個開源業務模型圍繞著支持的價值。不再希望被鎖定在單一供應商（誠然，不是所有人）中的企業都欣賞支持系統中新發現的多元主義價值。一組供應商，如果不是總是一致行動，那麼至少是為了同一個目標而進行的一些協調，比一個單獨的供應商在沒有特定方向上領導壟斷平臺要好。
為什麼Kubernetes現在很重要
Kubernetes並不屬於任何一家公司，儘管它基於一個名為Borg的項目，該項目最初是在谷歌內部開發的，而谷歌通常被認為是Kubernetes開發社區的實際領導者。也就是說，微軟已經完全圍繞Kubernetes重新調整了整個服務器系統的理念，並聘請了幾位主要的創造者。作為一個開源項目，Kubernetes由Linux基金會的代理機構——雲原生計算基金會(CNCF)管理。
谷歌最初設計Borg是為了滿足其自身的內部目的。因此，使用谷歌的搜索引擎本身作為一個例子是非常公平的:在搜索查詢中搜索匹配條目的基本工作是由數百個(也許是數千個)單獨的服務執行的，這些服務共同承擔責任。我想說"數不清"，但這不僅是錯誤的，而且與Kubernetes的整個觀點相反。它確實保留了組成整個網絡中的活動作業(或作業)的所有服務和組件的計數。
Docker和這沒關係嗎？
遺憾的是，對於包含這些分佈式程序的容器來說，目前沒有比"容器"更好的術語了。（有一段時間，我們稱這些東西為"docker容器"以將其與"tupperware容器"區分開來，但今天，docker只包含容器生態系統的一部分；另外，有不止一種格式如果你熟悉一個壓縮文件，它使用數學壓縮將幾個文件混合成一個，那麼你已經對現代軟件容器有了相當的瞭解。實際上，它們使用相同的方法將多個文件壓縮在一起。這些文件僅由可執行元素和程序運行所需的數據組成，無需在網絡中查找其他位置。其中一個元素實際上可能是一個小型的操作系統——一個小型化的Linux版本，通常是微軟的，一個叫做nano服務器的Windows的小兄弟。
為這種容器化部署方法編寫的程序（如搜索查詢響應）可以通過緩存網頁的索引查找尚未選擇的條目，檢查該條目的語義上下文是否與查詢內容匹配，對結果進行排序，並將其註冊到列表中以備日後收集。和檢索。然後程序將終止。這是分佈式服務的一個特點，使其與PC應用程序大不相同：它完成一個請求，然後停止。它知道這是一項更廣泛的工作的一部分，所以一旦它完成了它的功能，它就不再存在。軟件工程師借用現代哲學中的一個概念來描述這一方面：短暫性。與基於圖形用戶界面的應用程序不同，它的大部分週期都在等待用戶的響應，而一個短暫的服務完成了它的功能，然後到期。
在一個集裝箱化的網絡中（再一次，很抱歉，但沒有更好的詞），程序是孤立運行的。即使它們可以共享相同的處理器和內存空間，容器外部的主機操作系統也會保持它們的分離。（理論上，這種聯合依賴是可利用的，儘管在野外尚不存在已知的威脅性利用。）只能通過軟件定義的網絡在容器之間進行通信。一個更復雜的SDN將戰略性地給這些容器提供網絡地址，同時考慮到如何將它們收集在一起以執行一項共同的工作。
協調工作負載意味著什麼
這裡是編排進入畫面的地方。與"容器"不同，"編排"一詞完美地描述了Kubernetes扮演的角色。雖然有些人已經用管絃樂隊指揮來說明這個概念，但無論是在音樂還是分佈式應用中，指揮和管絃樂隊都有很大的區別。編排的動作為單獨的應用程序安排了協同工作的模式，就像樂隊中的樂器一樣。當作曲家產生軟件的原始模式時，包括其旋律線和節奏（裝配軟件容器的術語實際上是合成），編曲者使作品可以聽見。
"這就是為什麼我把Kubernetes稱為'可組合的平臺'，"BrianGracely解釋說，他是RedHat的產品戰略總監，在最近的一次公司網絡研討會上。這裡有一個框架，它應該是什麼樣子的——其中一部分來自於Kubernetes社區，另一部分來自於該社區多年的經驗，以及如何部署應用程序。"
Orchestrator的主要任務是維護其信任的應用程序的操作狀態。在另一個時代，這項工作被委託給操作系統。但當時平臺是一個單處理器，只有一組內存和專用存儲設備。如今，沒有多少東西可以實質性地將集裝箱化服務與更廣泛的應用程序上下文鏈接起來。（這些架構中最複雜的一個，被諸如Netflix這樣的大型雲服務所利用，根本不存在這樣的鏈接。）實際上，正是協調器獲取了所有這些服務的功能和工作產品，通過某種形式的清單對它們進行組織，並提出了一些應用程序的外觀。更改清單，您可能有一個完全不同的應用程序。
Kubernetes與任何其他類型的應用程序沒有任何結構上的獨特之處。它不是虛擬機。它的orchestrator在一個操作系統上運行。在運行時，它維護一個節點集群，這是一種更抽象的方式來引用可能是物理或虛擬的服務器。在每個節點上都有容器的容器。在每個代理中都有一個名為kubelet的客戶端代理，它代表協調器獨立管理函數，用於為其分配的節點。但即使這是一個與其他任何項目一樣的程序。
所以Kubernetes不像Hadoop，它真正改造了服務器中運行的應用程序的結構。儘管如此，這個協調器帶來的分佈式模型與2016年之前流行的模型截然不同。部署模型不會隨著時尚，美食或政治平臺等時代而變化。如果我們說實話，Kubernetes突然崛起並不是因為世界上所有企業突然意識到需要在雲端投入少量應用程序。Kubernetes是Google需要使其全球可訪問的工作負載在數萬個節點上可管理的產物。世界上很少有其他組織類似谷歌，或者擁有谷歌的數據中心檔案。並非每家公司都有自己的搜索引擎 -
分佈式系統的吸引力
那麼，為什麼Kubernetes或容器編排確實對企業有任何吸引力呢？其真正吸引力的原因與工作負載本身關係不大，而且與周圍的開發和部署模型有很大關係：
連續性 - 當應用程序由粒度組件組成時，通過單獨更新和改進這些組件，可以更加輕鬆地發展該應用程序。協調器可以根據這些個別更改如何影響整個工作負載進行適當調整。不再需要對應用程序進行功能改進才能進行大規模的大修 - 這通常會對其可用性產生負面影響。持續集成和持續交付的概念（CI / CD，"D"通常代表"部署"）可以通過一開始就設計的平臺更容易實現自動化，以便在更小，更易於管理的步驟中理解部署本身。
彈性 - Kubernetes維護容器組的活動副本，稱為副本集，用於在任何容器或容器分組（Kubernetes稱為pod）失敗的情況下保持正常運行時間和響應性的明確目的。這意味著數據中心不必複製整個應用程序，並在主要應用程序發生故障時觸發負載均衡器切換到輔助應用程序。實際上，副本集中的多個pod通常在任何一個時間運行，並且協調器的工作是在應用程序的整個生命週期中保持多個。
可擴展性 - 根據預先設定的策略，使用Kubernetes協調分佈式工作負載的組織的巨大回報是工作負載在必要時通過系統倍增的內置功能 - 再次擴展和縮減。為了最大限度地減少混亂的可能性，Kubernetes將相關容器組合在一起作為容器。當確定分配給這些pod的資源沒有儘可能多地使用時，可以將稱為自動縮放器的服務設置為自動將pod複製到不同的節點。
KUBERNETES是平臺還是其他什麼？
對於Kubernetes是否是Microsoft Windows平臺或VMware vSphere是一個平臺的平臺仍然存在一些不確定性 - 這是託管軟件高效運行所需的所有服務和資源的完整提供商。不可否認，Kubernetes是一個"引擎"，是為分佈式軟件系統提供動力的主要元素。然而，Kubernetes本身並不提供這些元素，就像Windows的前任MS-DOS最初沒有提供自己的硬盤優化器或備份程序一樣。
但正如許多用戶所聲稱的那樣，作為有效的引擎，Kubernetes是一個平臺的中心，可以由任意數量的能夠串聯工作的服務組成。有人會說今天的CNCF的目的是維護，編組和培養多個其他獨立的開源項目 - 例如，Prometheus等監控系統，Fluentd（不是拼寫錯誤）等日誌數據管理器，以及可信內容驗證器，例如公證人 - 可以共同構成平臺。在撰寫本文時，CNCF已經認證了59個發行版，其中許多是商業版，其中包括協調器以及其他CNCF工具或其供應商各自的工具。
"你會發現Kubernetes沒有提供所有這些東西，"Red Hat的Gracely說道。"通過不同的供應商，他們是社區的所有領域，通過開源附加項目，為市場提供了很多選擇，給予他們選擇，讓他們可以插入這些不同的元素，並允許公司最終決定，在這個更廣泛的框架內，我如何為我們想做的事情構建最佳平臺，挑選對我們有意義的最佳作品，但仍然可以互操作和支持？"
然而正如Gracely的評論本身所表明的那樣，由於任何這些系列的產品無疑是一個平臺，而Kubernetes是其中心的推動者，因此所有這些結果都應該是"Kubernetes平臺"。紅帽的OpenShift就是一個突出的例子，也是最新的2.0版Rancher。
與分佈式模型相比，預容器化時代應用的一個明確特徵是它們無法被分解，細分或縮放。現代開發人員稱這些應用程序是單片的。在最近的一次，CNCF執行董事Dan Kohn吹捧了稱為"升力換擋"的整體式過渡模型的優點。
他將其定義為"您可以實際使用任何軟件編寫的概念，並且可以將其包裝在容器中。我們已經訓練過將容器視為這些非常精緻的東西，只有最少的庫並且確切地說是運行所需的最小軟件。但是如果你有一個8GB的Java應用程序，你可以用一個容器包裝它。只是容器化它的行為，實際上確實為你創造了一些價值，甚至在你之前把它移到了雲端。
在起跑點擠成一團
討價還價Kohn和其他Kubernetes支持者向企業提出的建議是，基於Kubernetes或與Kubernetes集成的平臺至少能夠支持已有的應用程序 - 儘管是在不同的背景或主題中 - 同時它是值得信賴，迎來這個全新的，看似陌生的建築。
幫助CNCF實現其目標將成為託管應用程序的一系列基於公共雲的平臺，儘管使用容器而不是VM作為業務模型的基礎。 Google Kubernetes Engine（GKE，以前的Google容器引擎），Azure Kubernetes服務（AKS，以前的Azure容器服務），IBM Cloud Kubernetes服務（以前的IBM Bluemix容器服務），Kubernetes的亞馬遜彈性容器服務（EKS），Pivotal Container Service（ PKS，也許你感覺到一個主題是"K"代表"C"字，最近的VMware Kubernetes引擎，所有這些都將突然非常真實的容器即服務（CaaS）概念推進為PaaS的演變形式。所有這些都是Red Hat的OpenShift Online的補充，它早在Kubernetes就開創了CaaS概念。
現在，您可以使用Docker組合容器，並使用任何這些CaaS平臺在自己的Kubernetes集群上託管該容器。在所有這些情況下，容器將VM替換為消耗單位，因此您不再需要在雲端站起來自己的虛擬基礎架構，只需運行應用程序即可。
這是Kubernetes革命將在黑桃中獲得回報的地方。截至目前，在託管應用程序的基礎上提供基於雲的資源的市場非常健康，而不是安裝它們的虛擬化操作系統。它是如此健康，如此突然的市場，VMware除了加入它之外別無選擇。隨著新的，非單一的應用程序在公共雲中產生，培育和成熟，這個市場成功的標誌將是企業多久不再擔心是否或如何實施提升和轉移。
麼是K8s？業務流程如何重新定義數據中心
經過四年多一點的時間，這個誕生於谷歌內部容器管理工作的項目已經顛覆了VMware、微軟、Oracle以及其他所有可能成為數據中心之王的公司的最佳計劃。到底是什麼改變了一切?
Kubernetes是什麼?
對於那些在操作系統是所有軟件所依賴的平臺的時代，建立數據中心的目的和功能的概念的人來說，Kubernetes的目的並不是顯而易見的。Kubernetes是軟件資源的大規模持續重新調整的產物，這些資源共同構成了網絡應用程序。該對齊以稱為工作負載的概念為中心，該概念是由多個處理器中的一個或多個應用程序或一個或多個服務執行的作業的廣義概念。
工作量是一項工作——例如，管理供應鏈、監督物流、跟蹤庫存、促進證券市場。Kubernetes已經成為現代的工作控制系統。
"你可以把Kubernetes看作是一個應用程序模式的平臺，"谷歌軟件工程師Janet Kuo在2017年Kubecon會議上的指導課程中解釋道。這些模式使您的應用程序易於部署、運行和保持運行。"
虛擬機的優點正在衰退
越來越多的數據中心基礎設施致力於關注工作負載的健康狀況，而不是服務器的健康狀況。無論是物理處理器還是虛擬機，服務器都可能出現故障。該故障對這些工作負載的可用性和功能的影響應該小於最小值——它們根本不應該受到影響。
直到2016年，開源社區已經提出了一些方法來編排工作負載以獲得最大可用性。在很短的時間內，Kubernetes成為投資於開源的企業的選擇。原因可以寫一整本書，如果寫得足夠好，它可以被改編成藝術劇院的電影之一，贏得評論家的好評，但從來不會贏得奧斯卡獎。
也許，這是唯一的原因：谷歌推動Linux基金會建立雲計算基金會（CNCF）的早期舉措給了Kubernetes足夠的時間來在最廣泛的人群中有機地培養出一個追隨者。整個開源業務模型圍繞著支持的價值。不再希望被鎖定在單一供應商（誠然，不是所有人）中的企業都欣賞支持系統中新發現的多元主義價值。一組供應商，如果不是總是一致行動，那麼至少是為了同一個目標而進行的一些協調，比一個單獨的供應商在沒有特定方向上領導壟斷平臺要好。
為什麼Kubernetes現在很重要
Kubernetes並不屬於任何一家公司，儘管它基於一個名為Borg的項目，該項目最初是在谷歌內部開發的，而谷歌通常被認為是Kubernetes開發社區的實際領導者。也就是說，微軟已經完全圍繞Kubernetes重新調整了整個服務器系統的理念，並聘請了幾位主要的創造者。作為一個開源項目，Kubernetes由Linux基金會的代理機構——雲原生計算基金會(CNCF)管理。
谷歌最初設計Borg是為了滿足其自身的內部目的。因此，使用谷歌的搜索引擎本身作為一個例子是非常公平的:在搜索查詢中搜索匹配條目的基本工作是由數百個(也許是數千個)單獨的服務執行的，這些服務共同承擔責任。我想說"數不清"，但這不僅是錯誤的，而且與Kubernetes的整個觀點相反。它確實保留了組成整個網絡中的活動作業(或作業)的所有服務和組件的計數。
Docker和這沒關係嗎？
遺憾的是，對於包含這些分佈式程序的容器來說，目前沒有比"容器"更好的術語了。（有一段時間，我們稱這些東西為"docker容器"以將其與"tupperware容器"區分開來，但今天，docker只包含容器生態系統的一部分；另外，有不止一種格式如果你熟悉一個壓縮文件，它使用數學壓縮將幾個文件混合成一個，那麼你已經對現代軟件容器有了相當的瞭解。實際上，它們使用相同的方法將多個文件壓縮在一起。這些文件僅由可執行元素和程序運行所需的數據組成，無需在網絡中查找其他位置。其中一個元素實際上可能是一個小型的操作系統——一個小型化的Linux版本，通常是微軟的，一個叫做nano服務器的Windows的小兄弟。
為這種容器化部署方法編寫的程序（如搜索查詢響應）可以通過緩存網頁的索引查找尚未選擇的條目，檢查該條目的語義上下文是否與查詢內容匹配，對結果進行排序，並將其註冊到列表中以備日後收集。和檢索。然後程序將終止。這是分佈式服務的一個特點，使其與PC應用程序大不相同：它完成一個請求，然後停止。它知道這是一項更廣泛的工作的一部分，所以一旦它完成了它的功能，它就不再存在。軟件工程師借用現代哲學中的一個概念來描述這一方面：短暫性。與基於圖形用戶界面的應用程序不同，它的大部分週期都在等待用戶的響應，而一個短暫的服務完成了它的功能，然後到期。
在一個集裝箱化的網絡中（再一次，很抱歉，但沒有更好的詞），程序是孤立運行的。即使它們可以共享相同的處理器和內存空間，容器外部的主機操作系統也會保持它們的分離。（理論上，這種聯合依賴是可利用的，儘管在野外尚不存在已知的威脅性利用。）只能通過軟件定義的網絡在容器之間進行通信。一個更復雜的SDN將戰略性地給這些容器提供網絡地址，同時考慮到如何將它們收集在一起以執行一項共同的工作。
協調工作負載意味著什麼
這裡是編排進入畫面的地方。與"容器"不同，"編排"一詞完美地描述了Kubernetes扮演的角色。雖然有些人已經用管絃樂隊指揮來說明這個概念，但無論是在音樂還是分佈式應用中，指揮和管絃樂隊都有很大的區別。編排的動作為單獨的應用程序安排了協同工作的模式，就像樂隊中的樂器一樣。當作曲家產生軟件的原始模式時，包括其旋律線和節奏（裝配軟件容器的術語實際上是合成），編曲者使作品可以聽見。
"這就是為什麼我把Kubernetes稱為'可組合的平臺'，"BrianGracely解釋說，他是RedHat的產品戰略總監，在最近的一次公司網絡研討會上。這裡有一個框架，它應該是什麼樣子的——其中一部分來自於Kubernetes社區，另一部分來自於該社區多年的經驗，以及如何部署應用程序。"
Orchestrator的主要任務是維護其信任的應用程序的操作狀態。在另一個時代，這項工作被委託給操作系統。但當時平臺是一個單處理器，只有一組內存和專用存儲設備。如今，沒有多少東西可以實質性地將集裝箱化服務與更廣泛的應用程序上下文鏈接起來。（這些架構中最複雜的一個，被諸如Netflix這樣的大型雲服務所利用，根本不存在這樣的鏈接。）實際上，正是協調器獲取了所有這些服務的功能和工作產品，通過某種形式的清單對它們進行組織，並提出了一些應用程序的外觀。更改清單，您可能有一個完全不同的應用程序。
Kubernetes與任何其他類型的應用程序沒有任何結構上的獨特之處。它不是虛擬機。它的orchestrator在一個操作系統上運行。在運行時，它維護一個節點集群，這是一種更抽象的方式來引用可能是物理或虛擬的服務器。在每個節點上都有容器的容器。在每個代理中都有一個名為kubelet的客戶端代理，它代表協調器獨立管理函數，用於為其分配的節點。但即使這是一個與其他任何項目一樣的程序。
所以Kubernetes不像Hadoop，它真正改造了服務器中運行的應用程序的結構。儘管如此，這個協調器帶來的分佈式模型與2016年之前流行的模型截然不同。部署模型不會隨著時尚，美食或政治平臺等時代而變化。如果我們說實話，Kubernetes突然崛起並不是因為世界上所有企業突然意識到需要在雲端投入少量應用程序。Kubernetes是Google需要使其全球可訪問的工作負載在數萬個節點上可管理的產物。世界上很少有其他組織類似谷歌，或者擁有谷歌的數據中心檔案。並非每家公司都有自己的搜索引擎 -
分佈式系統的吸引力
那麼，為什麼Kubernetes或容器編排確實對企業有任何吸引力呢？其真正吸引力的原因與工作負載本身關係不大，而且與周圍的開發和部署模型有很大關係：
連續性 - 當應用程序由粒度組件組成時，通過單獨更新和改進這些組件，可以更加輕鬆地發展該應用程序。協調器可以根據這些個別更改如何影響整個工作負載進行適當調整。不再需要對應用程序進行功能改進才能進行大規模的大修 - 這通常會對其可用性產生負面影響。持續集成和持續交付的概念（CI / CD，"D"通常代表"部署"）可以通過一開始就設計的平臺更容易實現自動化，以便在更小，更易於管理的步驟中理解部署本身。
彈性 - Kubernetes維護容器組的活動副本，稱為副本集，用於在任何容器或容器分組（Kubernetes稱為pod）失敗的情況下保持正常運行時間和響應性的明確目的。這意味著數據中心不必複製整個應用程序，並在主要應用程序發生故障時觸發負載均衡器切換到輔助應用程序。實際上，副本集中的多個pod通常在任何一個時間運行，並且協調器的工作是在應用程序的整個生命週期中保持多個。
可擴展性 - 根據預先設定的策略，使用Kubernetes協調分佈式工作負載的組織的巨大回報是工作負載在必要時通過系統倍增的內置功能 - 再次擴展和縮減。為了最大限度地減少混亂的可能性，Kubernetes將相關容器組合在一起作為容器。當確定分配給這些pod的資源沒有儘可能多地使用時，可以將稱為自動縮放器的服務設置為自動將pod複製到不同的節點。
KUBERNETES是平臺還是其他什麼？
對於Kubernetes是否是Microsoft Windows平臺或VMware vSphere是一個平臺的平臺仍然存在一些不確定性 - 這是託管軟件高效運行所需的所有服務和資源的完整提供商。不可否認，Kubernetes是一個"引擎"，是為分佈式軟件系統提供動力的主要元素。然而，Kubernetes本身並不提供這些元素，就像Windows的前任MS-DOS最初沒有提供自己的硬盤優化器或備份程序一樣。
但正如許多用戶所聲稱的那樣，作為有效的引擎，Kubernetes是一個平臺的中心，可以由任意數量的能夠串聯工作的服務組成。有人會說今天的CNCF的目的是維護，編組和培養多個其他獨立的開源項目 - 例如，Prometheus等監控系統，Fluentd（不是拼寫錯誤）等日誌數據管理器，以及可信內容驗證器，例如公證人 - 可以共同構成平臺。在撰寫本文時，CNCF已經認證了59個發行版，其中許多是商業版，其中包括協調器以及其他CNCF工具或其供應商各自的工具。
"你會發現Kubernetes沒有提供所有這些東西，"Red Hat的Gracely說道。"通過不同的供應商，他們是社區的所有領域，通過開源附加項目，為市場提供了很多選擇，給予他們選擇，讓他們可以插入這些不同的元素，並允許公司最終決定，在這個更廣泛的框架內，我如何為我們想做的事情構建最佳平臺，挑選對我們有意義的最佳作品，但仍然可以互操作和支持？"
然而正如Gracely的評論本身所表明的那樣，由於任何這些系列的產品無疑是一個平臺，而Kubernetes是其中心的推動者，因此所有這些結果都應該是"Kubernetes平臺"。紅帽的OpenShift就是一個突出的例子，也是最新的2.0版Rancher。
與分佈式模型相比，預容器化時代應用的一個明確特徵是它們無法被分解，細分或縮放。現代開發人員稱這些應用程序是單片的。在最近的一次，CNCF執行董事Dan Kohn吹捧了稱為"升力換擋"的整體式過渡模型的優點。
他將其定義為"您可以實際使用任何軟件編寫的概念，並且可以將其包裝在容器中。我們已經訓練過將容器視為這些非常精緻的東西，只有最少的庫並且確切地說是運行所需的最小軟件。但是如果你有一個8GB的Java應用程序，你可以用一個容器包裝它。只是容器化它的行為，實際上確實為你創造了一些價值，甚至在你之前把它移到了雲端。
在起跑點擠成一團
討價還價Kohn和其他Kubernetes支持者向企業提出的建議是，基於Kubernetes或與Kubernetes集成的平臺至少能夠支持已有的應用程序 - 儘管是在不同的背景或主題中 - 同時它是值得信賴，迎來這個全新的，看似陌生的建築。
幫助CNCF實現其目標將成為託管應用程序的一系列基於公共雲的平臺，儘管使用容器而不是VM作為業務模型的基礎。 Google Kubernetes Engine（GKE，以前的Google容器引擎），Azure Kubernetes服務（AKS，以前的Azure容器服務），IBM Cloud Kubernetes服務（以前的IBM Bluemix容器服務），Kubernetes的亞馬遜彈性容器服務（EKS），Pivotal Container Service（ PKS，也許你感覺到一個主題是"K"代表"C"字，最近的VMware Kubernetes引擎，所有這些都將突然非常真實的容器即服務（CaaS）概念推進為PaaS的演變形式。所有這些都是Red Hat的OpenShift Online的補充，它早在Kubernetes就開創了CaaS概念。
現在，您可以使用Docker組合容器，並使用任何這些CaaS平臺在自己的Kubernetes集群上託管該容器。在所有這些情況下，容器將VM替換為消耗單位，因此您不再需要在雲端站起來自己的虛擬基礎架構，只需運行應用程序即可。
這是Kubernetes革命將在黑桃中獲得回報的地方。截至目前，在託管應用程序的基礎上提供基於雲的資源的市場非常健康，而不是安裝它們的虛擬化操作系統。它是如此健康，如此突然的市場，VMware除了加入它之外別無選擇。隨著新的，非單一的應用程序在公共雲中產生，培育和成熟，這個市場成功的標誌將是企業多久不再擔心是否或如何實施提升和轉移。
翻譯自“www.zdnet.com”
