Docker 的網路功能允許容器之間以及容器與外部網路進行通訊。理解 Docker 的網路模式，例如橋接網路、主機網路、無網路和覆寫網路，對於構建和管理容器化應用至關重要。Kubernetes 作為主流的容器協調平台，提供了一套完整的機制來管理和協調容器化的應用程式。深入理解 Kubernetes 的核心元件，例如 Scheduler、Replication Controller 和 Kubelet，對於有效地佈署和管理應用程式至關重要。此外，Service 的概念允許客戶端以穩定的方式存取動態的 Pod，簡化了服務發現和存取。除了 Kubernetes，Apache Mesos 也是一個成熟的容器協調框架，它透過 Marathon 等框架提供更細粒度的資源管理和任務排程能力。瞭解 Mesos 的架構和 Marathon 的使用方法，可以幫助開發者更好地利用叢集資源，並構建更具彈性和可擴充套件性的應用程式。
自訂網路（Custom Networks）詳解
在 Docker 中，自訂網路提供了更靈活和強大的網路管理功能。本文將探討三種最常用的自訂網路驅動程式：自訂橋接網路（custom bridge network）、覆寫網路（overlay network）以及底層網路（underlay network，使用 MACVLAN 驅動程式）。
自訂橋接網路驅動程式
自訂橋接網路驅動程式與預設的 docker0 網路類別似，但提供了更多功能，例如 IP 地址管理（IPAM）和服務發現。它還提供了更大的靈活性。
建立自訂橋接網路
要建立自訂橋接網路，可以使用以下命令：
docker network create --driver bridge pkNetwork
執行後，可以使用 docker network ls 命令驗證新網路是否建立成功。
檢視自訂橋接網路組態
使用 docker network inspect pkNetwork 命令可以檢視該網路的詳細組態，包括使用的驅動程式、IP 地址範圍等。
[
{
"Name": "pkNetwork",
"Id": "33edf6b8d0de1493a2d7dfde6762c1664ce59ae8b38aa7cae0a5726552d8edd9",
"Created": "2017-07-08T21:59:15.821409856Z",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "172.20.0.0/16",
"Gateway": "172.20.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {},
"Options": {},
"Labels": {}
}
]
連線容器到自訂橋接網路
可以透過指定 --network 引數將容器連線到自訂橋接網路，例如：
docker run -d --network pkNetwork --name tomcatPK tomcat
這樣，容器 tomcatPK 就會連線到 pkNetwork 網路中。
連線埠對映（Port Mapping）
在 Docker 中，同一網路中的容器可以互相通訊，但外部存取預設是被防火牆阻擋的。要允許外部存取，需要進行連線埠對映。
範例：將容器連線埠對映到主機連線埠
docker run -d --network pkNetwork -p 8000:80 --name tomcatPK tomcat
這樣，容器的 80 連線埠就會被對映到主機的 8000 連線埠，外部可以透過存取主機的 8000 連線埠來存取容器內的 Tomcat 服務。
底層實作
Docker 引擎會在底層 Linux 系統的 iptables 中新增 NAT（網路位址轉譯）規則，以實作連線埠對映。
覆寫網路驅動程式
覆寫網路驅動程式用於實作跨多主機的容器通訊。它透過將容器網路與底層實體層解耦，並在主機之間建立隧道來實作通訊。
架構範例
建立覆寫網路
可以使用以下命令建立覆寫網路：
docker network create -d overlay myOverlayNetwork
Docker 會自動在各主機上建立必要的設定，以實作跨主機的容器通訊。
Docker Swarm 與多主機網路
Docker Swarm 提供了叢集管理和協調功能，支援跨多主機的容器佈署和通訊。透過覆寫網路驅動程式，Docker Swarm 可以實作多主機之間的容器通訊。
多主機網路架構
當建立一個使用覆寫網路的服務時，Swarm 管理節點會自動將該網路擴充套件到參與該服務的其他節點上。
容器網路與協調管理
在現代化的軟體開發與佈署中，容器技術已成為不可或缺的一環。隨著容器數量的增加，如何有效地管理和協調這些容器，已經成為一個重要的課題。本篇文章將探討容器的網路管理與協調技術。
Docker 網路管理
Docker 提供了多種網路管理的方式，包括橋接網路、主機網路、無網路和覆寫網路等。其中，覆寫網路是一種允許多個 Docker 守護程式（daemon）之間進行通訊的網路模式。
覆寫網路驅動程式
覆寫網路驅動程式允許在多個 Docker 主機之間建立一個邏輯網路，使得容器可以跨主機進行通訊。為了實作這一點，覆寫網路需要一個有效的鍵值儲存服務來儲存必要的資訊，如發現、端點、IP 位址等。支援的鍵值儲存服務包括 Consul、Zookeeper 和 etcd 等。
Macvlan 網路驅動程式
Macvlan 是另一種內建的網路驅動程式，它比其他驅動程式更輕量級和簡單。Macvlan 不使用內建的 Linux 橋接和埠對映，而是直接將容器的介面連線到主機介面（eth0 或子介面）。這樣，每個虛擬介面都有唯一的 MAC 和 IP 位址，使得容器可以直接與外部資源進行通訊，而無需 NAT 和埠對映。
內容解密：
此圖示展示了 Macvlan 網路的架構。Macvlan 網路驅動程式將容器的介面直接連線到主機介面，使得容器可以直接與外部資源進行通訊。每個虛擬介面都有唯一的 MAC 和 IP 位址，這樣可以提高網路的效率和靈活性。
容器協調管理
隨著容器數量的增加，如何有效地管理和協調這些容器，已經成為一個重要的課題。容器協調管理工具可以幫助我們自動化地佈署、管理和擴充套件容器。
Kubernetes
Kubernetes 是一個由 Google 開發的開源容器協調管理工具。它提供了自動化佈署、擴充套件和管理容器的功能。Kubernetes 的主要元件包括：
- kubectl：Kubernetes 的命令列介面，用於與 Kubernetes 叢集進行互動。
- Master Node：Kubernetes 的主要節點，負責協調叢集活動。
- API Server：Kubernetes 的 API 伺服器，負責處理來自客戶端的請求。
- Scheduler：Kubernetes 的排程器，負責將容器排程到叢集中的節點上。
內容解密：
此圖示展示了 Kubernetes 的主要元件。Kubernetes 的 Master Node 負責協調叢集活動，API Server 負責處理來自客戶端的請求，Scheduler 負責將容器排程到叢集中的節點上。Worker Node 中的 Kubelet 和 Kube Proxy 負責管理容器和提供網路服務。
容器協調（Container Orchestration）深入解析
Kubernetes 排程器（Scheduler）的工作原理
Kubernetes 排程器是整個叢集的核心元件之一，其主要職責是根據 Pod 的需求和叢集的資源狀況，將 Pod 分配到最合適的節點（Node）上執行。排程器透過讀取 Pod 的描述檔案，瞭解其資源需求（如 CPU、記憶體）、節點親和性（Node Affinity）等資訊，然後根據自身的演算法，從叢集中篩選出符合條件的節點。
排程過程詳解
資源篩選：排程器首先檢查每個節點的資源可用性，排除那些無法滿足 Pod 資源需求的節點。例如，若某節點目前僅剩 4G 記憶體，而待排程的 Pod 需要至少 8G 記憶體，則該節點將被排除。
最佳節點選擇：在透過初步篩選的節點中，排程器會進一步根據一系列策略選擇最優節點。例如，為了提高應用的可用性，排程器會盡量將同一應用的多個副本分散到不同的節點上，避免單點故障。
Pod 排程：一旦選定最佳節點，排程器便會將 Pod 排程到該節點上執行。
Kubernetes 的架構具有高度的可擴充套件性。若預設的排程器無法滿足特定需求，使用者可以開發自定義排程器以滿足特定的業務需求。
複製控制器（Replication Controller）的作用
複製控制器的主要任務是確保叢集中始終執行著指定數量的 Pod 複本。如果實際執行的 Pod 數量與預期不符，複製控制器會採取相應措施進行調整。例如，當某個節點故障導致其上的 Pod 無法執行時，複製控制器會通知排程器在其他可用節點上啟動新的 Pod，以維持預期的副本數量。
動態調整例項
假設我們最初設定執行 3 個 Tomcat 容器例項。當其中一個節點故障時，複製控制器會檢測到實際執行的 Pod 數量少於預期，並觸發排程器在其他節點上啟動新的 Tomcat Pod，以還原到預期的狀態。同樣，若我們決定將 Tomcat 例項縮減至 2 個，複製控制器也會相應地終止多餘的 Pod，以符合新的預期狀態。
工作節點（Worker Nodes）與 Kubelet
工作節點是實際執行 Pod 的地方。每個工作節點上都執行著一個名為 Kubelet 的代理程式，它負責與主節點（Master Node）通訊，接收有關要在該節點上執行的 Pod 資訊。Kubelet 確保這些 Pod 被正確啟動，並持續監控節點和 Pod 的狀態，將相關資訊回報給主節點的 etcd 資料函式庫。
Kubelet 的關鍵角色
- 執行工作：Kubelet 負責執行主節點分配給工作節點的任務，即啟動和管理 Pod。
- 狀態回報：Kubelet 定期向 etcd 資料函式庫報告節點和 Pod 的狀態，包括健康狀況、資源使用情況等。
Pod 與 Kubernetes 服務（Services）
Kubernetes 中的 Pod 是動態實體，它們會根據需求被建立、銷毀或遷移。為了讓客戶端能夠穩定地存取這些動態的 Pod，Kubernetes 引入了 Service 的概念。Service 提供了一個抽象層，透過為一組相關的 Pod 提供單一的存取入口，使得客戶端無需關心後端 Pod 的具體位置和變化。
例項解析
假設我們有一個 MySQL 資料函式庫服務，透過 Kubernetes 佈署了多個 MySQL Pod。這些 Pod 具有相同的標籤（Label），如 app=MySQL。客戶端可以透過存取 MySQL Service 來連線資料函式庫，而無需知道具體的 Pod IP 地址。Service 提供了穩定的虛擬 IP 和埠，使得客戶端的存取不受後端 Pod 變化的影響。
Apache Mesos 與 Marathon 容器協調系統
Apache Mesos 是一種開源的容器協調框架，已經在大型生產環境中得到驗證。Mesos 類別似於作業系統核心，負責管理叢集中的資源。它採用主從架構（master/slave-based architecture）。Mesos 本身僅管理叢集資源，而執行在 Mesos 之上的框架（frameworks）則負責在叢集中排程任務。目前有多種框架可供選擇，其中最知名的包括 Marathon、Hadoop 和 Chronos。本章節將重點介紹 Marathon。
Mesos 架構
Mesos 的架構由主節點（masters）、代理節點（agents 或 slaves）以及框架組成，如圖 9.3 所示。讓我們來看看構成 Mesos 的主要元件。
Mesos Master
Mesos 主守護程式執行在主節點上。該守護程式負責管理執行在每個叢集節點上的代理守護程式，即主守護程式負責向代理守護程式分配工作（任務）。主守護程式還負責為使用 Mesos 叢集服務（例如 CPU、記憶體、網路、磁碟資源等）的框架提供服務。任意數量的框架都可以執行在同一個 Mesos 叢集上。框架是將任務帶入 Mesos 叢集的實體。框架希望在叢集中執行的任務透過主節點到達代理節點，並在代理節點上執行。
Mesos 主節點的工作是使叢集資源（如 CPU 和記憶體）能夠被等待執行任務的框架分享。它透過以所謂的「offers」形式分享叢集資源來實作這一點。在 Mesos 中，offers 包含了諸如可用於執行任務的 RAM 數量和 CPU 週期數量的詳細資訊。這些 offers 被傳送到已註冊的框架，框架有完全的自由來接受或拒絕它們。
Offers 不過是 Mesos 主節點通知已註冊框架叢集中可用資源的一種方式。例如，一個 offer 可能包含諸如「12G 記憶體、8 核 CPU 週期可用」的資訊。接收到 offer 的框架會檢查收到的 offer 和手頭待執行的任務。如果任務可以使用收到的 offer 執行，則框架接受它；否則，offer 被拒絕。
由於任意數量的框架都可以從同一個 Mesos 叢集消費資源，因此會出現諸如哪個框架獲得叢集資源的多少百分比等挑戰。Mesos 透過使資源分配完全可組態來優雅地處理這些挑戰，透過定義策略可以實作這一點。叢集管理員根據組織優先順序和/或在 Mesos 叢集中執行的任務的重要程度來定義分配給特定框架的資源量。
Agents（代理節點）
代理節點是實際執行任務的工作節點。每個工作節點上都執行著一個代理守護程式。該守護程式負責收集統計資訊並將其報告給 Mesos 主節點。
假設您的機器有 8GB RAM 和 4 核 CPU 週期可用。這些資訊將從代理節點傳送到 Mesos 主節點，主節點再將 offers 上傳到已註冊的框架。框架請求的任務實際上是在這些工作節點上執行的。代理節點從 Mesos 主節點取得工作（要執行的任務）。一旦接收到任務，它們就在執行器（executor）內啟動任務。
執行器簡單來說就是一個能夠執行 shell 命令或 Docker 容器等程式的容器或程式。Mesos 提供了簡單的執行器，可以執行 shell 命令和 Docker 容器；然而，大多數框架（如 Marathon）都帶有自己的執行器，提供比預設 Mesos 執行器更多的功能。
Frameworks（框架）
框架是叢集資源的消費者。如前所述，Mesos 本身僅管理叢集資源；而是在叢集中執行任務的是框架。框架有兩個主要元件：排程器（scheduler），它向 Mesos 主節點註冊，並負責檢查傳入的 offer 並決定是否接受或拒絕它；以及執行器（executor），它實際上在代理節點上執行任務。如果框架選擇不提供自己的執行器，則可以使用 Mesos 提供的預設執行器。
範例：Marathon Framework
假設我們希望佈署三個目錄微服務例項。下面是如何描述這個需求並將其交給 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 描述了在叢集中執行三個目錄微服務例項的需求。其中：
"id"指定了服務的 ID 為catalog-svc。"cpus"和"mem"分別指定了每個例項所需的 CPU 資源和記憶體資源。"instances"指定了需要啟動的例項數量。"container"部分描述了容器型別和相關組態。在此範例中，使用的是 Docker 容器。"docker"部分指定了使用的 Docker 映象、網路模式以及埠對映組態。
這段 JSON 組態展示瞭如何使用 Marathon 在 Mesos 叢集中佈署和管理 Docker 容器化的應用程式。透過這種方式，可以實作對應用程式的高效管理和擴充套件。
圖示說明
此圖示展示了 Mesos 的基本架構，包括 Mesos Master、Agents、Frameworks 等主要元件之間的關係。
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title Docker Kubernetes Mesos 容器網路與協調
package "Kubernetes Cluster" {
package "Control Plane" {
component [API Server] as api
component [Controller Manager] as cm
component [Scheduler] as sched
database [etcd] as etcd
}
package "Worker Nodes" {
component [Kubelet] as kubelet
component [Kube-proxy] as proxy
package "Pods" {
component [Container 1] as c1
component [Container 2] as c2
}
}
}
api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2
note right of api
核心 API 入口
所有操作經由此處
end note
@enduml
圖示內容解密：
- Mesos Master 負責管理 Agents 和提供資源給 Frameworks。
- Agents 負責執行來自 Frameworks 的任務。
- Frameworks 負責向 Mesos Master 排程任務，並決定是否接受 Mesos Master 提供的資源。
這張圖清晰地展示了 Mesos 的核心架構和各元件之間的互動關係，有助於更好地理解 Mesos 如何管理和協調叢集資源和任務執行。