Docker Swarm vs Kubernetes：中小企业该选谁？看完这篇不再纠结

第一章：Docker Swarm 集群管理入门

Docker Swarm 是 Docker 原生的集群管理和编排工具，允许用户将多个 Docker 主机组成一个虚拟的“Swarm”集群，统一调度和管理容器化应用。通过简单的命令即可实现服务的部署、扩展与更新，适用于中小规模的容器编排场景。

初始化 Swarm 集群

在主节点上执行以下命令以初始化 Swarm 集群，并指定当前节点为管理节点：

# 初始化 Swarm，指定监听地址和端口
docker swarm init --advertise-addr 192.168.1.10

# 输出示例会提供加入工作节点的命令
# docker swarm join --token <token> 192.168.1.10:2377

该命令会启动 Swarm 模式，并生成一个用于添加工作节点的安全令牌。

添加工作节点

在其他 Docker 主机上运行由 swarm init 输出的 join 命令，即可将其注册为工作节点。节点加入后，服务任务将由管理节点自动分配。

部署服务

使用 docker service 命令可在集群中部署可扩展的服务。例如，部署一个 Nginx 服务并暴露端口：

docker service create \
  --name my-nginx \
  --publish published=80,target=80 \
  --replicas 3 \
  nginx

上述命令创建了一个名为 my-nginx 的服务，副本数为 3，通过负载均衡对外提供 Web 服务。

查看集群状态

可通过以下命令查看节点和服务状态：

• docker node ls：列出所有集群节点
• docker service ls：列出所有服务
• docker service ps my-nginx：查看指定服务的任务运行情况

命令	作用
docker swarm init	初始化管理节点
docker swarm join	加入工作节点
docker service create	创建可扩展服务

graph TD A[Init Swarm] --> B[Add Worker Nodes] B --> C[Deploy Service] C --> D[Scale Replicas] D --> E[Monitor via CLI]

第二章：Docker Swarm 核心概念与架构解析

2.1 Swarm 模式下的节点角色与集群初始化原理

在 Docker Swarm 模式中，集群由两类核心节点构成：管理节点（Manager）和工作节点（Worker）。管理节点负责集群状态维护、任务调度和API接入，而工作节点仅执行分配的容器任务。

节点角色对比

角色	职责	容错能力
Manager	调度服务、维护集群状态	支持高可用（奇数节点推荐）
Worker	运行容器化任务	无决策权，可横向扩展

集群初始化命令示例

docker swarm init --advertise-addr 192.168.1.100

该命令在首台节点上创建 Swarm 集群，--advertise-addr 指定管理节点对外公布地址，确保其他节点可通信。执行后自动生成加入令牌，用于安全接入新节点。

2.2 服务（Service）模型与任务调度机制详解

在分布式系统中，服务模型定义了组件间的交互方式，而任务调度机制则决定了资源的分配效率与执行顺序。

服务模型核心架构

典型的服务模型基于微服务或Serverless架构，通过API网关暴露接口。每个服务实例注册至服务发现中心（如Consul或Eureka），实现动态负载均衡。

任务调度策略

主流调度器（如Kubernetes Scheduler）采用两级调度机制：

• 预选（Predicates）：过滤不满足资源约束的节点
• 优选（Priorities）：根据权重评分选择最优节点

// 示例：Kubernetes Pod调度扩展点
func (pl *ExamplePlugin) Filter(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeInfo *node.Info) *framework.Status {
    if nodeInfo.Allocatable.MilliCPU < pod.Spec.Containers[0].Resources.Requests.Cpu().MilliValue() {
        return framework.NewStatus(framework.Unschedulable, "insufficient CPU")
    }
    return nil
}

该代码段实现自定义调度插件的Filter方法，检查节点CPU资源是否满足Pod请求，若不足则返回不可调度状态。

2.3 覆盖网络与内置服务发现实践配置

在微服务架构中，覆盖网络（Overlay Network）为容器间通信提供了隔离且安全的虚拟网络层。通过 Docker Swarm 或 Kubernetes 等平台可构建跨主机的覆盖网络，实现服务间的自动发现与负载均衡。

创建覆盖网络示例

docker network create --driver overlay --attachable my-overlay-net

该命令创建一个名为 my-overlay-net 的覆盖网络，--driver overlay 指定使用覆盖驱动，--attachable 允许独立容器接入。

服务发现机制

容器在同一个覆盖网络中可通过服务名称自动解析 IP 地址。例如，在 Compose 文件中定义服务：

version: '3.8'
services:
  web:
    image: nginx
    networks:
      - my-overlay-net
  api:
    image: express-app
    networks:
      - my-overlay-net
networks:
  my-overlay-net:
    external: true

