Kubernetes不會重蹈OpenStack的炒作週期覆轍的七個理由-知識星球

Kubernetes是否存在像OpenStack一樣的炒作週期的危險？沒有，完全沒有！我有七個理由斷定Kubernetes在交付之前不會滑向炒作的深淵。

作為一個產業，我們喜歡玩“紅藍大對抗”的遊戲。我確信建立一個OpenStack vs Kubernetes的搞笑圖片是一個天大的錯誤。 OpenStack是有關基礎設施的，而Kubernetes是關於應用程式交付的。如果它們是應該高度協同的，而不是相互競爭的，那麼為什麼我們要繼續回到“對抗”的敘述呢？

上週KubeCon公佈了有關Kubernetes的相關事件、社群和供應商的爆炸性增長的明確證據——這也是我一直標註為“尖峰時刻”的東西。雖然有一個引人註目的願望，即將這一事件與過去幾年OpenStack的相關事件進行比較，但我認為這是一個欺騙性的對比。它們與開源工作類似，因為這兩個專案都在快速增長，由大廠商推動並充滿希望；然而，它們有著不同的市場動力，因為它們服務於不同的使用者群體。

Kubernetes領導層和管理Kubernetes的雲原生計算基金會（CNCF）正在根據自己的需求以及觀察其它專案比如OpenStack制定不同的戰略選擇。

任何快速發展、超大規模的開源專案都會面臨管理上的挑戰，甚至嚇跑每個參與者。從這個意義上說，相似之處是顯而易見的：隨著出現越來越多的不同利益方，維護貢獻者和保護專案的完整性是很困難的。我曾在OpenStack董事會任職四年（我被投票提名為2018年的職位）；作為幫助引導該專案的活躍領導者，我在這些問題上的立場是有據可查[1]的。

讓我們來探討一下Kubernetes不會重蹈OpenStack歷史的七個相互關聯的理由。

1. 關註應用程式而不是基礎設施

“雲原生Kubernetes”聽起來像一個矛盾，這是一個非常相關的點。所有的CNCF專案都聚焦於應用交付。這意味著他們搞了一個非常不同的“堆疊式”使用者社群。這些使用者能夠利用Amazon Web Services、Google Cloud Engine或Azure等通用基礎設施作為起點，因此在專案啟動時的運維差異極小。這意味著新使用者將專註於如何使用而不是如何安裝。

最終，對於OpenStack來說不可避免的安裝和運維挑戰會造成採用方面的摩擦。我瞭解如何親自將OpenStack基礎設施除錯到正確狀態方面的挑戰（請參閱“Crowbar[2]”）。我們努力建立的可重覆的底層經驗幫助我們通向了Digtal Rebar[3] API驅動的配置技術，這是RackN[4]的核心。任何直接依賴物理基礎設施的東西（最終都是這樣做的）都會為社群構建增加很大的複雜性。

2. 透過程式碼擁抱的API以及早期的一致性

Kubernetes能夠利用OpenStack互操作性工作（請參閱我的DefCore工作[5]）來快速建立經過認證的API標記。雖然這還處於初期，但卻發出了一個明確的市場訊號——供應商期待以可移植的方式遵守API。這有助於建立使用者信心和供應商參與度。反過來，這些舉措為一個活躍的生態系統建立了可訪問的市場，從而吸引更多的使用者。

我也相信Kubernetes更願意透過程式碼擁抱API。在我看來，一個（不幸的是）在OpenStack社群的妥協是要求所有的OpenStack供應商使用相同的程式碼庫。我不認為這兩個專案都有分叉的危險；然而，當需要特定的程式碼時，它會向參與者傳送錯誤的訊息——API是使用者的互動點，而不是程式碼。也就是說，我認為Kubernetes會從透過使用單一的語言——Golang而從中獲益，而不是有多個分發源。

3. Kubernetes是一個生態系統，而不是一個單體應用

Kubernetes中的長者決心保持專案小而專註。他們樂於使用CNCF作為Kubernetes生態圈相關專案的安全閥。典型的設計討論開始是固執己見的（只是Docker和GCE/AWS），然後在樣式和範圍擴充套件的時候提出通用的API。這意味著隨著時間的推移，專案會變得越來越小並解耦。

大型專案都面臨著增加功能範圍的巨大壓力。這就是為什麼OpenStack不斷新增諸如資料庫、負載均衡器、UX和編排系統等“半核心”服務的原因。雖然對許多使用者來說和諧是必不可少的服務，但是如果管理層協調一致的話，他們也會創造一個緊密耦合的單體應用。這些功能雖然關鍵，但它們不是基礎設施API的核心。解耦它們雖然會限制API的融合，但它構建了一個關鍵的生態系統，並使它們能夠更快地進行創新。

4. 沒有大帳篷，而是一個專案的停車場聚會

CNCF鬆散的治理方法可能會讓人困惑，因為圍繞他們如何為會員選擇專案似乎是沒有什麼組織或主題的（收聽我們最近的播客[6]）。他們不需要專案或通用基礎設施之間的協作；但是，這些專案確實有一個共享的架構方法。這種輕量級治理（自我描述為“最小可行治理”）並不會在社群中創造“內外”的思想，因為專案整合在一起的期望很低。相反，它們經常被統一，但並不總是包含在應用程式套件中。

