编排:Docker Swarm 与 KubernetesCopy Anchor Link

上篇把应用装进了集装箱;这一篇把集装箱装上船。 先讲 Docker Swarm ——配置格式和你刚学过的 Compose 是同一份规格,新增的概念一只手数得过来; 再讲 Kubernetes——Google Borg 的公开后裔,概念多一个量级,但核心思想没变: 描述期望状态,让系统持续对账。 主线例子:同一份工单系统,先在 三管理两工作的 Swarm 上跑起来,再被 Kompose 翻译成 20 个 K8s 配置文件。

1. 顶层全景Copy Anchor Link

  Docker Swarm(K8s 的小弟弟)
    起集群:Multipass 开 VM → swarm init → join-token 逐台加入
      四个新概念:manager/worker、overlay 网络、secrets、deploy 块
        stack 文件 ≈ compose 文件 + deploy/secrets/网络加密
  Kubernetes(Borg 血统的船长)
    三级架构:Cluster(控制平面) → Nodes → Pods
      两类工作负载:Deployment(无状态) / StatefulSet(有状态,数据库)
        Kompose 转换 → Kind 建集群 → kubectl 四板斧
  不变的主线:期望状态 + 持续对账(reconcile)

  图说:台阶从小弟弟到大船,工具复杂度翻倍,思想一行没换。

2. Docker Swarm:小弟弟上场Copy Anchor Link

定位一句话: 「Kubernetes 的小弟弟——提供类似服务,规模更小」; 配置格式与 Compose 遵循同一份规范,用法有些差异¹。

先把集群立起来(Multipass 路线): Swarm 模式内置于 Docker Engine, 但威力要多引擎组网才释放,所以需要多台 VM 当节点。Ubuntu 的 Multipass 一条命令开 VM:multipass launch docker --name mgr1——docker 是预置模板, VM 里 Docker 已装好;每台至少 4 GB 内存。开三台 manager(mgr1/2/3)+ 两台 worker,然后:

docker swarm init                          # 在 mgr1 里初始化
docker swarm join-token manager            # 打印加入命令(带 SWMTKN 令牌)
docker swarm join --token SWMTKN-1-… 172.24.19.65:2377   # 在别的 VM 里逐台执行

²

红字级别的差异:Swarm 不构建镜像。 Compose 能顺手 build,Swarm 只从 registry 拉预构建的镜像——「所以务必先把镜像构建发布好」³。

2.1 四个新概念Copy Anchor Link

① 集群、管理者与工人(clusters, managers, workers): Swarm = 可组网实现编排的 Docker Engine 集群;节点分两种角色—— manager 负责监督与期望状态对账,worker 负责扛容器。 两条最佳实践:manager 上不部署容器(职责分离); manager 数量取奇数、至少 3——分区容错时永远有一边节点多, 多数派显而易见,该谁接管 supervisor 职责没有争议⁴。

② 网络(networks): 真实环境里不能假设大家在一个网——为了安全, 默认互相隔离,谁能访问谁要显式声明;配置里不写网络,组件之间就默认不通。 Swarm 用 overlay 驱动(跨主机虚拟网络),还能开加密:

networks:
  ticketing-net:
    driver: overlay
    driver_opts:
      encrypted: 'yes'

⁵

③ Secrets(机密): compose 时代密码走 env_file;Swarm 给了正经机制—— docker secret create 创建后,配置文件里 secrets: [mariadb_password] 引用, 容器内以文件形式出现在 /run/secrets/<名字>, 环境变量写成 MARIADB_PASSWORD_FILE: /run/secrets/mariadb_password。 密码不再以环境变量的形态躺在进程表里⁶。

④ deploy 块(每个服务的调度策略):

deploy:
  replicas: 1                     # 期望实例数
  placement:
    constraints: ['node.role == worker']   # 只落在工人节点
  update_config:
    parallelism: 1                # 一次更新几个实例
    delay: 10s
    failure_action: rollback      # 更新失败自动回滚
  restart_policy:
    condition: on-failure
    max_attempts: 3
    delay: 5s
    window: 120s

⁷

2.2 七服务的 Swarm 版与 compose 版的差异Copy Anchor Link

