Docker Swarm与Kubernetes对比：容器编排平台的架构权衡

0x00 引言：容器编排的战国时代

在微服务架构盛行的今天，容器编排（Container Orchestration）已成为云原生基础设施的核心。当你的应用从单个Docker容器扩展到数百个容器时，手动管理变得不可能——你需要一个编排系统来自动化部署、扩展、网络配置和故障恢复。

Docker Swarm和Kubernetes是当前最主流的两大容器编排平台。前者以简洁易用著称，后者则提供了企业级的强大功能。作为架构师或DevOps工程师，选择正确的编排平台需要深入理解它们的设计哲学、技术架构和适用场景。

本文将从程序员的视角，对比分析这两个平台的底层实现、API设计、网络模型、存储方案和运维复杂度，帮助你做出符合团队技术栈和业务需求的决策。

0x01 架构对比：简洁vs复杂的设计哲学

1.1 Docker Swarm：内置的极简主义

Docker Swarm是Docker原生的集群管理工具，直接集成在Docker Engine中。

核心组件：

┌─────────────────────────────────────────────┐
│           Docker Swarm 架构                  │
├─────────────────────────────────────────────┤
│  Manager Nodes (Raft 一致性算法)            │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│  │ Manager 1│  │ Manager 2│  │ Manager 3│  │
│  │ (Leader) │  │(Follower)│  │(Follower)│  │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  │
│       │             │             │         │
├───────┴─────────────┴─────────────┴─────────┤
│  Worker Nodes (执行容器任务)                │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│  │ Worker 1 │  │ Worker 2 │  │ Worker N │  │
│  └──────────┘  └──────────┘  └──────────┘  │
└─────────────────────────────────────────────┘

特点：

• 管理节点（Manager）：负责集群管理、任务调度、服务发现
• 工作节点（Worker）：执行容器任务
• 无需额外安装：docker swarm init即可启用
• Raft共识算法：保证管理节点的高可用

1.2 Kubernetes：企业级的复杂生态

Kubernetes（K8s）是Google开源的容器编排系统，架构更为复杂但功能强大。

核心组件：

┌───────────────────────────────────────────────────────┐
│              Kubernetes 控制平面                       │
│  ┌──────────────┐  ┌──────────────┐                  │
│  │  API Server  │  │   etcd 集群  │  (数据存储)      │
│  └──────┬───────┘  └──────────────┘                  │
│         │                                              │
│  ┌──────┴───────┐  ┌──────────────┐  ┌────────────┐ │
│  │  Scheduler   │  │  Controller  │  │Cloud Ctrl  │ │
│  │  (调度器)    │  │   Manager    │  │  Manager   │ │
│  └──────────────┘  └──────────────┘  └────────────┘ │
└─────────────────────────┬─────────────────────────────┘
                          │
┌─────────────────────────┴─────────────────────────────┐
│                  Worker Nodes                          │
│  ┌─────────────────────────────────────────────────┐  │
│  │  Kubelet | Container Runtime | Kube-proxy       │  │
│  │  (节点代理)  (Docker/containerd)  (网络代理)    │  │
│  └─────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────┘

核心组件职责：

• API Server：集群的统一入口，所有操作都通过RESTful API
• etcd：分布式键值存储，保存集群状态
• Scheduler：Pod调度器，根据资源和策略分配节点
• Controller Manager：运行各种控制器（Deployment、ReplicaSet等）
• Kubelet：节点代理，管理Pod生命周期
• Kube-proxy：网络代理，维护Service的iptables规则

1.3 架构复杂度对比

0x02 服务部署：声明式配置的差异

2.1 Docker Swarm：Stack部署

Swarm使用Docker Compose格式的YAML文件，开发者学习成本低。

示例：部署Nginx服务

# docker-stack.yml
version: '3.8'

services:
  nginx:
    image: nginx:latest
    ports:
      - "80:80"
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure
      placement:
        constraints:
          - node.role == worker
    networks:
      - webnet
    volumes:
      - nginx-data:/usr/share/nginx/html

networks:
  webnet:
    driver: overlay

volumes:
  nginx-data:

部署命令：

# 初始化Swarm（仅首次）
docker swarm init

# 部署Stack
docker stack deploy -c docker-stack.yml myapp

