容器编排 on 吾爱主机

Docker Compose 5.3 原生 pre_start 初始化容器实战：让本地编排更接近 Kubernetes Init Container

Wed, 08 Jul 2026 09:08:00 +0800

Docker Compose 在 2026 年 7 月连续发布了 v5.3.0 和 v5.3.1。其中 v5.3.1 主要是内部流程与依赖更新；真正值得一线工程团队关注的变化，是 v5.3.0 引入了对 Compose Spec pre_start 生命周期钩子的原生支持。官方发布说明明确写到：这个版本 introduces native support for init containers；对应合并的 PR 说明也进一步确认，pre_start 会以临时容器形式在服务容器启动前运行，非零退出码会阻止服务启动。

这意味着，过去很多只能写进镜像入口脚本、Makefile 或 CI/CD 脚本里的初始化动作，现在可以被声明在 compose.yaml 中：等待依赖、初始化共享卷、生成配置、执行轻量迁移、预热本地开发数据，都可以变成 Compose 编排的一部分。对于把 Docker Compose 当作本地开发、集成测试和小规模部署工具的团队来说，这次更新比普通补丁版本更有工程价值。

版本与来源核验

本文基于多源官方资料整理，而不是复制单篇网文：

版本	发布时间	关键信息
Docker Compose `v5.3.0`	2026-07-02	引入原生 init containers / `pre_start` 支持，包含 OCI token transport、`run` 事件作用域等修复
Docker Compose `v5.3.1`	2026-07-07	最新补丁版本，主要包含 CI hardening、依赖升级与 Docker CLI `29.6.1` 等依赖更新
Compose Spec	持续维护	定义 `pre_start`：在服务容器启动前按顺序运行初始化容器，全部退出 `0` 后才启动服务

因此，生产或团队模板中如果准备试用 pre_start，建议直接升级到 v5.3.1 或后续更高版本，而不是停留在刚发布的 v5.3.0。

pre_start 到底解决什么问题

传统 Compose 项目里，初始化逻辑通常散落在几个位置：

写进业务镜像的 entrypoint.sh；
在 docker compose up 前手动执行脚本；
在 CI 中先跑 docker compose run --rm migrate；
使用 depends_on.condition: service_healthy 等待依赖服务健康后再启动主服务。

这些做法都能工作，但都有缺点。入口脚本会把“容器启动”与“环境初始化”强耦合，脚本失败时排查困难；CI 前置命令容易和开发者本地流程不一致；depends_on 更偏向依赖顺序和健康检查，并不负责在主容器启动前执行一次性任务。

pre_start 的定位更像 Kubernetes 的 Init Container：它不是在主容器内部执行命令，而是创建一个短生命周期的临时容器。这个临时容器可以使用自己的镜像，也可以默认继承服务镜像；它与服务加入相同网络，并共享服务声明的卷挂载。只有这些步骤按声明顺序全部成功退出后，服务容器才会真正启动。

一个最小可用示例

假设 Web 服务启动前需要在共享卷里生成配置文件，可以写成：

services:
 web:
 image: nginx:alpine
 volumes:
 - web-conf:/etc/nginx/conf.d
 pre_start:
 - image: alpine
 command: >-
 sh -c 'cat > /etc/nginx/conf.d/default.conf <<EOF
 server { listen 80; location / { return 200 "ok\\n"; } }
 EOF'
 ports:
 - "8080:80"

volumes:
 web-conf:

这里的关键点是：pre_start 容器先把配置写入 web-conf，主服务随后挂载同一个卷并读取配置。如果初始化命令退出非零，web 不会继续启动，这比“主容器启动后才发现配置缺失”更早暴露问题。

如果初始化逻辑需要和业务镜像使用同一套工具链，也可以省略 image，让 hook 默认使用父服务镜像：

services:
 api:
 build: .
 command: ./start-api
 volumes:
 - app-data:/app/data
 pre_start:
 - command: ./bin/prepare-runtime-cache --output /app/data/cache.json

volumes:
 app-data:

官方 PR 中的端到端测试也覆盖了这类场景：当 hook 未指定镜像时，会回退到服务自身构建出的镜像。

运行语义：不要把它当成万能任务调度器

从 Docker Compose PR 的说明看，当前实现有几个重要边界：

pre_start 当前按“每个服务一次”运行，而不是每个副本都运行；
仅当没有副本已经在运行时触发，例如首次 up、--force-recreate 或 Compose 规范发生变化；
普通 scale up 不会重新触发已有服务的 pre_start；
per_replica: true 在当前 Compose 实现中会被提前拒绝；
hook 非零退出会阻止服务以及依赖它的服务继续启动；
多个 pre_start 步骤会按声明顺序执行。