同一份全家桶,Swarm 版相对 compose 版只改了四类地方:⁸

后端的 environment 在 Swarm 版里最壮观:十几行环境变量把前面八章的配置 全部显式化(SQLX_OFFLINE=1、MAX_BODY_LIMIT=5、BUCKET_NAME=…), secrets 四个(JWT/mariadb/postgres/smtp)⁹。这个文件是「架构即配置」的 最佳标本:读它等于重读全书。

3. Kubernetes:大船船长Copy Anchor Link

来历: Google 的私有集群管理器 Borg 练出的经验,开源后用 Go 重写, 名字是希腊语「舵手」——像巨型货轮的船长,指挥成百上千的容器¹⁰。

它能干什么(书里列的七项): 服务发现(内建 DNS,按名字找、不管 IP)、 负载均衡、存储编排(对接云存储、按期望状态自动供给)、 自动发布与回滚、自愈(检出故障组件、杀掉、按策略重启)、 secret 与配置管理(声明式配置、secret 可安全轮换不停机)、水平伸缩 (一条命令、预定义逻辑或 UI)¹¹。

3.1 三级架构与四种工作负载Copy Anchor Link

架构骨架: Cluster(被管理的隔离环境,期望状态被持续观察、对账)→ Control Plane(控制集群组件、暴露 API)→ Nodes(跑 Pod 的物理机/VM, 生命周期被托管、可互相分担)→ Pod(容器的包装,最小部署单元; 一 Pod 可含多容器,惯例是一 Pod 一容器)¹²。

工作负载(「一个运行中的应用」的四种种法):

配套设施: Service(把 Pod 暴露给集群外)、StorageClass + PV + PVC (动态供给存储的三件套)、Secrets、Ingress/负载均衡¹³。

3.2 从 Swarm 到 K8s:Kompose 一键翻译Copy Anchor Link

手写 20 个 YAML 太劝退——官方工具 Kompose 干这个: kompose convert -f stack.yml 一把生成全套文件。 概念全都认识:每个组件拆成 deployment + service,密码进 secret 文件, 存储进 PVC 文件。书里给了完整的 20 个文件清单,并点出两个例外:¹⁴

• 存储要手工补:并非所有 Compose 特性都能自动翻译;
• secret 文件里的 base64 不是加密——「这些文件依旧不许进版本库; 更好是动态生成,或最后一刻注入;仓库里只放可注入的样例文件」。 (这句和第 7 章「base64 是编码不是加密」遥相呼应。)

3.3 Kind 建集群、Kubectl 四板斧Copy Anchor Link

本地跑 K8s 三选一:Docker Desktop 勾个框、Kind(为测试 K8s 而生, 节点跑成 Docker 容器)、Minikube(最接近真集群的体验)。 书里选 Kind,集群定义文件长这样:一个 control-plane + 两个 worker, extraPortMappings 把宿主端口透进来,extraMounts 把宿主目录挂给 worker(建卷和读初始化脚本用)¹⁵:

kind create cluster --config=kind-cluster-config.yml --name wslkind
kubectl cluster-info --context kind-wslkind    # 验活:控制平面与 CoreDNS 的地址
kubectl apply -f mariadb-password-secret.yaml  # 逐个应用配置(顺序:基建先行)
kubectl get all        # 全览:pods/services/deployments/replicasets/statefulsets

get all 的输出值得读一次:READY 列是「实际/期望」实例数, STATUS 里 CrashLoopBackOff = 持续失败的雅称; service 列表里能看到 ClusterIP(集群内)与 NodePort(对外)两种类型¹⁶。

排障三板斧(比 get 多两板): kubectl describe <资源>(详情与事件)、 kubectl logs <资源>(日志;容器被杀过加 --previous 看上一轮)。 顺手的贴士:给 kubectl 起别名 k¹⁷。

收尾的实话: 后端通过 kubectl proxy 能访问到(那条长长的 /api/v1/namespaces/default/services/backend:8000/proxy/login); 但前端对路径敏感,受不了这种长 URL——「要配 Ingress controller 或 负载均衡,超出本章范围」¹⁸。