此时 web 服务可通过 http://api:3000 直接访问，DNS 内部自动完成服务名到 IP 的映射。

• 覆盖网络基于 VXLAN 技术封装流量
• 内置 DNS 服务支持实时服务发现
• 加密通信可通过 --opt encrypted 启用

2.4 副本与全局模式部署策略对比分析

数据同步机制

副本模式通过主从复制实现数据冗余，适用于低延迟读操作。全局模式则依赖分布式共识算法（如Raft）保证跨区域一致性。

// 示例：Raft选举超时配置
heartbeatTimeout := 150 * time.Millisecond
electionTimeout := 300 * time.Millisecond

上述参数控制节点心跳与选举行为，较小值可加快故障转移，但可能增加网络压力。

部署特性对比

维度	副本模式	全局模式
一致性	最终一致	强一致
延迟	较低	较高
容灾能力	区域级	全局级

适用场景

• 副本模式适合读多写少、允许短暂不一致的业务场景
• 全局模式适用于金融交易等对数据一致性要求极高的系统

2.5 集群容错与自动恢复机制实战演示

在分布式系统中，集群容错与自动恢复能力是保障高可用的核心。当某个节点发生故障时，系统需自动感知并重新分配任务。

服务注册与健康检查配置

通过 Consul 实现节点注册与健康检测：

{
  "service": {
    "name": "user-service",
    "address": "192.168.1.10",
    "port": 8080,
    "check": {
      "http": "http://192.168.1.10:8080/health",
      "interval": "10s"
    }
  }
}

该配置每10秒发起一次健康检查，若连续失败三次，Consul 将其从服务列表中剔除。

自动故障转移流程

• 监控系统检测到主节点失联
• 选举算法（如Raft）触发新主节点选举
• 数据副本同步至新主节点
• 流量自动切换，客户端无感知

图示：故障检测 → 节点隔离 → 主节点选举 → 流量重定向

第三章：Swarm 集群搭建与运维操作

3.1 多主机环境下 Swarm 集群的快速部署

在多主机环境中，Docker Swarm 提供了简单高效的容器编排能力。通过初始化管理节点并加入工作节点，可快速构建集群。

初始化管理节点

在主服务器执行以下命令：

docker swarm init --advertise-addr <MANAGER-IP>

该命令启动 Swarm 模式，--advertise-addr 指定管理节点对外暴露的 IP 地址，确保其他节点可连接。

添加工作节点

执行 swarm init 后，终端输出包含 join 命令的令牌。在工作节点运行：

docker swarm join --token <TOKEN> <MANAGER-IP>:2377

此命令将当前主机注册为工作节点，实现集群拓扑构建。

节点角色验证

使用以下命令查看集群节点状态：

• docker node ls：列出所有节点及其角色（Manager/Worker）
• 确保各节点状态为 Ready，且角色分配正确

3.2 节点加入与退出的安全流程管理

在分布式系统中，节点的动态加入与退出必须经过严格的身份认证与状态同步机制，以防止非法接入和数据不一致。

安全准入控制

新节点加入前需通过TLS双向认证，并向集群注册中心提交数字证书。只有验证通过后，才允许参与数据同步。

节点退出处理

主动退出节点需发送注销请求，集群将触发重新分片策略。以下为退出流程的核心逻辑：

// NotifyClusterOfLeave 通知集群本节点即将退出
func (n *Node) NotifyClusterOfLeave() error {
    req, _ := http.NewRequest("POST", "https://cluster-control/leave", nil)
    req.Header.Set("Authorization", "Bearer "+n.Token)
    resp, err := n.Client.Do(req)
    if err != nil || resp.StatusCode != http.StatusOK {
        return fmt.Errorf("failed to leave securely")
    }
    return nil // 安全退出确认
}

上述代码通过HTTPS携带JWT令牌发起退出请求，确保操作可追溯且防篡改。集群控制面接收到请求后，会更新成员列表并启动负载再平衡。

3.3 服务更新、回滚与滚动升级实操

在 Kubernetes 中，服务的平滑更新依赖于 Deployment 的声明式更新机制。通过修改 Pod 模板字段，触发滚动更新策略。

执行滚动更新

使用以下命令更新镜像版本：

kubectl set image deployment/my-app my-container=nginx:1.21

该命令将 Deployment 管理的容器镜像从旧版本切换至 nginx:1.21，Kubernetes 自动按设定的策略逐批替换 Pod。

更新策略配置

Deployment 中的 strategy 字段定义更新行为：

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

maxSurge 控制超出期望副本数的上限，maxUnavailable 指定允许不可用的最大副本数，确保服务高可用。

版本回滚操作

若新版本异常，可快速回滚至上一版本：

kubectl rollout undo deployment/my-app

也可指定特定历史版本进行恢复，保障业务稳定性。

