最佳實踐系列丨Docker EE 大規模部署指南（一）

本文首發自“Docker公司”公衆号（ID：docker-cn）

編譯丨小東

每周一、三、五 與您不見不散！

此參考架構将幫助您規劃大規模 Docker 企業版部署。它涉及核心 Docker EE 平台、Universal Control Plane 以及 Docker Trusted Registry。請使用本指南來幫助确定 Docker EE 部署的硬體和基礎架構規模，并确定針對您的具體工作負載的最佳配置。

您将學到的知識

對于 Docker EE、Universal Control Plane （UCP）和 Docker Trusted Registry （DTR），本指南涵蓋了：

• 哪些應用場景參數很可能會影響規模要求；
• 基于實際測試的已知規模限制；
• 確定良好性能和未來增長餘地的最佳實踐；

Docker EE 與 Docker Universal Control Plane

本節論述實作優化性能和增長潛力的基礎 Docker EE 平台和 Universal Control Plane 配置。

管理節點的數量

對于生産叢集，建議的管理節點數量是 3 個或 5 個。3 管理節點叢集可以容許損失 1 個管理節點，而 5 管理節點叢集可以容許 2 個管理節點暫時故障。具有更多管理節點的叢集可以容許更多管理節點發生故障，但是增加管理節點也會增加維護開銷和按 Docker Swarm Raft 法定多數送出叢集狀态的開銷。在某些情況下，擁有較多管理節點（例如 5 個或 7 個）的叢集可能（在叢集更新延遲和吞吐量方面）不如隻有 3 個管理節點但其他規格類似的叢集。

一般而言，增加管理節點數量不會加快叢集操作速度（在某些情況下，反而會使速度變慢），不會增加叢集最大更新操作吞吐量，也不會增強叢集能夠管理的工作節點總數。

即使在管理節點發生故障，失去法定多數的情況下，叢集上的服務和任務也會繼續運作，并且保持穩态穩定（隻不過在沒有法定多數的情況下，無法更新叢集狀态）。是以，Docker 建議将投資花在個别管理節點故障後快速恢複的能力上（例如用于快速添加替換管理節點的自動化/腳本），而不要規劃具有大量管理節點的叢集。

1 個管理節點的叢集應該僅用于測試和試驗，因為損失管理節點就會導緻叢集損失。

請檢視文檔來擷取關于 Swarm 管理節點和工作節點配置的詳細資訊。

管理節點大小和類型

生産叢集中的管理節點最好擁有至少 16GB 的 RAM 和 4 個 vCPU。Docker 進行的測試表明，擁有 16GB RAM 的管理節點即使用在有 100 個工作節點和衆多服務、網絡及其他中繼資料的叢集中，也不會受限于記憶體大小。

生産叢集中的管理節點應該_始終_對 /var/lib/docker/swarm 挂載點使用 SSD。Docker 在此目錄中存儲 swarm 叢集狀态，并且會在叢集狀态更新時進行衆多小更新的讀寫。SSD 将確定以盡可能小的延遲送出更新。建議在用于測試和試驗的叢集中也使用 SSD 來確定良好性能。

提高 CPU 速度和數量，以及改善管理節點之間的網絡延遲，也會提高叢集性能。

工作節點大小和數量

對于工作節點而言，Docker 元件和代理程式的開銷并不大 – 通常小于 1GB 記憶體。确定工作節點大小和數量的過程與您目前确定應用或 VM 環境大小的過程類似。例如，您可以确定負載下的應用記憶體工作集，并考慮每個應用需要多少從節點（確定任務失敗時的耐用性和/或吞吐量）。這樣一來，您對叢集中各工作節點需要的總記憶體量就有了一個認識。

請記住，在工作節點發生故障時（或者您清空某個節點以進行更新或維修時），Docker Swarm 會自動重新排程任務，是以别忘了留出餘地，使任務能夠再平衡到其他節點。

還要記住的是，Docker 容器與虛拟機不同，與在容器外運作相比，在容器中運作應用所增加的記憶體或 CPU 開銷極小或為零。如果将應用從各個 VM 移動到容器中，或者将許多應用合并到一個 Docker EE 叢集中，那麼您為此使用的資源将比目前使用的少得多。

任務分割和限制資源使用

在生産叢集中，切勿在管理節點上運作工作負載。這是 Docker Universal Control Plane (UCP) 中的一種可配置的管理節點設定。

如果在叢集上部署的任務和服務具有差異很大的資源概要，而且您希望對不同的任務（例如具有不同的磁盤、記憶體或 CPU 特征）使用不同的節點類型，可以使用節點标記和服務限制來控制 Swarm 對特定服務的任務排程。

您還可以将節點加入集合以及基于使用者帳戶和團隊控制通路。如果某些團隊或個人經常要部署的應用會消耗許多資源，或者具有對其他團隊運作的任務産生不利影響的擾鄰特征，用這種方法可以有效隔離他們所管理的任務。請參見 RBAC 知識庫文章了解關于如何使用 Docker 企業版設計團隊和項目結構的示例。

資源限制