4. 主线例子走一遍:一套系统,两种船Copy Anchor Link

  路线 A(Swarm):
  multipass 开 5 台 VM → mgr1 上 swarm init → join-token 拉进其余 4 台
      → docker secret create × 4 → docker stack deploy -c stack.yml
      → 七服务落在 worker 节点,manager 只管对账
  路线 B(Kubernetes):
  kompose convert 把同一份 stack.yml 翻成 20 个 YAML
      → kind create cluster(1 控制面 + 2 工人)
      → kubectl apply 逐个文件(先基建后应用)
      → kubectl get all:5 个 Pod 全 Running,mariadb/postgres/redis 是 StatefulSet
      → kubectl proxy 打开登录页
  ——两条路线,同一个思想:把期望状态写下来,让系统去对账。

  图说:工具从 stack.yml 换到 20 个 YAML,复杂度涨了,但「读配置即读架构」不变。
  (节点数量、文件数量出自原书示例。)

5. 作者的判断与证据(分开标)Copy Anchor Link

有出处的: Swarm 只拉不构建、奇数 manager 的多数派理由、overlay 默认隔离、 K8s 七特性清单、Kompose 的两处例外、base64≠加密,均为原书原文^3451114。

作者自己的评估:

• 「Swarm 是 K8s 的小弟弟」「K8s 超出本章范围只讲基础」是篇幅取舍;
• 部署顺序「基建先行、后端其次、前端最后」是对依赖拓扑的经验判断¹⁹;
• 12 篇那个 YAGNI 判断块在这里依然生效:多数团队到 Compose/Swarm 就该停。

6. 边界与局限Copy Anchor Link

• 点到为止: Swarm 的滚动更新零停机、K8s 的 Ingress/Helm/Operator,全是 「知道名字、会查文档」的粒度;
• 本地集群的坑: Kind 的端口映射和挂载要手工声明;前端在 proxy 长 URL 下 不能工作,书里如实承认¹⁸;
• 数据库上 K8s: 书里把 MariaDB/Postgres/Redis 都写成 StatefulSet 是对的, 但生产要不要在 K8s 里养数据库,业界至今争论——托管数据库服务往往是更省心的答案。

7. 可带走的Copy Anchor Link

1. Swarm = Compose 同规格 + 四个新词:角色(manger/worker)、网络(overlay+加密)、 secrets(文件挂载)、deploy(调度策略)。
2. manager 取奇数至少 3: 分区时多数派即正统;manager 上不跑容器。
3. Swarm 不构建镜像——先 build、push,再 deploy。
4. K8s 三级架构:Cluster → Node → Pod; Pod 是最小部署单位,惯例一 Pod 一容器。
5. 无状态用 Deployment,有状态用 StatefulSet; 数据库属于后者。
6. Kompose 能翻译 Swarm 配置到 K8s, 但存储要手补、secret 文件不进版本库。
7. kubectl 四板斧: get all 看全景、describe 看事件、logs 看日志 (--previous 看上一轮)、apply 发配置。
8. 期望状态 + 持续对账,是两个编排器共同的心跳; 学会了读配置,就学会了读架构。

8. 原文地图Copy Anchor Link

3.4 Swarm stack 文件的逐服务账(与 Compose 版的 diff 全录)Copy Anchor Link

把第 2.2 节的「四类差异」落到每一行(依据原书 Code listing 9.6):²⁰

MariaDB 服务: environment 里出现 MARIADB_ROOT_PASSWORD_FILE: /run/secrets/mariadb_root_password——密码不再以环境变量明文存在, 而是 _FILE 后缀指向 secret 挂载的文件;secrets: [mariadb_root_password, mariadb_password] 声明两个挂载;deploy 四件套齐活(replicas: 1、 placement 约束到 worker、update_config parallelism 1 / delay 10s / failure_action rollback、restart_policy on-failure / max_attempts 3 / delay 5s / window 120s);网络显式 ticketing-net;端口改写成 published: 3306 / target: 3306 的长格式²¹。

PostgreSQL 服务: 同款四件套 + healthcheck(pg_isready 每秒一探、 超时 5 秒、重试 10 次);初始化脚本 bind 到 /docker-entrypoint-initdb.d (官方镜像首次启动自动执行);POSTGRES_DB: fang——调度库与主库分离的 配置证据²²。

