歡迎光臨
每天分享高質量文章
當前位置：知識星球 > 後端 > 正文

Kubernetes生態圈繁榮背後的利與弊

2019-01-15 分類：後端 閱讀(385) 評論(0)

 

如果你們公司已經準備全面使用Kubernetes編排管理器，而你為了方便部署正在找尋一個包管理工具，那麼你可能會傾向於選擇Helm，一個正在雲原生計算基金會（CNCF）孵化的開源專案。
你有可能還希望從推廣容器的公司瞭解Docker Compose，或者Draft——一個微軟專案，由開發Helm的同一幫人開發，或者還可能是Open Service Broker API，Habitat，或其他17種不同的開源包管理器。CNCF在其Landscape[1]網頁上列舉了所有這些內容，包括272個其他的雲原生開源專案。同時，這份清單每週都會追加更新。
有人會把這種過多的選擇稱為chaos（混亂），也有人稱之為新一波創新。不管怎麼說，圍繞Kubernetes發展而成的生態系統已經展示了其優勢但也帶來了混亂。對於那些已經準備將寶壓在Kubernetes上的公司，如何在眾多的可用擴充套件和應用程式介面之間做出一個明智的選擇，正成為它們面臨的最大挑戰之一。
IBM雲平臺全球副總裁兼技術長Jason McGee說：“這個圈子的活動多到令人驚訝，但我並不羨慕普通企業試圖去收集所有這些東西。”Jason McGee在西雅圖舉行的KubeCon會議上發表主題演講，共有8,000名技術愛好者聚集在一起，學習虛擬化技術之後最熱門的和資料中心相關的技術。
Kubernetes是一個雲原生平臺，它正在顛覆應用程式的開發方式。該軟體由谷歌（Google LLC）建立並且於四年前釋出為開源軟體。它迅速成為部署和管理大量容器類軟體的主流平臺，這些軟體是自包含的，即包含了應用程式需要跨環境執行時的所有程式碼和依賴包。
幾乎所有的計算機和雲基礎設施公司都以原生形式採用了Kubernetes，這是前所未有的壯舉。這其中的一個重要的因素是，一個單獨的可參照的平臺催生了一個龐大的開發者社群。他們正在擴充套件Kubernetes在監控，日誌，安全及儲存等領域的核心能力。
CNCF的Landscape對雲開發者而言就像一個應用商店。“擁有強大的第三方生態系統是彭博資訊選擇將其大部分開發業務轉移到Kubernetes的重要原因之一。”財經新聞和分析公司的資料分析和基礎架構負責人Steven Bower表示，“並非所有應用都要在Kubernetes中，你可以使用容器網路介面（CNI）混搭和整合不同專案的不同元件。”他指的是Kubernetes的原生規範中利用網路外掛為容器服務。
“Kubernetes的生態系統異常強大，因為市場意識到Kubernetes的威力。”Codefresh公司專門銷售針對Kubernetes的持續交付平臺，其首席佈道者Dan Garfield表示，“要來一個雲上通用的API嗎？好極了。”

 

狂野西部風

但有些專家警告說，現在的生態系統有點像一個狂野的西部片，許多專案都在爭取成為焦點，但幾乎沒有明確的領導者，組織一旦做出錯誤的選擇可能會導致在未來幾年內都將陷入耗時的遷移過程。
“現在採用Kubernetes的企業正行走在開源專案演進的雷區。” SiliconANGLE姐妹市場研究公司Wikibon的首席分析師James Kobielus說，“他們總體上仍然沒有達到一個成熟的，與供應商無關的產品棧，可以解決各種生產級的企業應用案例。”
生態系統迅猛發展的其中一個原因是，Kubernetes的所有權從Google轉移到了社群手中。谷歌領導者從經驗中得知，如果試圖控制該專案將會阻止競爭對手做出貢獻而阻礙該平臺的發展。他們希望避免出現分裂，因為分裂已經給其他開源專案造成了破壞。舉個例子：OpenStack，一個IaaS（基礎設施即服務）平臺，據說該陣營內成員之間的內鬥和眾多的衍生版本導致其未能兌現承諾。
“為了贏得更廣闊的世界，我們必須學會放手並且相信我們留下的任何空白都乾乾凈凈，以便他人盡情發揮。”谷歌的高階軟體工程師兼Kubernetes的主要開發人員之一Tim Hockin說，“流於形式的錶面工作必須有限度，生態系統一定要茁壯發展。”
“如果谷歌僅僅只開源了Kubernetes，”Gartner公司的研究主管Gregg Siegfried表示，“它無法擁有今天的影響力。”
尋道Linux之路

 