这几个规则决定了它适合“服务级别的一次性准备”，不适合做每个副本都必须执行的注册、预热或本地临时目录初始化。如果你的任务必须随副本扩容逐个执行，现阶段仍应使用应用自身启动逻辑、编排平台能力，或等待 Compose 后续支持完整的 per_replica 语义。

适合落地的场景

1. 本地开发数据库初始化

在开发环境中，很多团队会把数据库、缓存、对象存储模拟器和应用服务放进同一个 Compose 项目。pre_start 可以用于生成测试数据、写入默认配置，或者确认迁移脚本已经运行。

services:
 app:
 build: .
 depends_on:
 db:
 condition: service_healthy
 pre_start:
 - image: alpine
 command: sh -c 'echo "seed-ready" > /shared/state.txt'
 environment:
 - APP_ENV=local
 volumes:
 - app-shared:/shared

 db:
 image: postgres:17
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U postgres"]
 interval: 5s
 timeout: 3s
 retries: 20

volumes:
 app-shared:

这里仍然建议保留数据库健康检查。pre_start 负责“服务启动前做什么”，depends_on 和 healthcheck 负责“依赖是否已经可用”，二者不是替代关系。

2. 集成测试中的夹具准备

CI 里经常需要启动一组服务进行端到端测试。把夹具准备放在 pre_start 中，可以让开发者本地执行和 CI 执行保持一致：

docker compose up --build --abort-on-container-exit

如果初始化失败，Compose 会在服务启动阶段就返回错误，日志也更集中。相比在 CI YAML 中堆多段 shell，Compose 文件成为更清晰的环境说明书。

3. 共享卷中的配置或证书生成

对一些内部工具、反向代理或 demo 环境，可以用 pre_start 生成临时证书、模板配置、静态资源索引等，再让主服务读取。注意这只适合非敏感或临时材料；生产密钥仍应交给 Secret 管理系统，不要把长期敏感信息写进普通卷。

升级与验证建议

升级前先确认当前版本：

docker compose version

升级后重点检查三类流程：

首次 docker compose up：确认 hook 顺序、日志和失败行为；
再次 docker compose up：确认已运行服务不会无意义重复执行初始化；
docker compose up --force-recreate 或修改 compose.yaml：确认变更后会按预期重新执行。

还可以专门构造一个失败用例：

services:
 demo:
 image: alpine
 command: sleep 300
 pre_start:
 - image: alpine
 command: sh -c 'exit 17'

执行 docker compose up demo 后，预期主服务不会启动。这类“失败路径测试”比只验证成功路径更重要，因为 pre_start 的核心价值之一正是把启动前置条件变成可失败、可观测的编排步骤。

注意事项

不要把耗时很长、需要重试队列或人工审批的任务放进 pre_start，否则会阻塞服务启动；
不要假设 scale up 会为新增副本重新执行初始化；
不要把它当作数据库迁移的唯一保护，生产迁移仍应有幂等、锁和回滚策略；
对共享卷写入要保持幂等，避免 --force-recreate 后重复生成脏数据；
团队模板中应固定最低 Compose 版本，否则旧环境会因为不认识字段而失败。

总结

Docker Compose v5.3.x 的 pre_start 支持，让 Compose 在本地编排和集成测试场景中补上了一个长期缺口：服务启动前的初始化任务终于可以以声明式方式进入 compose.yaml。它不是 Kubernetes 的完整替代品，也不是通用任务调度系统，但非常适合处理服务级别、短生命周期、可幂等的一次性准备动作。

对工程团队来说，推荐的落地路径是：先升级到 v5.3.1 或更高版本，在非生产 Compose 项目中选择一个低风险初始化步骤试点；随后把成功路径、失败路径、重复 up、--force-recreate 和扩容行为都纳入验证。只要边界理解清楚，pre_start 会让 Compose 项目更可读、更一致，也更接近现代容器编排的生命周期模型。

参考资料

Docker Compose GitHub Release：v5.3.1（2026-07-07），https://github.com/docker/compose/releases/tag/v5.3.1
Docker Compose GitHub Release：v5.3.0（2026-07-02），https://github.com/docker/compose/releases/tag/v5.3.0
Docker Compose PR #13862：Pre start init containers，https://github.com/docker/compose/pull/13862
Compose Specification：pre_start lifecycle hook，https://github.com/compose-spec/compose-spec/blob/main/spec.md#pre_start
Docker Docs：Compose release notes，https://docs.docker.com/compose/releases/release-notes/