與OpenStack棄用的“大帳篷[7]”實驗相比，這種方法非常有創新性。它們是如何不同的呢？ Kubernetes和其它CNCF專案之間沒有產生混淆。這意味著使用者不會期望專案之間的整合（請參閱開放基礎設施文章[8]）。

5. 豐富的Kubernetes即服務

Kubernetes從早期就開始提供“即服務”產品，而提供商的數量也在迅速增長。服務提供商在這個領域活躍起來有幾個非常積極的好處。首先，它們使使用者更容易採用。其次，他們非常關心程式碼庫的規模和可操作性。第三，也是最關鍵的是，他們推動API保持一致性和可移植性。這些實體為社群提供了“參考”實現，鼓勵他們進行協調，以便他們能夠就增值功能進行競爭。

這些即服務產品也存在一些風險，比如黑箱操作以及隱藏程式碼分叉，這對OpenStack公有雲來說是一個巨大的挑戰，並且這一問題因為私有雲供應商的慷慨解囊而變得更加複雜。由於aaS供應商出現速度較慢且難以標準化，因此OpenStack使用者發現自己處於定製安裝狀態，而不是構建可移植的基礎設施，不過這種趨勢正在緩慢扭轉。

6. 強有力的管理

Kubernetes受益於Google的強大管理。在專案關鍵的構建階段，Google的頂尖人才、設計驗證和財務投資推動了Kubernetes的進展。 Google不直接與RedHat、CoreOS、IBM或三星等公司競爭的實際情況也使得他們可以安全地加入，更重要的是認可這個專案。單一供應商的影響力太大是一個風險，然而，Google也發出了正確的訊號，即讓其關鍵領導人退出。

雖然OpenStack由Rackspace和NASA發起，但管理程度受一開始設計的諸多限制。作為戴爾的一員，我加入了這個團隊，迅速將社群推向了多供應商領域。當協作環境允許時，這使得專案在關鍵的孵化階段發展壯大。不過回想起來，我希望我們更專註於技術。

7. 競爭對手

最後，Kubernetes可以從相對於其它容器排程系統較晚的釋出時間中受益， Docker、Mesos、Rancher、Apcera、Cloud Foundry和其它幾個（有誰還記得StackEngine ？！）最初有更完整的產品線。我記得當Docker Swarm（v0.12版本）透過與Docker Engine整合釋出引起業界轟動時，Kubernetes只被視為一個只有不溫不火的商業支援的弱者（直到Red Hat釋出OpenShift）。這個穩健的市場策略使專案在沒有太多聚光燈（標的？）的情況下成熟起來。

相比之下，OpenStack似乎已經完全成型，並且具有比預期更大的風險投資營銷預算。確實存在合理的公開的競爭對手（CloudStack、Eucalyptus和OpenNebula），但圍繞該專案的廠商炒作也積極地定位了OpenStack（是的，我在這裡很有罪過）。這毀掉了技術路線和良好願望。現在Kubernetes似乎已經贏得了這場容器排程的戰爭，蜜月已經結束了。

最後

沒有一個正確的方法來管理一個開源專案（鳴謝安娜·卡列尼娜[9]）。我們所能希望的最好方式就是我們所做的好的選擇勝過那些糟糕的。雖然這篇文章重點聚焦於OpenStack的挑戰，但是我們也做出了很多很好的選擇，對於新的開放基礎設施方向我感到樂觀。 Kubernetes正在根據這些選擇和自己的需求編織自己的路徑。迄今為止，我支援這些選擇。我希望我上面的這七點理由能夠幫助你更深入地思考這條路線——我想聽聽你們的關於對我所做的正確的事以及我錯過了什麼的一些看法。

相關連結：

http://robhirschfeld.com/
https://robhirschfeld.com/crowbar/
http://rebar.digital/
http://rackn.com/
https://robhirschfeld.com/tag/defcore/
https://www.rackn.com/2017/11/20/podcast-peter-miron-talking-nats-service-edge-cloud-native-foundation/
https://robhirschfeld.com/2014/11/21/big-tent/
https://www.rackn.com/2017/11/14/sirens-open-infrastructure-beacons-openstack-community/
https://en.wikipedia.org/wiki/Anna_Karenina

原文連結：https://thenewstack.io/7-ways-kubenetes-avoids-openstack-like-hype-cycle/

基於Kubernetes的容器雲平臺實踐培訓

本次培訓包含：Kubernetes核心概念；Kubernetes叢集的安裝配置、運維管理、架構規劃；Kubernetes元件、監控、網路；針對於Kubernetes API介面的二次開發；DevOps基本理念；Docker的企業級應用與運維等，點選識別下方二維碼加微信好友瞭解具體培訓內容。

點選閱讀原文連結即可報名。

Kubernetes不會重蹈OpenStack的炒作週期覆轍的七個理由

相關推薦

熱門標籤

熱門文章

分享創造快樂