因此誕生了CNCF。2014年，當谷歌準備將Kubernetes開源時，它選擇繞過Apache基金會，該基金會已經在培育一個名為Mesos的競爭性專案，而與Linux基金會合作建立CNCF作為一個新的管理機構管理雲原生軟體。Linux基金會在支援單個Linux核心方面的記錄是Google希望在Kubernetes上看到的發展樣式。
開源管理機構一直在和經常產生利益衝突的貢獻者們作鬥爭，特別是那些銷售相關產品和服務的貢獻者們。“在創新與穩定之間繃著一根弦，”福瑞斯特諮詢公司副總裁兼首席分析師Dave Bartoletti表示，“這些公司必須實現貨幣化，而為了貨幣化一些事物，它必須是穩定的。”
Kubernetes的開發人員希望穩定核心部分並促進生態系統的創新。CNCF的任務是圍繞一個Kubernetes程式碼庫將整個行業的競爭對手聚集到一起。它借鑒Linux playbook，制定了一個Kubernetes認證一致性計劃，以審核Kubernetes發行版之間的連續性。
到目前為止，90個包和託管版的Kubernetes發行版[2]已獲得認證，確保不會出現所謂“分支”的差異。CNCF還要求成員將他們建立的任何補丁都提交給社群以便參考，從而降低無意中出現分支的風險。
之後，CNCF打破了它自有的方式，接受和培育起開源專案的生態系統。開源基金會的職責之一就是挑選競爭的獲勝者，透過指派特定的專案接受服務，包括專案管理、支援、檔案推廣及其他資源，用來幫助那些專案取得成果。這些專案被稱為“孵化”，成熟以後就會“畢業”。
CNCF的創始人認為Apache的政策太過嚴苛並且過於關註開發人員。他們想要一種更具包容性的方法。Patrick O’Reilly表示 “我們希望拋開Apache專案的所有政策和流程，重新開始。”他是CNCF的創始人之一，現在是Get Cloud Native公司的執行長，Get Cloud Native公司專註於幫助企業遷移到雲平臺。
該基金會降低了專案轉變成孵化類專案的門檻，並將大部分決策權下放給了專案所有者。O’Reilly說：“CNCF能讓那些通常不愛說話的人說話。我不是說這是最好的方法，但它是我們現在擁有的最好的方法。”
現在，CNCF的技術監督委員會是決定孵化新專案的唯一仲裁者。它與理事會分開，理事會的成員包括供應商和其他商業利益相關方。該基金會還要求每一個專案都有一個中立的治理流程，用來最大程度的減少來自行業的壓力。
Gartner的Siegfried說：“Apache社群的流程稍顯笨拙，並且不允許快速演進和多樣化的視角。而CNCF則培養和鼓勵管理社群流程。”
事實上，有些人認為CNCF是未來如何處理開源專案的典範。“本質上，它正在為微服務這一新世界，重新打造應用程式開發平臺。”Wikibon的Kobielus說道，“這是計算機歷史上史無前例的一項雄心勃勃的計劃。”
但是，較少規則帶來的缺點是充滿不確定性。對於平衡創新和穩定性方面，CNCF的方法是否一定優於其他方法，這點仍然有待商榷。到目前為止，除Kubernetes之外，只有兩個專案已經畢業：一個是Envoy，一個簡化網路服務的代理伺服器。另一個是Prometheus，一個監控平臺。
所以它仍處於早期階段，專案需要數年才能孵化。目前，“Kubernetes生態系統已成為眾多供應商角逐發行版和託管雲版的一個混亂領域。”Kobielus說，“而以谷歌開發的Kubernetes為中心，不斷增加的開源專案，更是亂上加亂。”

 

從無序到有序

 