Kubernetes (K8s) 完全指南：架构、核心概念与实战命令

Thu, 25 Jun 2026 16:30:00 +0000

前言

Kubernetes（简称 K8s）是 Google 开源的容器编排平台，已成为云原生领域的事实标准。当前最新版本为 v1.36（2026 年发布）。它能自动化容器化应用的部署、扩缩容和管理。无论是微服务架构、CI/CD 流水线，还是混合云部署，K8s 都是核心基础设施。

1. 架构概述

1.1 整体架构

┌─────────────────────────────────────────────────────┐
│ Control Plane │
│ ┌──────────┐ ┌──────────┐ ┌────────┐ ┌──────────┐ │
│ │ API │ │Scheduler │ │Controller│ │ etcd │ │
│ │ Server │ │ │ │ Manager │ │ │ │
│ └──────────┘ └──────────┘ └────────┘ └──────────┘ │
└─────────────────────────────────────────────────────┘
 │
 ┌───────────┼───────────┐
 ▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Worker 1 │ │ Worker 2 │ │ Worker 3 │
│ ┌──────────┐ │ │ ┌──────────┐ │ │ ┌──────────┐ │
│ │ kubelet │ │ │ │ kubelet │ │ │ │ kubelet │ │
│ ├──────────┤ │ │ ├──────────┤ │ │ ├──────────┤ │
│ │kube-proxy│ │ │ │kube-proxy│ │ │ │kube-proxy│ │
│ ├──────────┤ │ │ ├──────────┤ │ │ ├──────────┤ │
│ │Container │ │ │ │Container │ │ │ │Container │ │
│ │ Runtime │ │ │ │ Runtime │ │ │ │ Runtime │ │
│ └──────────┘ │ │ └──────────┘ │ │ └──────────┘ │
└──────────────┘ └──────────────┘ └──────────────┘

1.2 Control Plane 组件

组件	作用
API Server	集群的统一入口，所有操作通过 REST API 进行
etcd	分布式键值存储，保存集群的所有状态数据
Scheduler	监听未调度的 Pod，根据资源/亲和性等分配到合适的节点
Controller Manager	运行各种控制器（Deployment、ReplicaSet、Node 等），确保实际状态与期望状态一致

1.3 Worker Node 组件

组件	作用
kubelet	每个节点上的代理，管理 Pod 生命周期，汇报节点状态
kube-proxy	网络代理，实现 Service 的负载均衡和网络规则
Container Runtime	容器运行时（containerd、CRI-O 等）

2. 核心概念

2.1 Pod

Pod 是 K8s 最小的部署单元，包含一个或多个容器。

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
 name: my-pod
 labels:
 app: myapp
 version: v1
spec:
 containers:
 - name: nginx
 image: nginx:1.25
 ports:
 - containerPort: 80
 resources:
 requests:
 cpu: "100m"
 memory: "128Mi"
 limits:
 cpu: "500m"
 memory: "256Mi"
 livenessProbe:
 httpGet:
 path: /healthz
 port: 80
 initialDelaySeconds: 10
 periodSeconds: 5
 readinessProbe:
 httpGet:
 path: /ready
 port: 80
 initialDelaySeconds: 5
 periodSeconds: 3
 - name: sidecar
 image: busybox
 command: ["sh", "-c", "while true; do echo hello; sleep 10; done"]

2.2 Deployment

Deployment 管理 ReplicaSet，实现应用的声明式更新。

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: myapp
 namespace: default
spec:
 replicas: 3
 selector:
 matchLabels:
 app: myapp
 strategy:
 type: RollingUpdate
 rollingUpdate:
 maxSurge: 1 # 滚动更新时最多多出 1 个 Pod
 maxUnavailable: 0 # 更新时不允许不可用
 template:
 metadata:
 labels:
 app: myapp
 spec:
 containers:
 - name: myapp
 image: myapp:1.0
 ports:
 - containerPort: 8080
 env:
 - name: DB_HOST
 valueFrom:
 configMapKeyRef:
 name: myconfig
 key: db_host
 - name: DB_PASSWORD
 valueFrom:
 secretKeyRef:
 name: mysecret
 key: db_password
 resources:
 requests:
 cpu: "250m"
 memory: "256Mi"
 limits:
 cpu: "1"
 memory: "512Mi"

2.3 Service

Service 为 Pod 提供稳定的网络访问入口。

# ClusterIP（集群内部访问）
apiVersion: v1
kind: Service
metadata:
 name: myapp-svc
spec:
 type: ClusterIP
 selector:
 app: myapp
 ports:
 - port: 80
 targetPort: 8080
 protocol: TCP

