Docker Swarm和Kubernetes在大規模集群中的性能比較

Contents

這篇文章主要針對Docker Swarm和Kubernetes在大規模部署的條件下的3個問題展開討論。在大規模部署下，它們的性能如何？它們是否可以被批量操作？需要采取何種措施來支持他們的大規模部署和運維？

• 我們需要使用側重於用例的基准測試來對所有容器平台進行比較，這樣采用者才可以做出正確的決策。
• 筆者從用戶的角度建立了一套測評工具，用普通的方法測試Docker Swarm和Kubernetes。我只評估了通用的功能：容器的啟動時間和容器羅列時間。
• Swarm的性能比Kubernetes好。
• Kubernetes和Swarm都在1000個節點的集群上執行同樣的工作。
• 無論從架構還是功能的角度來看，Kubernetes都是一個更加成熟且復雜的系統，因此它就需要更多的精力去部署和運維。
• 以下所分析和呈現的數據可以幫助用戶基於自身的需求來選擇一個合適的平台。

序文

我很高興地向大家透露，這篇文章是被資助的獨立研究與開發的成果。Docker公司不僅貢獻了工程師們的寶貴時間，並且購買AWS的服務來支持該工作的不斷迭代和測試。發布全部的相關內容用於檢測，重復利用以及第三方測試是我們的共同目標。如果你或者你的組織對資助其他的創新研究感興趣，請通過http://allingeek.com聯系我。

我在這次研究的過程中學習到很多知識，不僅局限於測評的結果和集群架構。如果你想要隨時參與討論，請在Twitter上關注我或閱讀我的博客，因為這些內容細節將隨着時間流逝被我漸漸淡忘。

這個項目帶來一個黑暗的現實那就是——雲不是無限的——當我用光us-west-2a上所有m3.medium的容量時，集群放置位置成為了我的關注焦點。Oops！正在回滾……

現實中Swarm和Kubernetes在大規模集群中的性能表現怎么樣？

我承認，當我最初提出這個問題時並不知道怎么回答。我讀過一些文章，比如Kubernetes Performance Measurements and Roadmap和Scale Testing Swarm to 30,000 Containers等。但是這些文章都存在一個問題：我們很難理解作者真正要測什么，以及測試環境是怎么樣的。更加讓人痛苦的是，沒有提供清晰的步驟或工具讓測試重現。每個呈現出來的數據會變得沒有意義，因為讀者已經迷失在上下文中。我認為，對於讀者來說，這些數據比起沒有被證明的表述反而更加危險。因為讀者會更願意去相信你的數字，即使它們很難理解。

現有的研究和文獻的另一個問題是，很少有文章在測量相同的東西。這樣就很難來比較結果報告。我們需要一個通用或完整的功能測試基准，讓這類的工具可以測試每個平台（不僅僅是Swarm和Kubernetes），這樣就可以幫助到DevOps社區，就如同QuirksMode.org幫助網頁開發者一樣。

這個項目面臨的挑戰是建立一個通用的框架來評估在一個現實部署環境中的通用功能，同時幫助讀者記錄流程。畢竟我需要讓每個普通讀者可以拿到結果信息。而在真正的執行前，建立一個通用的命名方式是很重要的，例如Docker是采用Container技術，一個“pod”是Kubernetes中的最小部署單元，一個pod由至少一個Container組成。我們所描述的工作都是使用單容器的pod，所以接下來的這篇文章中，我會使用Container來替代pod。文章中接下來的內容，我將引用Kubernetes的作業（job）。一個作業是一個Kubernetes的控制面板所管理的單元，是用戶希望完成的任務。一個作業通過一個pod執行，在這里也是一個Container。

選擇用於測量的操作

Swarm和Kubernetes提供了不同的API和功能的抽象。 Swarm是Docker的一個子項目，它的作用在集群級別下就如同Docker在一台單獨的機器中起到的功能。你可以使用Swarm來管理單個容器或者列出集群中所有運行的容器。而Kubernetes擁有並行啟動，自動擴容，有差別的批處理和服務生命周期，負載均衡等特性。因此，經過全面的評價后，我將”容器啟動延遲”和”容器羅列時間”作為兩個最佳的候選操作。