第四章：服务管理与高可用性保障

4.1 使用 Docker Stack 编排复杂应用栈

Docker Stack 是 Docker 原生支持的集群编排工具，适用于在 Swarm 模式下部署多服务应用栈。通过一个声明式的 Compose 格式文件，可定义服务依赖、网络和卷等资源。

部署流程概述

• 编写 docker-compose.yml 文件描述服务拓扑
• 使用 docker stack deploy 命令部署应用栈
• Swarm 自动调度任务并维护期望状态

典型配置示例

version: '3.8'
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    deploy:
      replicas: 3
  db:
    image: postgres:13
    environment:
      POSTGRES_PASSWORD: example

该配置定义了一个包含 Nginx 和 PostgreSQL 的应用栈。web 服务暴露 80 端口并运行 3 个副本，db 服务通过环境变量设置初始密码。deploy 指令仅在 Swarm 模式下生效，确保高可用性。

4.2 配置管理与敏感信息加密（Secrets）实战

在现代云原生应用部署中，配置与密钥的管理必须与代码分离，确保安全性与灵活性。Kubernetes 提供了 `Secret` 资源对象，用于存储敏感数据，如数据库密码、API 密钥等。

创建加密的 Secrets

使用 Base64 编码将敏感信息注入 Secret：

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: YWRtaW4=     # "admin"
  password: MWYyZDFlMmU2N2Rm    # "secret123"

上述 YAML 中，`data` 字段要求值为 Base64 编码。可通过命令 `echo -n "admin" | base64` 生成。Kubernetes 在 Pod 启动时自动解码并挂载为环境变量或文件。

Pod 中安全引用 Secret

• 作为环境变量注入，避免硬编码
• 以卷形式挂载，实现动态读取

通过 RBAC 控制 Secret 访问权限，并结合 Hashicorp Vault 等外部系统实现动态密钥分发，提升整体安全层级。

4.3 存储卷与持久化数据解决方案集成

在 Kubernetes 中，存储卷（Volume）是实现容器间数据共享和持久化的关键机制。通过将存储抽象为资源对象，K8s 支持多种后端存储系统无缝接入。

持久化存储卷类型对比

类型	适用场景	访问模式
PersistentVolume (PV)	集群级存储资源	ReadWriteOnce, ReadOnlyMany, ReadWriteMany
PersistentVolumeClaim (PVC)	用户对存储的请求	按需绑定 PV

声明式持久化配置示例

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

该配置定义了一个请求 10GB 存储的 PVC，仅允许单节点读写挂载。Kubernetes 将自动绑定符合条件的 PV，实现存储解耦。 动态供给可通过 StorageClass 实现，结合云厂商插件自动创建底层存储实例，提升部署效率。

4.4 监控、日志收集与健康检查机制配置

集成Prometheus监控指标

为保障服务可观测性，需在应用中暴露符合Prometheus规范的metrics端点。使用Go语言示例：

http.Handle("/metrics", promhttp.Handler())
log.Fatal(http.ListenAndServe(":8080", nil))

该代码注册/metrics路径，由Prometheus定期抓取。promhttp.Handler()自动收集Go运行时指标及自定义计数器。

统一日志格式与采集

采用JSON格式输出结构化日志，便于ELK栈解析：

• 包含字段：timestamp、level、service_name、trace_id
• 通过Filebeat收集并转发至Logstash
• 错误日志触发告警规则

健康检查接口设计

提供/healthz端点供Kubernetes探针调用：

状态码	含义
200	服务正常
500	依赖异常

第五章：总结与展望

云原生架构的持续演进

现代企业正加速向云原生转型，Kubernetes 已成为容器编排的事实标准。在实际部署中，通过 Helm 管理复杂应用显著提升了交付效率。例如，某金融客户使用 Helm Chart 统一管理微服务部署，将发布周期从两周缩短至两天。

// 示例：Helm 钩子用于数据库迁移
apiVersion: batch/v1
kind: Job
metadata:
  name: migrate-db
  annotations:
    "helm.sh/hook": pre-upgrade
    "helm.sh/hook-weight": "-5"
spec:
  template:
    spec:
      containers:
      - name: migrate
        image: db-migrate:latest

可观测性体系的构建实践

生产环境稳定性依赖于完善的监控体系。以下为某电商平台采用的核心组件组合：

功能	工具	用途
日志收集	Fluentd	聚合容器日志
指标监控	Prometheus	采集服务性能数据
链路追踪	Jaeger	定位跨服务延迟

未来技术融合方向

• Service Mesh 与安全策略深度集成，实现零信任网络控制
• AIOps 开始应用于异常检测，自动识别流量突增模式
• 边缘计算场景下，轻量级 K8s 发行版（如 K3s）部署规模持续扩大