---
# NodePort（外部通过节点端口访问）
apiVersion: v1
kind: Service
metadata:
 name: myapp-nodeport
spec:
 type: NodePort
 selector:
 app: myapp
 ports:
 - port: 80
 targetPort: 8080
 nodePort: 30080 # 外部通过 <NodeIP>:30080 访问

---
# LoadBalancer（云厂商负载均衡）
apiVersion: v1
kind: Service
metadata:
 name: myapp-lb
spec:
 type: LoadBalancer
 selector:
 app: myapp
 ports:
 - port: 80
 targetPort: 8080

2.4 Ingress

Ingress 管理外部对集群服务的 HTTP/HTTPS 访问。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: myapp-ingress
 annotations:
 nginx.ingress.kubernetes.io/rewrite-target: /
 cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
 ingressClassName: nginx
 tls:
 - hosts:
 - app.example.com
 secretName: app-tls
 rules:
 - host: app.example.com
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: myapp-svc
 port:
 number: 80
 - path: /api
 pathType: Prefix
 backend:
 service:
 name: api-svc
 port:
 number: 8080

2.5 ConfigMap 和 Secret

# ConfigMap - 存储配置数据
apiVersion: v1
kind: ConfigMap
metadata:
 name: myconfig
data:
 db_host: "mysql.default.svc.cluster.local"
 db_port: "3306"
 app.properties: |
 server.port=8080
 logging.level=INFO

---
# Secret - 存储敏感数据（base64 编码）
apiVersion: v1
kind: Secret
metadata:
 name: mysecret
type: Opaque
data:
 db_password: cGFzc3dvcmQxMjM=  # echo -n 'password123' | base64
 api_key: c2VjcmV0a2V5

2.6 其他核心资源

# 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
 volumeMounts:
 - name: data
 mountPath: /var/lib/mysql
 volumeClaimTemplates:
 - metadata:
 name: data
 spec:
 accessModes: ["ReadWriteOnce"]
 resources:
 requests:
 storage: 10Gi

---
# DaemonSet - 每个节点运行一个 Pod
apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: log-agent
spec:
 selector:
 matchLabels:
 app: log-agent
 template:
 metadata:
 labels:
 app: log-agent
 spec:
 containers:
 - name: fluentd
 image: fluentd:latest

---
# CronJob - 定时任务
apiVersion: batch/v1
kind: CronJob
metadata:
 name: backup
spec:
 schedule: "0 2 * * *" # 每天凌晨 2 点
 jobTemplate:
 spec:
 template:
 spec:
 containers:
 - name: backup
 image: backup-tool:latest
 command: ["/bin/sh", "-c", "run-backup.sh"]
 restartPolicy: OnFailure

3. 常用 kubectl 命令

3.1 集群信息

# 集群信息
kubectl cluster-info
kubectl get nodes
kubectl get nodes -o wide # 详细信息
kubectl describe node <node-name>

# 查看所有资源
kubectl get all -A # 所有命名空间
kubectl get all -n kube-system # 指定命名空间

3.2 资源管理

# 创建资源
kubectl apply -f deployment.yaml
kubectl create namespace my-ns
kubectl create configmap myconfig --from-file=config.properties
kubectl create secret generic mysecret --from-literal=password=123

# 查看资源
kubectl get pods
kubectl get pods -o wide # 显示 IP 和节点
kubectl get pods --show-labels # 显示标签
kubectl get pods -l app=myapp # 按标签过滤
kubectl get pods -A # 所有命名空间
kubectl get pods -w # 实时监听变化
kubectl get pods --field-selector=status.phase=Running

kubectl get svc
kubectl get deploy
kubectl get ingress
kubectl get configmap
kubectl get secret
kubectl get pvc # 持久卷声明
kubectl get events --sort-by='.lastTimestamp'

# 查看详情
kubectl describe pod <pod-name>
kubectl describe svc <svc-name>
kubectl describe node <node-name>

# 删除资源
kubectl delete pod <pod-name>
kubectl delete -f deployment.yaml
kubectl delete pods --all # 删除所有 Pod
kubectl delete pods --all -n my-ns

3.3 部署与更新

# 滚动更新
kubectl set image deployment/myapp myapp=myapp:2.0
kubectl apply -f deployment.yaml # 声明式更新

# 查看更新状态
kubectl rollout status deployment/myapp
kubectl rollout history deployment/myapp

# 回滚
kubectl rollout undo deployment/myapp # 回到上一个版本
kubectl rollout undo deployment/myapp --to-revision=2 # 回到指定版本