最小化容器的啟動時間對於延遲敏感的程序而言非常重要。舉個例子，類似於AWS lambda的即時編譯（Just-in-time）容器服務會在收到一個依賴於它特定功能的請求之后，才真正地啟動一個容器。 而即時編譯容器在物聯網（IoT）領域也有其實際的應用。另外，作業或者批處理軟件本質而言就是“按需的”。而無狀態的微服務和固化的部署單元也是被廣泛提倡和采用的。我堅信當上述提到的趨勢進一步的趨向於作為即時編譯服務存在時，響應式部署基礎架構的盛行會是一種自然地演化結果。而對於這種類型的系統而言，低延遲是一個必要的需求。

對於“容器羅列時間”所需的低延遲而言，並沒有相關的用例支持。但從目前所積累的相當經驗來看，在一個集群上羅列容器命令的延遲與否會和運維人員的效率有密切的聯系。如果羅列容器操作相當慢，那么運維人員可以考慮建立用於更新本地容器列表緩存的一個后台執行任務，基於此我們可以提供比直接執行羅列容器操作更加好的性能來提升效率。

開發測試工具套件

Kubernetes和Swarm都提供了同步API調用來獲取容器列表。 這意味着他們的命令行客戶端同時會被阻塞，直至收到整個列表信息以后才會退出。所以可以方便的使用time命令來測試兩者羅列容器所需要的時間。 Swarm另外提供了同步的接口來創建容器，因此我可以使用同樣的測試模式（基於time命令）來測定啟動的延遲。不過，Kubernetes使用異步的方式來完成同樣的功能（創建一個容器），換句話說，客戶端會在容器真正啟動之前就已經退出。 所以，對於Kubernetes啟動時間的測定需要使用不同的方法。

使用羅列容器的接口來獲取完整的信息，或者使用“運行時間”來確定一個容器啟動所需要的時間是十分有吸引力的方案。這個策略依賴於獲取信息操作本身有足夠合理的精度。但結果將顯示，羅列容器的延遲非常巨大，以至於使用精度在十到百毫秒的測定命令來確定時間不是十分合理。 使用這樣的測試方法會引入太多的錯誤。

因此，使用等同和通用的測試方法來做測定是一個更好的方案。在上述討論案例中，兩個平台都會最終啟動一個容器。當它收到新容器的信息時，超時的進程將會退出。

按照上述方法測定啟動延遲會引入一定的額外開銷，但是額外開銷對於所有的平台而言都是均衡的，因此也就不影響比較的結果。

測試環境

我在AWS上使用1000個節點的集群測試了Kubernetes和Swarm。這是AWS平台上比較受歡迎的測試方法。節點運行在m3.medium的實例（1 vCPU，3.75 GB）上。基礎設施機器使用m3.xlarge的實例（4 vCPU，15GB）。鍵值數據庫運行在c4.xlarge 的實例（4 vCPU，7.5 GB）上。Kubernetes的API層采用6個冗余備份。測試運行在同一個VPC中的一台單機（t2.micro）上。

我基於以上配置選擇了這些實例種類用於其它研究，並且在早期的迭代中觀察性能。通用組件的性能特征：測試節點，worker節點和etcd都是一樣的。每個集群節點所提供的資源不會影響到這些測試的性能，除非這些資源不支持平台組件。你可以根據你自己大致的資源要求，規模大小和成本要求來決定自己部署的實例類型，集群大小。在這個測試中，軟件沒有太強需求。

用預加載到機器中的一些休眠程序來填充每個節點。使用者一般會采用預加載鏡像這個通用的策略用來減少不穩定性和啟動延遲。Kubernetes節點用“gcr.io/google_containers/pause:go”鏡像，而Swarm使用Dokcer Hub上的“alpine:latest”鏡像中的休眠命令。被測試的容器都是通過“alpine:latest”鏡像創建的，並且都只執行nc命令。

所有集群都根據大規模部署最佳實踐和領域專家的指導意見進行配置。這些配置與一個產品環境有着如下不同之處：

1. 不采用multi-host網絡部署
2. 不采用高可用的鍵值數據庫配置
3. 不采用安全TLS通信，並且對網絡配置並不進行安全加固。
4. Kubernetes並不啟用身份認證和授權的功能

我測試的軟件版本是Kubernetes v1.2.0-alpha.7和Dokcer Swarm v1.1.3-rc2（是從dockerswarm/swarm:master拉取的）。兩個集群的鍵值數據庫都采用etcd v2.2.1。

此次測評的目的是給預測級別的性能概率建立一些統計置信度。要完成該任務需要多次測量（或采樣）相同的操作。每個目標級別，相同集合的性能分布可以幫助我們理解“下一次”操作的性能概率。大采樣量可以提高精度，並且降低噪聲或異常樣本帶來的的影響。