Redis / MailHog 服务: 最简形态——placement 约束 + 网络 + 端口 + Redis 的命名卷(ticketing-redis:/data,RDB 快照落这里); MailHog 两个端口都 published(1025 SMTP + 8025 网页)²³。

backend 服务: 全家桶里配置最壮观的一个——environment 十几行: SERVER_PORT、CLIENT_URL、REDIS_URL: redis://redis/(服务名即主机名)、 MARIADB_(HOST/DATABASE/USER/PASSWORD_FILE)、POSTGRES_、 JWT_SECRET_FILE、SQLX_OFFLINE: 1、MAX_BODY_LIMIT: 5、 BUCKET_NAME: dv-rust-ticketing-s3-bucket、SMTP_*;secrets 四个 (jwt/mariadb/postgres/smtp);deploy 里 parallelism: 2(前后端滚动 更新允许两个实例并行)²⁴。

frontend 服务: 两行 environment(BACKEND_HOST: ticketing-backend、 BACKEND_PORT: 8000)——反代方案的运行期半;依赖后端(deploy 顺序)。 「服务名即 DNS」是 overlay 网络的隐形福利: 容器之间按服务名互找, IP 漂移无所谓²⁵。

3.5 起栈与运维的两条命令(原书流程补全)Copy Anchor Link

  # 在 manager 节点上(node1 装过多台 VM 后任选一):
  docker stack deploy -c stack.yml ticketing     # 应用整个栈
  docker service ls                               # 看服务分布与副本状态

  图说:stack = Swarm 世界的「compose up」;-c 指定文件,ticketing 是栈名。

「先构建发布,再部署」的红字再放一次: Swarm 不构建镜像,只从 registry 拉——所以 CI(第 12 篇的 docker.yml)必须先于 stack deploy 跑完; viktordaroczi/ticketing:latest 这类 tag 就是部署的寻址坐标²⁶。

4.4 K8s 对象文件的完整清单(20 个文件的逻辑分组)Copy Anchor Link

把 Kompose 产物按对象类型归档(原书逐文件列过,此处收拢):²⁷

「生成后要人工过」的两处(原书明写):存储需要手工定义 (「并非所有 Compose 特性都能自动翻译」);secret 文件不入库 (「仓库里只放可注入的样例」)。Kompose 是 kickstart 不是成品—— 「我们仍需 review 生成的文件」²⁸。

4.5 kubectl 排障场景的完整剧本Copy Anchor Link

  症状:某个 Pod 一直 CrashLoopBackOff
      kubectl get all                     # 定位哪个 Pod(READY 列实际/期望)
      kubectl describe pod/<名>            # 事件流:调度失败?探针失败?镜像拉不到?
      kubectl logs <pod>                   # 应用日志(若容器活着)
      kubectl logs <pod> --previous        # 上一轮日志(容器已重启过时必须)
      kubectl get all / describe / logs 三板斧循环,直到定位

  图说:get 定位对象,describe 看事件,logs 看输出;--previous 专查「死过一次」的。

alias 贴士原样收: 「在 .rc 文件里加 alias k="kubectl";PowerShell 用 Set-Alias -Name k -Value kubectl」——排障时省下的每次 7 个字母, 累积起来很可观²⁹。

4.6 K8s 概念与 Swarm 概念的对照表(一鱼两吃)Copy Anchor Link

「编排的谱系」一句话: Docker Compose(单机)→ Swarm(同规格多机、 配置同源)→ Kubernetes(集群的一切皆对象)——复杂度递增,期望状态的 思想一行未改;这正是第 12 篇那句「编排 = 自动化生命周期 + 健康 + 伸缩」的三级注脚³¹。

8. 原文地图补充Copy Anchor Link

9. 可带走的(补两条)Copy Anchor Link

11. Compose 到 Swarm 的四类 diff:密码变 secrets、restart 变 deploy 四件套、 隐式网络变显式 overlay、卷先声明——配置同源,语义升格。
12. kubectl 四板斧: get all 定位、describe 看事件、logs 看输出 (--previous 查死过一次的)、apply 发配置;先基建后应用。