Mesos 與 Marathon 和 Docker Swarm 容器協調實戰

– 11 分鐘閱讀

Mesos 作為一個分散式系統核心，負責管理叢集資源，並透過兩階段的資源分配機制將資源提供給 Marathon 等框架。Marathon 則專注於長期執行的應用程式，提供自動重啟、健康檢查和擴充套件等功能。相較之下，Docker Swarm 作為 Docker 原生協調引擎，簡化了叢集的建立和管理，並提供服務、任務等抽象概念來管理容器化應用程式。在資源分配方面，Mesos 使用「報價」機制，讓框架決定是否接受資源，而 Marathon 則根據 JSON 組態檔案定義應用程式需求，並由 Mesos 進行資源分配。Docker Swarm 則透過管理節點和工作節點的協作來分配任務，並確保服務的穩定執行。服務佈署方面，Marathon 使用 JSON 檔案描述應用程式規格，包含容器映像、資源需求和例項數量等資訊。Docker Swarm 則透過 docker service create 命令建立服務，並可使用 docker service scale 進行擴充套件和縮減。服務發現方面，Docker Swarm 內建 DNS 機制，讓容器之間可以透過服務名稱互相存取，簡化了服務發現的過程，而 Mesos 和 Marathon 則需要額外整合服務發現工具。隨著容器技術的發展，這些工具也持續演進，未來將會出現更多自動化和智慧化的功能，例如根據機器學習的資源排程和自動擴充套件。

容器協調技術：Apache Mesos 與 Marathon

在現代雲端運算與容器協調技術中，Apache Mesos 與 Marathon 是兩個強大的工具。Mesos 提供了一個靈活且高效的資源管理框架，而 Marathon 則是建立在 Mesos 之上的應用協調工具。本篇文章將探討 Mesos 與 Marathon 的架構與功能，並結合實際案例來說明它們的應用。

Mesos 的架構與功能

Apache Mesos 是一個開源的容器協調框架，適合大規模生產環境使用。Mesos 類別似於作業系統核心，負責管理叢集中的資源。它採用主從式架構，由主節點和從節點（代理節點）組成。主節點負責管理叢集資源，而從節點則執行實際的工作任務。

主要組成部分

  1. Mesos Master：

    • 主節點上的守護程式，負責管理叢集中的所有代理節點。
    • 提供計算資源（如 CPU、記憶體、網路和磁碟資源）給框架。
    • 可以支援多個框架同時執行，每個框架都可以向 Mesos 單獨提出資源請求。

  2. Agents：

    • 工作節點，負責執行實際的工作任務。
    • 每個工作節點上執行一個代理守護程式，負責收集和報告統計資料給 Mesos Master。
    • 當從 Mesos Master 接收到工作任務時，代理守護程式會啟動一個執行器來執行該任務。

  3. Frameworks：

    • 框架是資源的消費者，負責在叢集中執行實際的工作任務。
    • 框架有兩個主要組成部分：排程器和執行器。
      • 排程器：向 Mesos Master 註冊，並根據接收到的資源報告決定是否接受或拒絕這些資源。
      • 執行器：在代理節點上執行實際的工作任務。如果框架沒有提供自己的執行器，可以使用 Mesos 提供的預設執行器。

框架與資源分配

Mesos 透過「報價」機制來分配資源。當 Mesos Master 接收到代理節點的可用資源報告後，會將這些資源以「報價」的形式傳送給已註冊的框架。框架可以根據自己的需求決定是否接受這些報價。

例如，假設一個報價包含「12GB 記憶體、8 個 CPU 核心可用」，框架會檢查自己的任務需求是否可以滿足這些報價。如果可以，則接受；否則拒絕。

Mesos 的資源分配策略是高度可組態的，叢集管理員可以根據組織需求和任務優先順序來定義每個框架可以使用的資源比例。

Marathon 框架

Marathon 是建立在 Mesos 上的一個應用協調工具，專注於長期執行（long-running）應用的管理。Marathon 提供了豐富的功能來簡化應用佈署和擴充套件。

佈署三個目錄微服務例項

假設我們要在叢集中佈署三個目錄微服務例項（catalog microservice），以下是如何使用 Marathon 來描述這個需求：

