KubeCon大會：商業化加速推動Kubernetes開源項目日趨成熟

至頂網報道

來源：siliconANGLE

本周，年度KubeCon + CloudNativeCon North America 2018大會在西雅圖舉行，這次活動將讓雲計算產業有機會評估一下Kubernetes到底發展到什麼程度了，此外也探討了可能阻礙Kubernetes平台發揮全部潛力的各種問題。

整個2018年Kubernetes都是科技領域一個熱點話題，看起來這項技術似乎將在未來幾年繼續保持無處不在的發展勢頭。如今Kubernetes生態系統已經非常有活力，不過這是一把雙刃劍。

提供商們對Kubernetes的商業化採用是今年雲計算領域的一個主流旋律，這是因為現在企業可以更輕鬆地部署容器，Kubernetes實現了應用編寫一次就能部署在很多計算環境中（從本地數據中心到公有雲）。Kubernetes成熟的一個明顯標誌是，圍繞Kubernetes成長起來的開源項目構成了一個豐富的生態系統，這其中包括監控項目（Prometheus）、服務代理（Envoy）、遠程過程調用（gRPC）、容器網路介面（CNI）、基於DNS的服務發現（CoreDNS）、打包環境（Helm）等等。

Kubernetes主導地位日益增長的的另一個跡象是迅速擴大的企業採用率。Cloud Native Computing Foundation最近發布兩年一次的企業用戶調查報告顯示，自2017年12月以來，使用雲原生技術的企業已經增長了200%多。Kubernetes是容器管理的首選，83％的企業表示他們在私有雲、公有雲、混合雲或者多雲部署中採用Kubernetes，有大約40％的企業表示他們現在生產中採用Kubernetes。

對雲計算廠商來說，Kubernetes是一個重要的競爭焦點。所有領先的公有雲廠商都對這項開源技術進行了大量投資。AWS、微軟、谷歌、IBM、Oracle和阿里巴巴都有他們各自的Kubernetes引擎，此外還有Red Hat、思科、VMware等等。

Kubernetes生態系統的擴散困擾著市場

然而，那些採用Kubernetes的企業現在正在走進開源項目的雷區，這些開源項目並沒有積累成為一個成熟的、廠商無關的堆棧，能夠應對各種雲計算的各種生產級企業應用用途。

Kubernetes生態系統有多令人困惑？核心的Kubernetes開源平台已經演變成為數十個廠商調整過的發行版和託管雲實施，令人眼花繚亂。不僅如此，有一系列開源項目構建並補充了Google的Kubernetes，這就更加令人困惑了。

有許多（但並不是全部）開源容器化相關的項目都屬於Cloud Native Computing Foundation，只有少數不是Kubernetes的項目。最值得注意的是， 用於監控的Prometheus，用於代理的Envoy，都已經「逐漸」走向標準化。

但是我們還沒有看到不同子項目之間取得突破性成功。因此，採用基於Kubernetes解決方案的企業面臨著可能需要在市場崩潰時的一兩年內進行「重新構建」式的遷移活動所帶來的風險，我們都知道很多有前景的開源項目都已經從人們視野中逐漸消失了。

Oracle最近在積極「規劃」一套核心的CNCF項目，這一點值得稱道。但考慮到這只是一家廠商，這對於帶來跨行業的一致性不會帶來太大影響——如果雲原生計算要成熟到成為任何容器化微服務的支撐，就必須要有這種一致性。而且，這無法確保攻擊面的安全，攻擊面在龐大異構多廠商、聯合和碎片化的Kubernetes發行版、版本和工具中正在不斷擴大。

Kubernetes正在成熟的開源核心

然而，Kubernetes開源平台顯示出成熟的跡象。根據source最近的一項源代碼分析，目前版本為1.13的Kubernetes核心代碼庫正在趨於穩定。

2018年Kubernetes核心項目的貢獻總數正在放緩。隨著時間的推移，CNCF管理下的Kubernetes核心代碼庫穩定在大約175萬行代碼，而其公共應用編程介面端點大約穩定在1.6萬。同時，對於Kubernetes特殊興趣群組和CNCF內孵化器項目的貢獻也呈現放緩趨勢。