# 查看服务
docker service ls
docker service ps myapp_nginx

# 扩容
docker service scale myapp_nginx=5

# 滚动更新
docker service update --image nginx:1.21 myapp_nginx

2.2 Kubernetes：Deployment部署

Kubernetes的YAML配置更加结构化，但也更冗长。

示例：部署Nginx

# nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: "500m"
            memory: "512Mi"
          requests:
            cpu: "250m"
            memory: "256Mi"
        volumeMounts:
        - name: nginx-storage
          mountPath: /usr/share/nginx/html
      volumes:
      - name: nginx-storage
        persistentVolumeClaim:
          claimName: nginx-pvc

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

部署命令：

# 部署
kubectl apply -f nginx-deployment.yaml

# 查看资源
kubectl get deployments
kubectl get pods
kubectl get services

# 扩容
kubectl scale deployment nginx-deployment --replicas=5

# 滚动更新
kubectl set image deployment/nginx-deployment nginx=nginx:1.21

# 回滚
kubectl rollout undo deployment/nginx-deployment

2.3 配置对比分析

Docker Swarm优势：

• 配置更简洁，与docker-compose兼容
• 无需区分Deployment、Service、ConfigMap等多种资源
• 适合从单机Docker迁移的团队

Kubernetes优势：

• 资源类型丰富：Deployment、StatefulSet、DaemonSet、Job等
• 更细粒度的资源管理（CPU/内存限制与请求）
• 强大的标签选择器（Label Selector）
• 声明式API，更适合GitOps

0x03 服务发现与负载均衡

3.1 Docker Swarm：内置DNS + VIP

Swarm使用虚拟IP（VIP）模式实现服务发现和负载均衡。

工作原理：

客户端 → DNS查询(service_name) → VIP(虚拟IP) 
      → IPVS负载均衡 → 后端容器实例

代码示例：

# 创建两个服务
docker service create --name web --replicas 3 nginx
docker service create --name api --replicas 2 myapi:latest

# 在web容器内访问api服务
docker exec <web_container_id> curl http://api:8080
# DNS自动解析api为VIP，IPVS进行负载均衡

特点：

• 自动负载均衡：基于Linux内核的IPVS（IP Virtual Server）
• 零配置：服务名即可访问，无需手动配置

• 模式选择：

  • VIP模式（默认）：单个虚拟IP + 负载均衡
  • DNSRR模式：DNS轮询返回所有容器IP

3.2 Kubernetes：Service抽象层

Kubernetes的Service是独立的资源对象，提供更灵活的配置。

Service类型：

1. ClusterIP（默认）

apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: ClusterIP  # 仅集群内部访问
  selector:
    app: api
  ports:
  - protocol: TCP
    port: 8080        # Service端口
    targetPort: 8080  # Pod端口

工作原理：

Pod → kube-proxy → iptables/IPVS规则 → 目标Pod

2. NodePort（外部访问）

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: NodePort
  selector:
    app: web
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 30080  # 在每个节点上暴露此端口

访问方式：http://<任意节点IP>:30080

3. LoadBalancer（云环境）

apiVersion: v1
kind: Service
metadata:
  name: lb-service
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

云提供商会自动创建外部负载均衡器（如AWS ELB、GCP Load Balancer）。

4. Headless Service（无负载均衡）

apiVersion: v1
kind: Service
metadata:
  name: stateful-service
spec:
  clusterIP: None  # Headless
  selector:
    app: database
  ports:
  - protocol: TCP
    port: 3306

用于StatefulSet，DNS返回所有Pod IP而非VIP。

3.3 Ingress：HTTP路由

Kubernetes提供Ingress资源进行七层路由：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80
  tls:
  - hosts:
    - www.example.com
    secretName: tls-secret

Swarm等价方案：使用Traefik或Nginx作为反向代理。

0x04 网络模型：Overlay vs CNI

4.1 Docker Swarm：Overlay网络

Swarm使用内置的Overlay网络驱动，基于VXLAN封装。

网络架构：

# 创建overlay网络
docker network create -d overlay --attachable mynet

# 查看网络详情
docker network inspect mynet

特点：

• 跨主机通信：自动VXLAN隧道
• 加密支持：--opt encrypted
• 网络隔离：不同overlay网络完全隔离