出現各種選項百花齊放的局面，這裡有一些刻意的因素。谷歌向社群釋出Kubernetes的標的之一是隨著時間的推移，將更多的功能轉移到擴充套件中，削減核心程式碼庫。Kubernetes本身已經“與我們釋出它時完全不同。”Hocking說，“我們希望把更多的功能從核心中剔除。”
CNCF的技術長Chris Aniszczyk表示，該基金會正在努力堅守這一原則。他在本週接受採訪時表示，“Kubernetes一直專註於將功能從核心中剔除，以盡可能地實現其擴充套件性。”
但對於那些想要追隨Kubernetes的組織而言，選擇的多樣性可能會帶來一些問題。尤其是那些大型企業，這點更加令人擔憂，“他們需要一個可以遵循的合法合規的要求或者內部的標準。” DivvyCloud公司執行長Brian Johnson表示，“大多數生態系統中的專案，在這方面還沒有明確的技術控制或最佳實踐的流程。”DivvyCloud公司是一家提供政策驅動的雲安全和合規公司。
挑選勝出的專案可以使組織更好地利用社群的研發能力，因為成功的專案意味著下一輪創新。“開源世界中有一股吸收所有的能量的動力。”IBM的McGee說。“你會想要與之合作。”
隨著一些孵化類專案的畢業和其他一些專案的淘汰，Kubernetes生態系統不再是“你要自己用一籃子工具打造屬於你的東西。”齊格弗裡德說，“它將提供一個完整的整合。”
有證據表明Kubernetes生態系統正在進行整合。本週基於一項對GitHub倉庫的分析，Sourced Technologies S.L.表示“Kubernetes專案核心部分的提交速度似乎有所放緩。”
“我已經看到正在發生的第一輪整合。”IBM的McGee說，“但我們仍處於如何整合各部分的生態系統建立階段。”
經歷這類週期也不是什麼新鮮事。在業界選擇使用Linux之前，曾經有超過20個版本的Unix。Hadoop大資料生態系統在早期也異常複雜，直到軟體供應商和雲端計算公司介入後，簡化了部署和整合過程。Johnson說：“最有可能的結果是將會有5到10個主流Kubernetes框架，早期試用這些框架的企業將測試和驗證這些框架。”
在很大程度上，採用Kubernetes的速度加快了其成熟的過程。O’Reilly說：“一旦你讓銀行進入，人們不再希望發生重大變化。”

 

IT的選擇

 

那麼資訊科技經理該如何在此期間做出決策呢？Forrester的Bartoletti認為，對大多數公司而言，這都不是問題。
“企業首先要清楚他們是平臺的構建者，平臺的運營者還是平臺的消費者。”他說，“這個選擇決定了你該如何分配資源。”
Bartoletti將平臺的構建者定義為業務主要依賴於在Kubernetes平臺上建立應用程式的公司。對他們而言，在生態系統方面做出正確的選擇至關重要。平臺的運營者更願意託管他們自己的Kubernetes實體，且不認為該平臺具有戰略意義。平臺的消費者只想要一個可用的平臺，不會特別關心它的出處。
“如果要建一個旅行預訂系統，那麼根據所建平臺的差異性進行取捨，這點尤為重要。”Bartoletti說，“但一般的企業可能不需要加入所有社群。”
平臺的運營者可透過與那些在生態系統活躍度很高的商業Kubernetes供應商合作（例如IBM，Red Hat公司或Pivotal軟體公司），以防止在選型時陷入困境。“如果Pivotal為您提供了很好的服務，那麼就沒有理由改變。”他說，“因為Pivotal的工作就是保證它們正常工作。”
對於平臺的消費者來說，最好選一家主流的公有雲提供商，可提供全面可控的服務並負責保持客戶當前的狀態。
專家認為，雖然目前的生態系統讓人眼花繚亂，但平臺的消費者也不能只充當旁觀者。開源專案的優點之一是它們基於標準工具集，可以適應Landscape的變化。例如，Docker公司最初選擇自己的Swarm編排工具而不是Kubernetes，但這並沒有阻止它之後與Kubernetes整合，而Swarm仍然是一個可選項。
負責任的開源供應商不會做出死板的決定。“有可能[亞馬遜網路服務公司]將來會從Lambda轉移到另一個Serverless平臺，但人們會後悔使用Lambda嗎？”Bartoletti說，“我的客戶們都不會後悔。”
基於這一事實，IT經理們應該可以減少些對他們所做決定的擔憂：在開源的世界裡，即使選錯了也能得到令人滿意的結果。
相關連結：

  1. https://landscape.cncf.io/cncf=hosted,graduated,incubating,sandbox,member,no&license;=open-source

  2. https://www.cncf.io/certification/software-conformance/#logos

原文連結：https://siliconangle.com/2018/12/13/kubernetes-sprawling-ecosystem-offers-plenty-choice-risk/

贊(0)
標籤：

相關推薦

熱門標籤

iOS (11238)微軟 (4955)Linux (4274)安全 (4180)Python (4161)效能 (3165)運維 (2774)最佳化 (2419).NET (2262)Google (2136)機器學習 (1795)併發 (1613)分散式 (1559)叢集 (1240)SQL (1174)Mysql (1060)區塊鏈 (1017)Docker (977)微服務 (922)面試 (919)Apache (743)NLP (725)Redis (719)Android (668)Git (640)架構師 (632)Nginx (630)Facebook (599)JVM (595)爬蟲 (476)

熱門文章

分享創造快樂