這個測評程序集群使用率分別為10%、50%、90%、99%和100%，每個目標使用級別收集1000*的樣本。在這個環境下，當一個節點運行30台容器時就會滿了。所以，當一個1000節點的集群有30000台運行的容器時，這個集群也滿了。測量時每次就采集一個樣本，所以在測試盒或API服務上並不會產生任何的資源競爭。

在對Kubernetes測評時，會使某些級別的一系列操作樣本數量降低到100個。隨后，測評程序上的每個操作都會消耗超過100多秒。最終，1000個樣本將會消耗大約28小時來完成每個目標級別的操作。

測試結果

由於統計結果的數據經常被曲解，所以下列顯示的圖表和周圍的注釋我們會盡量保持簡潔，確保不會給讀者帶來困惑。此外，在闡述相關數據的時候，我永遠不會跟你說“相信我吧”。我得到的所有數據都在GitHub上。你可以用來做你自己的分析。

下面4個圖表所提供的數據，可以幫助我們來回答一個問題：“當我的集群資源使用率是X%的時候，將需要多長時間來啟動下一個容器？”每個圖表有一個小標題比如：“10%的樣本容器在少於……時間內啟動”。這就表示，在同樣的目標水平，你有10%的概率將在少於圖表中給的時間啟動的下一個容器。所有值的單位都是秒。

如果你想要在Kubernetes上在一秒內啟動一台容器，如果你的系統上已經有一些負載的話，這可能性比較小。第3001台容器想要在1.83秒內啟動的概率是10%。

如果你想要在Kubernetes上在一秒內啟動一台容器，如果你的系統上已經有一些負載的話，這可能性比較小。第3001台容器想要在1.83秒內啟動的概率是10%。

到了資源占用率為90%時，在兩個平台之間的測評數據有最明顯差別，那就是Swarm在啟動容器的速度上快大約4至6倍。

在分析結果之前，我們看到在Kubernetes的90%至99%資源占有率過程中，數據有點走樣。在和同事討論該異常時，我們推測是etcd測試的線性性質和“模型建立”原因導致的問題。這些問題導致系統經歷一個異常的減速，並且在后面99%部分的變得很不穩定。我仍然在圖中標注上該數據，是因為這些數據也許可以表明集群長期運行下會出現的穩定性問題，這是非常有趣的。我曾經聽到一些說法是etcd v3會有一些改進，包括性能增強和清理任務等，也許可以幫助解決這個問題。所以，之后我使用了一個全新的集群來測試負載100%下的Kubernetes。由於該原因，所以我在以下的分析中不計在90%和99%資源使用率下的測試數據。

在分析這些圖表和得到的數據，你可以做一些着重的觀察：

1. Kubernetes的第30001台容通常在2.52秒至3.1秒啟動，而Swarm則只需要0.56秒至0.67秒。
2. 當集群中有3000台至30000台容器時，Kubernetes容器的啟動延遲會增加0.69秒至0.74秒，而Swarm只有0.22-0.27秒。
3. 觀察到Swarm的最長啟動延遲是1.14秒（第30001台容器），比Kubernetes的最短延遲（在第3001台容器是1.69秒）還短大約0.5秒多。

當做這類的測評時大的采樣量是很重要的，因為數據可以讓你更好地理解遇到一個特殊結果的可能性。在這個案例下，我們知道Kubernetes將花費幾秒的時間來啟動單台容器。Swarm通常可以在一秒內啟動一台容器，一般可以在0.7秒內啟動，除了10%的其他情況。那么這么小的延遲肯定會對一個真實的基礎架構決策有着實際的應用。

如果要我去建立一個“剛好及時”的容器系統，像AWS Lamda，那么我肯定會采用Swarm為基礎來搭建那個系統。

有趣的是，我想補充一點，復制控制器提供的Kubernetes並發容器調度的效果是很驚人的。使用Kubernetes復制控制器，我可以在155秒內創建3000個容器副本。如果沒有使用並發的話，將在Swarm上需要大約1100秒，在Kuberntes上則需要6200秒。

一些時候采用並行的方法是一個非常好的想法，這也正是編排系統平台的閃光點所在。

羅列容器命令的測試結果如下所示。請注意，Kubernetes在99%資源占有率下的測試結果是異常的，隨后我會用是一個健康的集群來在100%負載下重新測評。

Kubernetes里羅列容器命令的性能在集群資源使用率為90%至100%時，表現跟其他迭代測試的結果一致。