• 端口发布：

  • Ingress模式（默认）：任意节点均可访问服务
  • Host模式：只在运行容器的节点监听端口

端口发布示例：

# Ingress模式（推荐）
docker service create --name web \
  --publish published=80,target=80,mode=ingress \
  nginx

# Host模式
docker service create --name web \
  --publish published=80,target=80,mode=host \
  --constraint 'node.hostname==node1' \
  nginx

4.2 Kubernetes：CNI插件生态

Kubernetes采用CNI（Container Network Interface）标准，支持多种网络插件。

主流CNI插件对比：

Calico网络策略示例：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-policy
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

这实现了微服务间的细粒度网络隔离。

4.3 网络性能对比

基准测试（iperf3）：

结论：

• Swarm和K8s性能相近，差异主要来自CNI插件选择
• Calico性能略优于Flannel（BGP路由 vs VXLAN封装）
• 实际应用中，网络很少成为瓶颈

0x05 存储管理：Volumes vs PV/PVC

5.1 Docker Swarm：简化的Volume管理

Volume类型：

# 1. 命名卷（Named Volume）
docker volume create mydata
docker service create --mount source=mydata,target=/data nginx

# 2. 绑定挂载（Bind Mount）
docker service create --mount type=bind,source=/host/path,target=/container/path nginx

# 3. tmpfs（内存文件系统）
docker service create --mount type=tmpfs,target=/tmp nginx

限制：

• 无动态供应：需手动创建Volume
• 无存储类（Storage Class）：无法自动选择存储后端
• 跨节点限制：默认Volume不支持跨节点共享（需使用NFS等插件）

NFS Volume示例：

services:
  app:
    image: myapp
    volumes:
      - type: volume
        source: nfs-data
        target: /data
        volume:
          nocopy: true

volumes:
  nfs-data:
    driver: local
    driver_opts:
      type: nfs
      o: addr=192.168.1.100,rw
      device: ":/exported/path"

5.2 Kubernetes：PV/PVC抽象层

Kubernetes的存储模型更加抽象和灵活。

核心概念：

• PersistentVolume (PV)：管理员创建的存储资源
• PersistentVolumeClaim (PVC)：用户的存储请求
• StorageClass：动态供应存储的模板

示例1：静态供应（手动创建PV）

# PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.100
    path: "/exported/path"

---
# PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi

---
# Pod使用PVC
apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app
    image: myapp
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: nfs-pvc

示例2：动态供应（StorageClass）

# StorageClass（使用AWS EBS）
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  iopsPerGB: "10"
  encrypted: "true"
allowVolumeExpansion: true

---
# PVC自动创建PV
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-pvc
spec:
  storageClassName: fast-ssd
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

访问模式：

• ReadWriteOnce (RWO)：单节点读写（如EBS、本地磁盘）
• ReadOnlyMany (ROX)：多节点只读
• ReadWriteMany (RWX)：多节点读写（如NFS、CephFS）

5.3 StatefulSet：有状态应用

Kubernetes的StatefulSet为有状态应用提供稳定的标识和存储：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        ports:
        - containerPort: 3306
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: fast-ssd
      resources:
        requests:
          storage: 50Gi

特点：

• 稳定的网络标识：mysql-0.mysql, mysql-1.mysql, mysql-2.mysql
• 有序部署/删除：按序号顺序操作
• 持久化存储：每个Pod自动绑定专属PVC

Swarm没有等价的StatefulSet，需手动管理。

0x06 配置管理：Secrets与ConfigMaps

6.1 Docker Swarm：Secrets与Configs

Secrets（敏感信息）：

# 创建Secret
echo "mypassword" | docker secret create db_password -

# 或从文件
docker secret create db_password ./password.txt

# 使用Secret
docker service create \
  --name db \
  --secret db_password \
  mysql:8.0

# 在容器内访问：/run/secrets/db_password（只读）

Configs（非敏感配置）：

# 创建Config
docker config create nginx_config ./nginx.conf

# 使用Config
docker service create \
  --name web \
  --config source=nginx_config,target=/etc/nginx/nginx.conf \
  nginx

6.2 Kubernetes：Secrets与ConfigMaps