# 扩缩容
kubectl scale deployment/myapp --replicas=5
kubectl autoscale deployment/myapp --min=3 --max=10 --cpu-percent=80

3.4 调试与日志

# 查看日志
kubectl logs <pod-name>
kubectl logs <pod-name> -f # 实时追踪
kubectl logs <pod-name> --tail=100 # 最后 100 行
kubectl logs <pod-name> -c <container> # 多容器 Pod 指定容器
kubectl logs -l app=myapp # 按标签查看日志
kubectl logs --previous # 查看上次崩溃的日志

# 进入容器
kubectl exec -it <pod-name> -- /bin/bash
kubectl exec -it <pod-name> -c <container> -- /bin/sh

# 端口转发
kubectl port-forward <pod-name> 8080:80
kubectl port-forward svc/myapp-svc 8080:80

# 文件复制
kubectl cp <pod-name>:/path/file ./file
kubectl cp ./file <pod-name>:/path/file

# 查看 Pod 事件
kubectl get events --field-selector involvedObject.name=<pod-name>

# 调试 Pod（临时容器）
kubectl debug <pod-name> -it --image=busybox

3.5 命名空间管理

kubectl get namespaces
kubectl create namespace dev
kubectl config set-context --current --namespace=dev # 切换默认命名空间
kubectl delete namespace dev

4. 网络模型

4.1 Service 类型对比

类型	访问范围	使用场景
ClusterIP	集群内部	微服务间通信（默认）
NodePort	外部通过节点IP:Port	开发测试
LoadBalancer	云厂商 LB	生产环境
ExternalName	DNS CNAME	引用外部服务

4.2 网络策略

# 只允许同命名空间中 label 为 role=frontend 的 Pod 访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: allow-frontend
 namespace: production
spec:
 podSelector:
 matchLabels:
 app: backend
 policyTypes:
 - Ingress
 ingress:
 - from:
 - podSelector:
 matchLabels:
 role: frontend
 ports:
 - port: 8080

5. 存储

5.1 PersistentVolume 与 PVC

# PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
 name: my-pv
spec:
 capacity:
 storage: 10Gi
 accessModes:
 - ReadWriteOnce
 storageClassName: standard
 hostPath:
 path: /data/pv

---
# PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: my-pvc
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 5Gi
 storageClassName: standard

---
# 在 Pod 中使用
spec:
 containers:
 - name: app
 volumeMounts:
 - name: data
 mountPath: /data
 volumes:
 - name: data
 persistentVolumeClaim:
 claimName: my-pvc

5.2 StorageClass（动态供给）

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: fast
provisioner: kubernetes.io/aws-ebs
parameters:
 type: gp3
 iopsPerGB: "10"
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

6. RBAC 权限管理

# 创建角色
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: dev
 name: pod-reader
rules:
 - apiGroups: [""]
 resources: ["pods", "pods/log"]
 verbs: ["get", "list", "watch"]
 - apiGroups: ["apps"]
 resources: ["deployments"]
 verbs: ["get", "list"]

---
# 绑定角色到用户
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: read-pods
 namespace: dev
subjects:
 - kind: User
 name: developer
 apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: Role
 name: pod-reader
 apiGroup: rbac.authorization.k8s.io

7. 集群搭建方式

方式	适用场景	复杂度
minikube	本地学习开发	⭐
kind	CI/CD 测试	⭐⭐
kubeadm	生产部署	⭐⭐⭐
k3s	边缘/IoT/轻量	⭐⭐
托管服务	EKS/AKS/GKE	⭐⭐

8. 生产最佳实践

资源限制 — 始终设置 requests 和 limits
健康检查 — 配置 livenessProbe 和 readinessProbe
副本数 — 至少 2 个副本保证高可用
滚动更新 — 设置合理的 maxSurge 和 maxUnavailable
命名空间隔离 — 按环境（dev/staging/prod）分命名空间
网络策略 — 限制 Pod 间不必要的通信
RBAC — 最小权限原则
监控告警 — Prometheus + Grafana
日志收集 — EFK/Loki 栈
备份 etcd — 定期备份集群状态

总结

K8s 核心知识点：

架构 — Control Plane + Worker Node
Pod — 最小部署单元
Deployment — 无状态应用管理，滚动更新
Service — 为 Pod 提供稳定访问入口
Ingress — HTTP/HTTPS 路由
ConfigMap/Secret — 配置与敏感数据管理
StatefulSet — 有状态应用
PV/PVC — 持久化存储
RBAC — 权限控制
kubectl — 集群操作的核心命令