Swarm和Kube 大專欄  Docker Swarm和Kubernetes在大規模集群中的性能比較rnetes在容器密度較低時都表現得很好。在10%集群資源使用率的情況下，Kubernetes羅列所有容器所花費的時間總是比創建一個容器耗費的時間短。

數據表明，在集群資源使用率為50%至90%之間的某一點，Kubernetes的性能會超過某個閾值，而性能的降低也比它在10%至50%時的快。更深層地探究數據，我發現第50個百分點是6.45秒，而第75個百分點時是28.93秒。對於這一點，我更願意解釋為Kubernetes在集群使用率達到50%的時候羅列容器命令的性能開始出現大幅下滑。

Swarm的性能數據則比較少有戲劇性的變化但仍然說明了一些問題。就如同Kubernetes，Swarm也會有一個性能的臨界點，由有一個平緩的增長趨勢后跳到一個高很多級別的平緩增長趨勢。就是說該臨界點會影響集群在負載90%-99%時使效率提高，而在負載為50%到90%的區域使效率降低。

在所有的測試級別中，Swarm在集群使用率為99%時的性能表現比Kubernetes在集群使用率為10%時的性能仍快4到6倍。

在我跑完該基准測試后，我想對照現有可搜集到的其他測試數據確認一下我的發現。最終找到GitHub上一個從2015年1月開始的對調查容器啟動時間的項目。他們號稱可以達到他們的目標，“在一個100節點，3000個pod的集群上，可以使99%的預先拉取過鏡像的點對點pod的啟動時間達到小於5秒的性能指標。”我不能確定他們使用的是什么測試環境，但是我所收集的數據有着相同的數量級。

GitHub上的評論指出，測試端對端容器的啟動時間的延遲與測試調度吞吐量是不同的。CoreOS的Hongchao Deng在幾周前發布了一篇文章，關於Kubernetes的調度程序，並在一個虛擬或空環境中測試性能。那個測試把調度程序的性能與其他來源如網絡，資源競爭的噪音隔離開來。但真實環境並沒有那樣的隔離，所以想要在自然環境下有那樣的性能，有點不現實。CoreOS的文章寫得非常好，我逐字拜讀了。它是在實際應用工程中如何提高單個組件性能最好的一個例子。

總結一下，這些測評結果顯示我們所測試的操作在Swarm上運行得比Kubernetes的快。兩個集群用的都是相同的數據庫技術，相同的測試工具和網絡拓撲。我們可以推測，造成不同結果的原因是在架構和算法選擇上。在下一章，我們會深入到兩種架構中來了解。

Kubernetes和Swarm是否真的具有操作1000個節點的能力？

我曾經把兩個集群都擴建到1000個節點。這需要的時間就像90次迭代一樣，用了100多小時的研究和實踐。這一章將闡述了它們的架構，資源利用的設計理念等。

我在每個平台都啟動了默認工具。Kubernetes運行一個叫做kube-up.sh的腳本來啟動一個在某個雲服務上的單主控節點的集群。大多數的Swarm教程和指導會讓讀者用Docker Machine來生成集群（包括我自己）。然而兩種方法都不能讓集群擴到1000個節點。

為Kubernetes所創建的單主節點運行着etcd數據庫、API服務、kubelet、scheduler，、controller-manager、 flannel、kube-proxy和 一個 DNS server。Kube-up.sh可以提供這個集群但只要一個有300個備份的備份controller節點准備運行，那么master節點的性能就會下降。內存不會產生問題，但這些負載會消耗CPU。資源消耗所產生不穩定性和性能問題，會導致集群不可用。

用Docker Machine部署機器太慢了，並且當生成一個1000節點的集群時，經常會遇到不可恢復的錯誤，造成無法成功部署。我最初的實驗采用一些比如並行10個進程的方法。那會花費大約4個小時來創建前100個節點。當我增加並發數到100時，我馬上就后悔這么做。

那導致我的第一次經歷AWS的流量限速，並且導致AWS的web console不能用。

經過好幾個小時，又創建了另外100個節點來彌補錯誤（大約有10%的錯誤率——機器掛了，不是Docker）。我承認這不是個好想法，並終止了實驗。

自定義模板

當時我只在AWS上做測試。我選擇了CloudFormation，因為這是雲服務上自帶的。但后來反思我覺得我還是應該使用Terraform來在其他雲上測試。