ConfigMap示例：

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  app.properties: |
    server.port=8080
    log.level=INFO
  database.url: "jdbc:mysql://db:3306/mydb"

---
# 使用ConfigMap
apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
  - name: app
    image: myapp
    env:
    - name: DB_URL
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: database.url
    volumeMounts:
    - name: config
      mountPath: /etc/config
  volumes:
  - name: config
    configMap:
      name: app-config

Secret示例：

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: YWRtaW4=  # base64编码的"admin"
  password: cGFzc3dvcmQ=  # base64编码的"password"

---
apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
  - name: app
    image: myapp
    env:
    - name: DB_USER
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: username
    - name: DB_PASS
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: password

TLS Secret（证书管理）：

kubectl create secret tls tls-secret \
  --cert=path/to/cert.crt \
  --key=path/to/key.key

6.3 对比分析

0x07 调度与资源管理

7.1 Docker Swarm：Placement约束

Swarm使用约束（Constraints）和偏好（Preferences）进行调度：

services:
  db:
    image: postgres
    deploy:
      placement:
        constraints:
          - node.role == manager  # 只在管理节点运行
          - node.labels.disk == ssd  # 需要SSD节点
        preferences:
          - spread: node.labels.datacenter  # 跨数据中心分布

节点标签管理：

# 添加标签
docker node update --label-add disk=ssd node1

# 查看节点
docker node ls
docker node inspect node1

7.2 Kubernetes：丰富的调度策略

Kubernetes提供更细粒度的调度控制。

NodeSelector（简单标签选择）

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  nodeSelector:
    disktype: ssd
    region: us-west
  containers:
  - name: app
    image: myapp

Node Affinity（节点亲和性）

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd
            - nvme
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        preference:
          matchExpressions:
          - key: region
            operator: In
            values:
            - us-west-1
  containers:
  - name: app
    image: myapp

Pod Affinity/Anti-Affinity（Pod亲和/反亲和）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  template:
    spec:
      affinity:
        # Pod反亲和：不同副本分散到不同节点
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: web
            topologyKey: kubernetes.io/hostname
        
        # Pod亲和：靠近缓存服务
        podAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchLabels:
                  app: cache
              topologyKey: kubernetes.io/hostname
      containers:
      - name: web
        image: nginx

Taints与Tolerations（污点与容忍）

# 为节点添加污点（禁止普通Pod调度）
kubectl taint nodes node1 dedicated=gpu:NoSchedule

# Pod容忍污点
apiVersion: v1
kind: Pod
metadata:
  name: gpu-job
spec:
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"
  containers:
  - name: gpu-app
    image: tensorflow/tensorflow:latest-gpu

7.3 资源限制与QoS

Kubernetes资源管理：

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
  - name: app
    image: myapp
    resources:
      requests:  # 最小保证资源
        cpu: "250m"
        memory: "256Mi"
      limits:    # 最大可用资源
        cpu: "1000m"
        memory: "1Gi"

QoS等级：

• Guaranteed：requests == limits（最高优先级）
• Burstable：requests < limits（中等优先级）
• BestEffort：未设置requests/limits（最低优先级）

内存不足时，Kubelet优先驱逐BestEffort Pod。

Swarm资源限制：

services:
  app:
    image: myapp
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 1G
        reservations:
          cpus: '0.25'
          memory: 256M

功能相似但配置更简单。

0x08 高可用与故障恢复

8.1 Docker Swarm：简单但有限

管理节点高可用：

# 推荐奇数个管理节点（3/5/7）
# 容忍故障数 = (N-1)/2

# 提升Worker为Manager
docker node promote worker1

# 降级Manager为Worker
docker node demote manager3

服务自愈：

services:
  web:
    image: nginx
    deploy:
      replicas: 3
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
        window: 120s

Swarm自动重启失败容器，但无健康检查机制。

8.2 Kubernetes：企业级可靠性

控制平面高可用：

┌─────────────────────────────────────────┐
│  多Master高可用架构                      │
│  ┌──────────┐  ┌──────────┐  ┌────────┐│
│  │ Master 1 │  │ Master 2 │  │Master 3││
│  └────┬─────┘  └────┬─────┘  └────┬───┘│
│       └──────────────┼──────────────┘   │
│                      │                  │
│           ┌──────────┴───────────┐      │
│           │  etcd 集群（3/5节点）│      │
│           └──────────────────────┘      │
└─────────────────────────────────────────┘