但這並不意味著Kubernetes生態系統的創新正在萎縮。source的研究還表明，更多創新來自於與Kubernetes相關的項目，這些項目在CNCF範圍之外由GitHub組織進行管理。這個規模更大的Kubernetes生態系統最近大部分活動都會涉及到開發集群聯合、容器運行時、支持高性能計算和機器學習的可擴展工作負載管理、以及彈性負載平衡。

在商業化方面，很顯然廠商們並沒有放緩在核心Kubernetes生態系統項目中構建他們自己的雲計算環境的步伐。與此同時，很多最活躍的雲計算解決方案提供商都在擴展他們自己的開源新項目，以滿足CNCF社區項目核心範圍之外的需求。

例如，AWS最近發布的Firecracker，是一個使用基於Linux內核的虛擬機或KVM的輕量級開源虛擬機監控工具。Firecracker可以在無伺服器雲中創建和管理安全的多租戶容器和Lambda功能。它能夠實現主流容器的運行時，以管理像microVM這樣的容器。通過這種方式，它讓開發者可以利用虛擬機的工作負載隔離，同時獲得在Kubernetes背板上運行容器的效率。

Firecracker是在Apache v2.0下提供許可的，可從GitHub存儲庫下載，旨在優化無伺服器環境中的瞬態和無狀態工作負載。AWS Lambda使用Firecracker作為配置和運行沙箱的基礎，公有雲提供商在該沙箱上執行客戶代碼。

Firecracker提供了一種安全設備模型，可以減少內存佔用和攻擊面，同時在每台伺服器上提供高密度的microVM。最小的設備型號可以縮短啟動時間（在默認microVM大小的i3.metal上小於125毫秒），同時減少攻擊面。Firecracker可以將數千個microVM打包到一台機器上。用戶可以訪問其進程內速率限制器，以精細的粒度控制網路和存儲資源的共享方式，甚至可以跨數千個microVM進行控制。

研究公司Wikibon發現，Firecracker最值得關注的是AWS將Kubernetes容器化與無伺服器及虛擬化範例協調一致的方式。這並不是CNCF Kubernetes核心項目的主要關注點，但這對於那些已經投資了所有這些技術的企業來說，是一項越來越明顯的要求。

CNCF能否讓Kubernetes與其他社區協調一致？

Kubernetes核心社區之外的持續創新對於生態系統的成熟發展來說至關重要。最近，谷歌研究員Eric Brewer認為，谷歌（仍然是Kubernetes社區最主要的貢獻者）可能過早地開源了Kubernetes，而給社區留下太多需要解決的問題。

但是，Brewer的觀點並沒有點到根本問題。如果在開源之前，谷歌在開發和證明Kubernetes核心堆棧的時候就已經參與到社區中的話就會好很多。有理由讓一個有遠見的廠商在發布到開源社區之前打造一個一致的——儘管是複雜的——解決方案堆棧。

也許是已經吸取了這一教訓，谷歌正在全力以赴地構建另一個核心開源堆棧TensorFlow，它具有強大的功能層、工具和介面、同樣重要的是——廣泛的社區參與。

也許谷歌會在某個時候將開源TensorFlow堆棧提交給類似CNCF這樣的組織，正式開發和治理TensorFlow，並使其與Kubernetes生態系統保持一致。在兩到三年的時間內，Kubernetes和TensorFlow生態系統將會融合，因為AI DevOps的容器化正在加速，解決這些要求的、仍在萌芽狀態的開源項目——例如Kubeflow——將成為Kubernetes無所不在的雲世界中所有AI應用開發的核心。

谷歌應該將TensorFlow提交給CNCF嗎？現在我們還不清楚目前的CNCF是否能夠給TensorFlow帶來所需的一致性，讓這個開源堆棧不會偏離核心用途，同時確保TensorFlow工作組與Kubernetes工作組有適當的接觸，確保進行必要的調整。

-END-

至頂網

一個談新技術和新商業模式的信息服務平台，致力於記錄和推動數字化創新，服務CIO、CTO等技術和商業的決策者、從業者。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！