我根據現有的最佳實踐和社區專家的專業知識設計了每個模板。我首先注意到，Swarm大集群的最佳之間與我之前創建了100次的演示集群有着相同的架構。Kube-up提供的Kubernetes集群需要一個架構上的改變。兩個架構圖如下圖所示。

左圖：Swarm的節點和管理器直接依賴於基於etcd的鍵值對存儲。而用戶端直接與Swarm的管理器連接。右圖：全部的Kubernetes節點，主組件和用戶端通過一個橫向擴展的API和一個負載均衡器通信。只有API服務與etcd通信。

上圖中，“Docker Group”和“Node Group”是各個集群的1000個節點組成的組。這些是用戶請求運行容器的機器。標注為“test-node”的機器用於跑測試。

有一個很有意思的地方是，根據Google這篇“Borg, Omega, and Kubernetes”文章描述，Swarm的框架與Omega類似。兩個系統都讓控制板組件直接與數據庫連接。而Kubernetes把全部組件間的通信都集中在一個橫向擴展的API上。

Kubernetes的API服務允許你根據資源和組類別關聯數據庫，通過設置–etcd-servers-overrides標志字就可以完成。我把熱數據（例如指標和事件）與可操作資源如job和pod隔離開來。Kubernetes large cluster configuration guide這篇指導描述了怎么關聯數據庫。實現1000個節點或更多節點的集群就需要這么做。

下圖表示啟動一個容器的不同序列以及不同順序會怎么影響性能數據。每個灰色的列代表一個網絡上的不同host。

啟動Swarm（1）中的一個容器，就會有一個客戶端連接到Swarm管理器。管理器執行一個基於以及采集好的資源數據設計的計划算法。然后（2）管理器會直接連接到目標節點，並且啟動容器。當節點啟動容器，它會反饋給管理器。管理器會立即給客戶端響應。在操作的過程中，客戶端的連接是打開的。

以下這個序列圖是基於我對系統架構大致了解的介紹，可能會包含細節上的錯誤。該圖忽略了大多數內部進程和非正式的交互（某些API服務或組件在工作是因為它在運行的狀態，並不是因為它與一個請求在進行交互）。

在Kubernetes，（1）一個客戶端通過一個負載均衡器連接到一個API服務，（2）會在etcd中產生一個資源。Etcd執行它的狀態機然后（3、4）通過API服務器就新的資源數據更新觀察者服務，之后，（5、6）controller-manager會對一個新的job請求做出響應並且通過再次調用API服務來創建一個新的pod資源。然后，（7、8）etcd會通過API更新這個新資源的監視器，（9）同時會觸發程序調度器做一個新的調度決策，並且（10、11）通過API把pod指派給一個節點。最后，（12、13）etcd和API把指派信息通知目標Kubernetes節點並（14）啟動容器。在容器啟動之后，（15、16）會通過API來吧狀態改變記錄在etcd中。

Kubernetes的工作流程比Swarm涉及更多在網絡的交互，API調用和數據庫中的資源。同時，Swarm的架構缺少一個控制的中心點和一個組件來分擔未來更多功能加進來時對數據庫造成的負擔。

在大規模的Kubernetes系統中，API機器的運行會占用15%到30%的CPU。數據庫也差不多。Swarm的管理器會占用大約10%的CPU，而數據庫大約是8%。

筆者個人猜想，Swarm可以再擴展幾千個節點，數據庫才會遇到一些問題。而Kubernetes擴展架構則需要更過的API host（你會知道什么時候應該關注這些機器的CPU使用量）。

如何支持這些大規模系統是另一個問題

每個人都有自己的偏愛和己見。市場上的宣傳，痛苦的經歷，長長的評論欄，冷卻的推測都會使偏愛升溫。不做量化的綜述， 我提出兩種估算應用的方法，同樣可以適用於估算建立一個系統所需的工作量。如果你有其他的定義或改進我的估算方法，我希望聽到你的意見。

總的說來，Docker Swarm一定程度上比Kubernetes集群組件更加容易應用和支持。

應用工作量（adoption effort）指的是從一個新手到熟練地操作一項新技術所需要的工作量。這適用於一個團隊采用一項新的技術和每次團隊新增一個成員時的情景。觀察發現，任何組件的學習曲線和這個組件的抽象概念的數量成正比，所以我提出下列這個公式來計算一個應用工作量指數（adoption effort index ，AEI）：

1	adoption effort = component count * abstraction count