健康检查：

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
  - name: app
    image: myapp
    livenessProbe:   # 存活探针：失败则重启
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10
    readinessProbe:  # 就绪探针：失败则移出Service
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
    startupProbe:    # 启动探针：慢启动应用
      httpGet:
        path: /startup
        port: 8080
      failureThreshold: 30
      periodSeconds: 10

PodDisruptionBudget（中断预算）：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: app-pdb
spec:
  minAvailable: 2  # 至少保证2个Pod可用
  selector:
    matchLabels:
      app: web

防止节点维护时过度驱逐Pod。

0x09 监控与日志

9.1 Docker Swarm：依赖第三方工具

Swarm本身不提供监控方案，通常配合：

• Prometheus + cAdvisor：容器指标采集
• ELK/EFK Stack：日志聚合
• Portainer：Web管理界面

示例：Prometheus监控

services:
  prometheus:
    image: prom/prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    deploy:
      placement:
        constraints:
          - node.role == manager

9.2 Kubernetes：原生可观测性

指标服务器（Metrics Server）：

# 安装Metrics Server
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# 查看节点资源
kubectl top nodes

# 查看Pod资源
kubectl top pods

Horizontal Pod Autoscaler（HPA）：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: AverageValue
        averageValue: 500Mi

日志聚合：

# 查看Pod日志
kubectl logs pod-name
kubectl logs -f deployment/web  # 实时日志

# EFK Stack（Elasticsearch + Fluentd + Kibana）
kubectl apply -f https://github.com/fluent/fluentd-kubernetes-daemonset/blob/master/fluentd-daemonset-elasticsearch-rbac.yaml

0x10 生产环境选型建议

10.1 选择Docker Swarm的场景

适合：

• 小型团队（<10人）
• 中小规模应用（<100容器）
• 已有Docker经验，希望快速上手
• 资源受限环境（边缘计算、IoT）
• 简单的微服务架构

案例：

场景：创业公司，5人技术团队，3个微服务
部署：3台服务器（2 Manager + 1 Worker）
学习时间：1天上手，1周熟练
运维成本：低

10.2 选择Kubernetes的场景

适合：

• 大型团队与复杂系统
• 需要企业级功能（RBAC、审计、多租户）
• 混合云/多云部署
• 需要丰富的第三方生态（Helm、Operator）
• 有专职DevOps团队

案例：

场景：B轮公司，50人技术团队，20+微服务
部署：AWS EKS托管集群
学习时间：2周上手，3个月熟练
运维成本：中高（托管服务降低成本）

10.3 对比总结表

10.4 迁移路径

从Swarm迁移到K8s：

1. 使用Kompose转换docker-compose.yml

kompose convert -f docker-stack.yml

1. 逐步迁移服务（蓝绿部署）
2. 利用Kubernetes Operator简化管理

混合方案：

• 核心服务使用K8s
• 边缘节点使用Swarm（轻量级）

0x11 总结：没有银弹，只有权衡

容器编排平台的选择没有绝对的对错，只有最适合的选择：

Docker Swarm：

• 优势：简单、快速、资源占用少
• 劣势：功能有限、生态较小、企业级功能不足
• 适合：快速原型、小型项目、学习容器编排

Kubernetes：

• 优势：功能全面、生态丰富、行业标准
• 劣势：复杂、学习曲线陡峭、资源消耗大
• 适合：大规模生产、企业应用、长期投资

最终建议：

• 初创团队：从Swarm开始，快速验证业务
• 成长型公司：评估业务规模，适时迁移到K8s
• 大型企业：直接选择K8s，使用托管服务降低成本

记住：过早优化是万恶之源，但技术债总有偿还的一天。选择能支撑未来2-3年业务增长的方案，而不是追逐最新最酷的技术。

参考资料：

1. Docker Swarm官方文档
2. Kubernetes官方文档
3. Kubernetes设计理念与架构
4. Burns, B., et al. (2018). "Kubernetes: Up and Running" (O'Reilly)
5. CNCF Cloud Native Landscape