{
  "id": "catalog-svc",
  "cpus": 0.5,
  "mem": 8.0,
  "instances": 3,
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "helpdesk/catalog-svc",
      "network": "BRIDGE",
      "portMappings": [
        {"containerPort": 80, "hostPort": 80, "protocol": "tcp"}
      ]
    }
  }
}

此 JSON 組態表示我們需要在叢集中執行三個目錄微服務例項。container 段落指定了容器型別為 Docker 容器，並詳細說明瞭所使用的 Docker 映象及網路組態。

舉例解說

此圖示展示瞭如何在 Marathon 中定義一個目錄微服務例項：

  graph TD;
    A[Marathon] --> B[Mesos Master];
    B --> C[Agent 1];
    B --> D[Agent 2];
    B --> E[Agent 3];
    C --> F[Executor];
    D --> G[Executor];
    E --> H[Executor];

    subgraph Docker Container
        F1[Catalog Microservice];
        G1[Catalog Microservice];
        H1[Catalog Microservice];
    end
次段落標題：內容解密：
  • Marathon：Marathon 是一個應用協調工具，負責將應用佈署到叢集中的各個代理節點上。
  • Mesos Master：Mesos 主節點負責管理叢集中的所有代理節點及其可用資源。
  • Agent：代理節點（Agent）是實際執行工作任務的工作者。每個代理節點上執行一個代理守護程式。
  • Executor：執行器是負責在代理節點上執行實際工作任務的程式或容器。Marathon 提供自己的執行器來處理 Docker 容器。
  • Docker Container：Docker 裝載特定應用（此處為目錄微服務）並且外部網路進行通訊。

Marathon 的優勢

Marathon 提供了豐富的功能來簡化應用佈署和擴充套件：

  • 自動重啟：當應用失敗時，Marathon 自動重啟應用。
  • 健康檢查：Marathon 提供健康檢查功能來確保應用正常執行。
  • 擴充套件性：可以輕鬆地擴充套件或縮減應使用案例項數量來應對不同的負載需求。

資安與監控

除了協調功能外，Mesos 和 Marathon 還提供了豐富的監控和安全功能：

  • ZooKeeper：Mesos 和 Marathon 需要 ZooKeeper 作為分散式協調服務來確保高用性和一致性。
  • 監控工具：可以使用 Prometheus 和 Grafana 等工具來監控叢集中的各種指標。

未來趨勢

隨著容器技術的不斷發展，Mesos 和 Marathon 的角色也在不斷演變。未來可能會看到更多自動化和智慧化的協調功能，例如根據機器學習的人工智慧排程系統。

Docker Swarm 容器協調引擎

Docker Swarm 是來自 Docker 自身的原生容器協調引擎。Swarm 實際上是一組啟用了 Swarm 模式的 Docker 容器，這些機器（Docker 引擎）共同構成了一個 Swarm 叢集。Swarm 有效地管理叢集，指示叢集節點執行容器。讓我們來看看其中的主要概念。

節點（Nodes）

在簡單的術語中，節點就是屬於 Swarm 叢集的一個 Docker 引擎。叢集中既有工作節點（Worker Nodes），也有 Swarm 管理節點（Manager Nodes）。Swarm 管理節點是 Swarm 叢集的大腦，負責透過指示工作節點執行容器來管理 Swarm 叢集。

管理節點並不是作為單一節點佈署的；相反，通常佈署奇數個節點，如三、五和七個，以避免成為單一故障點。管理節點執行所謂的 raft 一致性演算法來「選舉」一個長官者。如果長官者當機，其中一個追隨者將被選為新的長官者，從而避免系統中斷或任何型別的失敗。

服務（Services）

服務是對於需要在叢集節點上執行的內容進行定義。服務定義包括以下幾項：

  • 在容器中執行的映像
  • 需要在容器內執行的命令
  • 副本或正在執行的容器例項數量

任務（Tasks）

任務是 Swarm 中排程的基本單位，它包含了需要在容器內執行的 Docker 容器以及命令。當 Swarm 管理者收到啟動服務的請求時，服務僅僅表示要啟動哪個容器以及需要在叢集中執行多少個例項。然後，管理者將任務（要啟動的容器和需要在容器內執行的命令）分配給工作節點，並讓工作節點啟動這些容器。它還確保在叢集中啟動了所需數量的副本（例項）。