就像AEI，一個運維工作量指數（a support effort index ，SEI）是一個指標，表示長期運維一個平台所需要的工作量級別是多少。基於筆者自己的實驗，發現這個指數應該與組件之間交互序列的平均長度成比例。SEI反映了一個操作失敗的機會數。我提出了以下的計算公式：

1	support effort = component count * interaction sequence length

諸如此類的標准對於社區可以專注於討論具體的論點是非常重要的。不然對話可能會變得模凌兩可或情感導向。在這種情況下，社區的發展很難有進一步前進。

Kubernetes提供的功能相對於Swarm來說是一個超集。出於單項對比的考慮，我們只比較測試他們之間可以類比的組件。測試的Kubernetes配置有以下組件：

• Docker Engine
• kubelet binary
• Pod-master
• Controller-manager
• Scheduler
• API server
• Etcd

一個包含網絡環境的生產環境配置也需要包括：

• Flannel
• kube-proxy
• kube-dns

測試的Swarm配置有如下組件：

• Docker Engine
• Swarm Manager
• Swarm in Join Mode
• etcd

一個multi-host的網絡的Swarm集群應該只需要增加一個組件：libnetwork——這個是Docker daemon的一部分——也在其他的一些工具如Flannel、Weave或者是Calico項目之中。

剔除通用組件（Docker Engine和etcd）和不計一些影響不大的組件，如負載均衡器等等之后，Kubernetes的組件數只剩5個，而Swarm只有2個。

Docker和Swarm提供相同的抽象功能，但Swarm還把集群本身抽象成為一台機器。相同的抽象有：

• Containers
• Images

Kubernetes還提供“集群”抽象，另外在測試中還使用以下抽象：

• Containers
• Images
• Pods
• Jobs

最終結果是Swarm的抽象數量為3，而Kubernetes是5個。Kubernetes的功能豐富，這個數字還忽略了“replication controllers，” “services” 。采用這些抽象會提高AEI。

把這些數值插入到應用工作量指數等式中，得到的Kubernetes的指數是25，而Swarm是6。

對比支持工作量指數可以用模糊數學評估。據我所知，全部的Swarm操作都需要引入單個內部組件交互來完成。那么列舉操作可能頻繁使用這種並發的交互。Kubernetes中最短的操作可能是列舉操作需要至少兩步完成。我所理解的創建job操作需要5或更多的交互。

Swarm的運維工作量指數是2，Kubernetes是至少25。

反觀這些數字，我想確定的是，很明顯，選擇Kubernetes並不是我的意圖。這些數字反映Kubernetes是一個龐大的項目，有很多可移動的部分，有很多方面可以學習，但也有更多潛在失敗的機會。即使如此，Kubernetes所完成的架構可以防止一些Swarm上已知的弱點，這就有可能產生更多深奧的問題和細微差別。

所調查的這些工作量可以作為參考，只作為一個實施者想要使用Kubernetes提供的擴展功能集所需要投入的時間與精力。

行動的召喚

整個工程社區似乎都醉心於容器和上述提到那些奇妙的工具之中。 我非常高興有機會去實驗或者實踐其中的一些。 這些推動的力量加上這些工具幫助整個社區以比起以往更加快的速度推動技術的進步。

但是”擁有某個工具”和”理解某個工具在大生態圈中表現出來的優勢和劣勢”是有差別的。而優化一個沒有任何衡量標准的工具是非常困難的。 因此，進一步的做類似的研究和開發對於整個社區而言是有益的。同時， 制定開放和可復驗的測試基准，透明的分析過程和清晰的相關標准將會幫助決策制定者在一個數據驅動的環境中完成他的決策工作。

最后，請幫助我們在這個話題上做進一步的拓展。 我們需要其他領域，雲供應上和集群配置方面的數據。 我們需要拓展我們的公共測試基准，使其能覆蓋更多的功能點。 我們需要一個更加具有可拓展性的測試工具。 我們需要更多對於將猜測剝離出設計本身感興趣的人士的參與。

所有我所用到的代碼和模板都能在GitHub上找到。 請親自嘗試運行這些測試然后幫助我們改進或者提出改進的建議。 如果你有突發的靈感並且自己開發了一些東西，請別猶豫，將它們給分享給大家吧。 我們需要這些數據。

Cloud Container Cluster Common
Benchmark：https://github.com/allingeek/c4-bench
Evaluating Container Platforms at Scale
Data：https://github.com/allingeek/ecps-data

原文鏈接：Evaluating Container Platforms at Scale（翻譯：Lynna）