我們每天在數百臺伺服器上執行成百上千個容器，面臨的最大一個挑戰是怎樣高效地排程容器。容器的排程是指在一組伺服器上處理容器分配的問題，以保證服務能平穩執行。由於這些需要排程的容器是客戶應用程式的元件，我們必須在還未知曉其效能特點之前進行排程。

　　不合適的排程方法會導致以下可能的結果：

　　過多的資源配置——意味著更高的成本。

　　過少的資源配置——意味著使用者的穩定性差。

　　合適的排程方法對我們而言很重要，以經濟高效的方式，提供最好的使用者體驗。

　　隨機性排程策略

　　起初，在我們的早期產品中使用了相同的排程方法。這個方法(在Docker Swarm之前)沒有以任何方式對容器的執行進行約束，而只是簡單地隨機選擇一個伺服器。

　　但是，執行全棧環境和執行程式碼段是完全不同的事——我們很快發現，這個解決方案並不理想。我們的伺服器經常因繁忙導致CPU過載和記憶體不足。

　　硬約束條件

　　我們一起根據需要，定義了一種新的排程器：不再隨機選擇伺服器;要能約束執行所需的資源分配，理想情況下，還要易於部署。

　　幸運的是，Docker Swarm擁有了全部這些特性，最近該工具的穩定性也已滿足生產環境的要求。我們使用spread排程策略，以減少因伺服器故障而損壞的容器數量。並設定了基於映象的類別關係，同類容器可以執行在同樣的伺服器中。

　　我們使用了Datadog中Docker整合功能，可詳細觀測容器使用資源的情況。Datadog包含了所有我們需要的資料，可用來描述每個容器的記憶體或CPU使用率，以及每個伺服器的磁碟使用率。

　　有了這份資料，我們發現記憶體是制約因素(不是CPU或磁碟)，因此，我們決定利用記憶體約束來排程我們的容器。我們根據觀測到的Datalog記憶體分配情況，設定我們的記憶體約束在99%的位置即1GB。我們還可以手動重置對每一個容器的約束。

        結果顯示，這個約束非常有效!我們將不會再看到伺服器記憶體不足，或因超載而執行緩慢。

　　軟約束條件

　　享受了這個發現所帶來的穩定性，在一段時間後，我們注意到，這種策略過度佔用了伺服器資源。大多數容器實際的記憶體使用率遠遠低於該記憶體硬約束1GB。這意味著我們所付費的比實際使用的多很多。

　　我們想要更經濟高效，但又不能損失穩定性。降低硬約束不是一個好的選擇，因為耗記憶體的應用會因為這個約束而崩潰。

　　我們需要一種基於估計的約束，在必要時又可以被突破的排程方法。值得慶幸的是，Docker提供了--memory-reservation選項來設定記憶體軟約束。當設定該軟約束時，容器可以自由地使用所需的記憶體，但是，當伺服器上有記憶體爭用時，Docker會試圖縮減記憶體到軟約束值以內。基於軟約束的排程會減少浪費，並設定一個硬約束來阻止失控。但Swarm沒有這個功能，所以是時候需要我們使用Go語言，給Swarm建立一個定製版本分支，可排程軟記憶體約束，而不是硬約束。再使用Datadog收集資料，基於概率選擇理想的軟約束閥值，並設定硬約束為容器使用的最大值。這個方法顯著地減少了浪費，而且也沒有影響到穩定。

        動態範圍和突破

　　Docker1.12.0版中，最酷的一個功能是排程軟約束的能力。雖然它仍等待發布，不過我們已經提前嘗試，可簡便地使用如下命令來排程軟約束。

　　docker service create --reserve-memory <soft_limit>

　　鑑於軟約束的成功，我們的下一步是為每個容器動態地選擇軟約束和硬約束。因為所有的資料都輸送到了Datadog，可通過一個查詢，得到理想的軟硬約束閾值，保持容器穩定執行而又不浪費資源。敬請關注這個部落格，我們一有結果就會讓您知道!

　　原文連結：Cost-efficient container scheduling with Docker Swarm(翻譯：陳晏娥，校對：黃帥)