从单机容器到集群编排，再到灰度发布与探针。

一、单机容器

Docker

Docker 用镜像、容器和仓库把应用连同依赖打包。Dockerfile 描述构建层，镜像不可变，容器是它的运行实例。卷持久化数据，网络把多容器连起来。它解决的是“在我机器上能跑”的环境漂移，不是虚拟机那种完整操作系统隔离。

镜像要小：多阶段构建、不要把构建工具留在最终层。以非 root 运行，只读根文件系统能减少攻击面。标签不要长期只用 latest。编排上单机用 Compose，多机用 Kubernetes。日志打到 stdout，配置用环境变量或文件注入。排查时看镜像历史和容器 inspect。Docker 是交付格式，生产可靠性还取决于健康检查、资源限制和镜像扫描。

docker-compose

Docker Compose 用一份 YAML 描述多容器应用：服务、网络、卷和依赖启动顺序。本地开发可以把数据库、缓存和 API 一次拉起，和环境变量、覆盖文件配合后也能用于简单预发。

关键是把镜像构建与运行配置分开，密钥不要写进仓库。健康检查和 depends_on 条件启动能减少“库还没好就连”的竞态。资源限制要写上，否则笔记本上互相抢 CPU。

生产集群更常见的是把 Compose 转成 Swarm stack 或 K8s 清单。Compose 本身不是调度器，单机重启策略解决不了跨节点故障转移。

docker-swarm

Docker Swarm 是 Docker 自带的集群编排模式，把多台主机组成一个调度域，用 service 声明副本数、网络和滚动更新。对已经熟悉 Compose 文件的团队，学习曲线比 Kubernetes 平缓。

它适合中小规模内部平台：overlay 网络、ingress 负载和密钥管理够用，但生态插件、CRD 和复杂调度策略不如 K8s 丰富。生产上要规划管理节点奇数个，并备份 Raft 状态。

滚动更新要设更新并行度和失败暂停。健康检查失败应自动回滚，而不是只看容器起来了。和外部负载均衡对接时，明确是路由网格还是主机端口模式，避免流量黑洞。

二、集群

K8S etcd

etcd 是 Kubernetes 的键值存储，保存集群对象和配置。它用 Raft 保证多数派写入，因此控制面是否健康很大程度上取决于 etcd 的磁盘、延迟和成员数。

运维要点：专用高速盘、控制提案规模、定期压缩与备份、三或五节点奇数集群。不要把 etcd 当通用数据库给业务写大 value。证书与 peer 通信要隔离。恢复时用快照加 WAL，先确认集群 ID 再启动，避免脑裂。监控 leader 选举、fdatasync 延迟和数据库大小。升级 kube-apiserver 前先确认 etcd 版本兼容。

devops k3s

k3s 是面向边缘和轻量集群的 Kubernetes 发行版，去掉了不少默认插件，单二进制即可拉起。适合实验室、门店设备和资源有限的 CI 跑集群，而不是替代大规模托管 K8s 的所有能力。

和完整发行版相比，它默认使用 sqlite 或精简存储，Traefik 作入口，内存占用更低。生产上仍要规划证书轮换、备份 etcd/sqlite，以及如何把镜像和 Helm chart 同步到离线节点。

DevOps 流程上可以把 k3s 当预发或集成环境：流水线把同一套清单先打到 k3s，再晋级到正式集群，减少“本地 Minikube 能过、线上挂掉”的落差。

三、发布与探针

k8s 实战-应用探针

Kubernetes 探针用来判断容器是否活着、是否就绪、是否启动完成。liveness 失败会重启容器，readiness 失败会从 Service 摘除，startupProbe 则给慢启动应用一段宽限期，避免被过早杀死。

HTTP 探针应打到轻量健康接口，不要每次去连数据库全表扫描。exec 探针会 fork 进程，高频下有开销。timeout、period 和 failureThreshold 要按真实启动曲线调：JVM 冷启动往往需要 startupProbe。就绪与存活不要用同一个过重检查，否则抖动会连环重启。观察 kubelet 事件比看应用日志更能确认探针是否误杀。

k8s 实战-灰度发布、金丝雀发布

灰度与金丝雀发布都是把新版本先交给一小部分流量，观察错误率和延迟后再扩量。Kubernetes 里可以用两个 Deployment 共用一个 Service，通过副本比例切流；更精细则靠 Ingress、Gateway API 或服务网格按 Header、用户 ID 分流。

关键是可观测：金丝雀必须有独立指标，否则看不出是新版本的问题。回滚路径要预先演练，不要只靠改镜像 tag。数据库兼容要向前向后都成立，否则流量切回去也会失败。小流量不等于低风险，若金丝雀用户恰好是核心客户，仍可能放大故障。发布策略应写成流水线，而不是值班时手工改 YAML。