作為終端使用者，我們只需提及我們的意圖或應用程式的期望狀態，Swarm 管理者則確保應用程式的期望狀態得到實作並維持。

Docker Swarm 叢集範例

讓我們動手來看看如何建立一個簡單的 Swarm 叢集。好訊息是，只要你有安裝 Docker，就不需要額外軟體設定來進行 Swarm 的操作。截至撰寫本文時，Docker 的最新版本是 17.06，我們將使用這個版本來探索 Swarm。

Docker Swarm 叢集設定

在這個範例中，我們設定一個包含兩個節點的 Swarm 叢集（一個管理者，一個工作者）。

首先在你想要設定成管理者節點的機器上執行以下命令來初始化一個 Swarm 叢集：

docker swarm init --listen-addr 10.88.237.217:2377

此命令中的 10.88.237.217 是執行該命令機器的介面 IP 地址，而 2377 是節點監聽來自 Swarm 管理流量的預設埠。

初始化完成後，你會看到如下輸出：

Swarm initialized: current node (ckmtounajpf06pglhv8jerlou) is now a manager.
To add a worker to this swarm, run the following command:
docker swarm join \
--token SWMTKN-1-60v0219bqi48oeimlhbby39huseueu9redz94obklzzceazw43-6hlck485hgtifuw2u71u3j2dy \
10.88.237.217:2377
To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

這時候還沒有工作者節點加入到叢集中，我們只有一個 Swarm 管理者。

檢視叢集中的節點

我們可以列出叢集中的所有節點以快速檢視叢集中的哪些節點：

docker node ls

你會看到如下輸出：

ID                            HOSTNAME          STATUS    AVAILABILITY   MANAGER STATUS
ckmtounajpf06pglhv8jerlou   * swarm-master   Ready     Active         Leader

從輸出可以看出，Swarm 主機目前是唯一的一個節點。

新增工作節點

接下來我們要將另一台安裝有 Docker 的機器新增到這個 Swarm 叢集中作為工作者節點。我們需要在該機器上執行以下命令：

docker swarm join --token SWMTKN-1-60v0219bqi48oeimlhbby39huseueu9redz94obklzzceazw43-6hlck485hgtifuw2u71u3j2dy 10.88.237.217:2377

從此命令可以看出，要使一台機器成為工作者節點，只需執行 swarm join 命令並提供主機 IP 和埠詳細資訊即可。

這樣就完成了基本的 Docker Swarm 叢集設定。接下來可以進一步學習如何佈署和管理服務、任務等高階功能。

內容解密：

Swarm 是 Docker 自身提供的一種原生容器協調引擎，它將多台機器整合成一個叢集來執行和管理容器化應用程式。理解節點、服務和任務這些核心概念非常重要。

  • 節點：通常由多個 Docker 引擎組成，包括工作節點和管理節點。
  • 服務：定義了應用程式需要執行的內容及其組態。
  • 任務：具體執行內容及其分配與排程細節。

設定一個簡單的 Docker Swarm 叢集只需初始化一個節點作為管理節點並透過特定令牌將其他機器新增為工作節點即可。這使得叢集擴充套件變得非常方便和高效。

小段落標題

架構設計與高用性

Docker Swarm 的設計注重高用性和簡單易用性。透過 raft 一致性演算法確保即使主節點故障也能快速選舉新長官者從而保證系統不中斷執行。此外多個管理節點佈署進一步避免單點故障帶來的風險。

小段落標題

實戰操作與應用

透過實際操作可以看到 Docker Swarm 的便捷性及其強大功能：從簡單初始化到新增多個工作節點僅需幾條簡單命令即可完成。這對於實作高可擴充套件性和穩定性至關重要。

下一步挑戰

隨著業務規模擴大及複雜度增加，進一步掌握如何在生產環境下佈署和維護 Docker Swarm 叢集將會更加重要。透過實踐與學習高階功能組態與最佳化手段將能進一步提升系統效能及穩定性。

Docker Swarm 叢集與服務管理

在現代的技術環境中，Docker Swarm 提供了一個強大的工具來管理容器叢集。本文將詳細介紹如何設定和管理 Docker Swarm 叢集，並探討服務建立、擴充套件及服務發現的相關概念。