Docker EE 支援對容器和服務任務應用資源限制。Docker 建議在建立服務時使用 --reserve-memory=和 --limit-memory=參數。這些參數讓 Docker EE 可以根據預期的記憶體消耗，更好地在工作節點上打包任務。

此外，配置設定一個全局（每節點 1 個執行個體）“幽靈”服務也許是個好主意，它可以在每個節點上保留一部分（例如 2GB）記憶體，供非 Docker 系統服務使用。因為 Docker Swarm 目前不會考慮非 Docker 管理的工作負載所消耗的工作節點記憶體，是以這個方法很有意義：

docker service create --name system-reservation --reserve-memory 2G --limit-memory 2G --reserve-cpu 1 --mode global nginx:latest
           

(nginx 在此服務中實際上不執行任何工作。)（可以使用任何不會消耗大量記憶體或 CPU 的小鏡像取代 nginx）。

請檢視關于容器資源限制和為服務保留記憶體或 CPU 的文檔。

磁盤空間

對于生産叢集，您需要關注幾個影響工作節點磁盤空間使用的因素：

• 工作節點上使用中的 Docker 容器鏡像；
• 為容器建立的本地 Docker 存儲卷；
• 工作節點上存儲的容器日志；
• 工作節點上存儲的 Docker 引擎日志；
• 容器寫入的臨時資料；

工作節點上的容器鏡像

要确定該為使用中的鏡像配置設定多少空間，請嘗試将一些應用放入容器，然後檢視産生的鏡像有多大。請注意，Docker 鏡像包括多個層，如果有多個容器使用同一個層（對于 ubuntu 之類的 OS 層或 openjdk 之類的語言架構層來說很常見），在任何一個節點或 Docker Trusted Registry 上隻會存儲和使用該層的一個副本。層共享也意味着部署應用的新版本通常隻會使節點上被占用的空間增加相對較小的幅度（因為隻有容納應用的最上數層發生更改）。

請注意，Docker Windows 容器鏡像往往會變得比 Linux 容器鏡像大。

為了持續監視使用中的容器鏡像存儲，應該盡量確定應用鏡像從通用的基礎鏡像衍生。還可考慮運作定期腳本或 Cron 作業來修剪不使用的鏡像，特别是在節點要處理許多鏡像更新的情況下（例如比較頻繁地發生部署的建構伺服器或測試系統）。請參見關于鏡像修剪的文檔擷取詳細資訊。

日志

對于生産叢集，Docker 建議使用日志記錄驅動或其他第三方服務聚合容器日志。隻有 json-file（可能還包括 journald）日志驅動會導緻容器日志在節點上累積，在這種情況下，要注意輪替或删除舊的容器日志。請參見日志記錄設計與最佳實踐擷取詳細資訊。

Docker 引擎日志存儲在工作節點和管理節點上。産生的引擎日志數量根據工作負載和引擎設定而變。例如，debug 日志級别會導緻系統寫入更多日志。應該使用 logrotate 之類的實用程式管理引擎日志（壓縮并最終删除）。

Overlay 網絡和網格路由

Docker EE 附帶受支援的内置 Overlay 網絡驅動，用于實作配合 Docker Swarm 使用的多主機網絡。Overlay 網絡會造成與封裝網絡流量和管理 IP 位址及其他跟蹤網絡任務和服務的中繼資料有關的開銷。

Docker EE 客戶如果有網絡吞吐量要求非常高或者工作負載動态性極高（叢集或服務的更新頻率很高）的應用，應該考慮盡量降低對開箱即用的 Docker Overlay 網絡和網格路由的依賴。要達到這一目的，有多種方法：

• 使用主機模式釋出取代網格路由；
• 使用 macvlan 驅動，它的性能可能好于預設驅動；
• 使用非 Docker 服務發現機制（例如 Consul）；
• 考慮使用 dnsrr 取代 vip 服務端點；

如果 Overlay 網絡由使用基于 VIP 的端點模式建立（預設）的服務所使用，則網絡大小不應該超過 /24 個含 256 個 IP 位址的區塊（預設）。使用者不應該通過增加 IP 區塊大小來繞過此限制，而應該使用 dnsrr 端點模式或使用多個較小的 Overlay 網絡。

還應注意的是，如果對一個 Overlay 網絡配置設定了大量任務，例如有許多任務關聯到該網絡或者網絡上的服務擴充到許多從節點，那麼 Docker EE 可能會遇到 IP 枯竭的問題。在因為節點故障而重新排程任務時，也可能出現該問題。目前如果發生節點故障，Docker 會等待 24 小時以釋放 Overlay IP 位址。可通過在 Docker 守護程序日志中查找 failed to allocate network IP for task 消息來診斷該問題。

HTTP 網格路由

含有 Universal Control Plane 的 Docker 企業版附帶内置的 HTTP 網格路由功能。HTTP 網格路由因為增加了網絡跳數和路由控制，會增加一些開銷，應該僅用于管理對外部暴露的服務的網絡。對于在 Docker 上托管的服務之間的網絡和路由，隻須使用标準的内置 Docker Overlay 網絡即可獲得最佳性能。