叢集節點管理

首先，讓我們來看看參與叢集的節點。透過以下命令可以列出所有節點：

docker node ls

執行此命令後，你應該會看到一個管理節點（manager）和一個工作節點（worker），這些節點共同組成了 Swarm 叢集。

此圖示

  graph LR
    A[管理節點] --> B[工作節點]
    B --> A

內容解密：

  • 圖示解說：此圖示展示了 Docker Swarm 叢集中的基本架構，包括一個管理節點和一個工作節點之間的雙向關係。
  • 邏輯關係：管理節點負責叢集的管理和排程，而工作節點則執行實際的容器任務。
  • 技術考量：這種架構確保了高用性和負載平衡，因為管理節點可以動態分配任務給多個工作節點。

服務建立

接下來，我們將建立一個 Tomcat 服務並在叢集中佈署它。首先，我們需要確定要使用的 Docker 映像（image）及需要執行的例項數量（replicas）。

假設我們開始時沒有任何執行中的容器：

docker ps -a

我們可以看到 docker ps -a 沒有傳回任何條目，表示目前沒有任何容器在執行。

接下來，我們建立一個服務並指定使用 tomcat:7.0 映像，並要求 Swarm 管理者建立一個例項：

docker service create --name TomcatService --replicas 1 tomcat:7.0

執行這個命令後，我們可以再次使用 docker ps -a 檢視容器狀態：

docker ps -a

這次我們會看到一個名為 TomcatService 的容器在執行。最後，使用 docker service ls 列出剛剛啟動的服務：

docker service ls

結果顯示 TomcatService 正在執行並且達到了預期的副本數量。

擴充套件與縮減

擴充套件服務非常簡單，只需要求 Swarm 管理者增加 Tomcat 副本的數量即可：

docker service scale TomcatService=2

這會在叢集中啟動額外的容器。稍等片刻後，使用 docker service ls 檢視服務狀態：

docker service ls

你應該會看到 TomcatService 的副本數量已經增加到兩個。同樣地，縮減服務也非常簡單：

docker service scale TomcatService=1

這樣就會將副本數量減少回一個。

此圖示

  graph TD;
    A[Docker Service] --> B[Replica 1];
    A --> C[Replica 2];
    B --> D[Container Instance];
    C --> E[Container Instance];

內容解密：

  • 圖示解說：此圖示展示了 Docker 服務如何管理多個副本（replicas），每個副本都對應到一個實際執行中的容器例項。
  • 邏輯關係：Docker Service 作為控制層負責排程和管理多個容器例項。
  • 技術考量：這種設計確保了高用性和水平擴充套件能力，能夠根據負載情況動態調整容器例項數量。

服務發現

在理解了如何建立和擴充套件服務之後，我們來探討一下服務發現的概念。服務發現是指在分散式系統中找到特定服務執行位置的機制。傳統上，當我們佈署應用程式時，通常會給服務命名以表示其功能，例如 helpdesk-db.domain.com。然而，隨著虛擬機器（VMs）和雲技術的普及，動態新增和移除節點變得更加常見。

傳統與現代服務發現

在傳統環境中，負載平衡器如 NGINX 或 HAProxy 被用來分配流量到多個服務例項。當新的 VM 被新增時，負載平衡器會自動更新組態以反映這些變化。

然而，在現代的容器化環境中，由於容器能夠快速啟動和停止，服務發現變得更加複雜。幸運的是，有許多工具可以幫助我們處理這些問題。

常見的服務發現模式

  1. 客戶端側服務發現：客戶端從登入檔中查詢服務位置。登入檔包含所有服務及其位置資訊。當服務啟動或停止時，登入檔會自動更新。
  2. 伺服器端側服務發現：客戶端透過請求特定 URL 或 API 取得可用的服務列表。

Docker Swarm 的優勢

Docker Swarm 本身就內建了一些基本的服務發現機制。當你建立一個 Docker Swarm 服務時，Swarm 自動為該服務建立一個 DNS 名稱。其他容器可以透過這個 DNS 名稱來存取該服務。

例如：

http://TomcatService:8080

這樣就不需要手動組態 DNS 或修改組態檔案來讓客戶端知道服務位置。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。