## 1. Docker 是容器运行时，不是编排平台 很多人第一次接触容器技术时，会下意识地把 Docker 当成“万能胶”——觉得装了 Docker 就能解决部署、扩缩容、高可用所有问题。我当年也是这么想的，还兴致勃勃地用 `docker run` 启动了七八个服务，配上 `--restart=always`，自以为搞定了生产环境。结果某天 Redis 容器 OOM 被 kill，Docker 确实自动重启了，但应用连不上 Redis 的时候根本没做健康检查，上游服务直接雪崩。这才意识到：Docker 的核心职责非常聚焦——**把应用和它的运行时环境打包成一个可移植、可复现的标准化单元，并在单机上可靠地启动、停止、日志收集和资源隔离**。 它不关心这个容器该不该重启（只管 exit code 和 restart policy），不关心它该跑在哪台机器上，也不管它和其他容器怎么通信、怎么暴露端口、怎么应对流量突增。这些都不是 Docker 的设计目标。它的 API 设计得极其干净：`build` 打包镜像，`run` 启动实例，`exec` 进入调试，`logs` 查看输出，`ps` 列出状态。没有 Service Discovery，没有滚动更新策略，没有跨主机网络策略。你用 `docker network create --driver overlay` 搭集群？那是 Swarm 的事，不是 Docker Engine 本身的功能。 实际项目中，我常用 Docker 做三件事：第一是本地开发环境一致性保障，前端同事拉一个含 Node 18 + Yarn + Chrome 的镜像，后端同事用含 JDK 17 + Maven 的镜像，大家 `docker build -t myapp . && docker run -p 8080:8080 myapp` 就能跑通，彻底告别“在我机器上是好的”；第二是 CI/CD 流水线中的构建环节，用多阶段构建（multi-stage build）把编译环境和运行环境彻底分离，最终镜像只有几 MB；第三是离线交付场景，比如给客户部署边缘设备，直接 `docker load < app.tar` 加载镜像，比传一堆 jar 包加 shell 脚本靠谱得多。这些场景里，Docker 表现得非常稳，命令行反馈明确，错误信息直指问题根源，比如 `failed to solve: failed to read dockerfile: open /path/Dockerfile: no such file or directory`，一看就知道路径错了，不用猜。 > 提示：Docker Desktop 在 macOS 和 Windows 上默认启用了 WSL2 或 Hyper-V 虚拟化层，实际运行的是 Linux 容器。如果你在 Linux 服务器上部署，务必确认内核版本 ≥3.10（推荐 ≥4.19），并启用 cgroups v2 和 overlay2 存储驱动。执行 `docker info | grep "Storage Driver\|Kernel Version"` 可快速验证。 ## 2. Kubernetes 是声明式集群操作系统 Kubernetes 不是 Docker 的“升级版”，也不是“更高级的 Docker”。它压根就不处理容器镜像怎么构建、怎么分层存储、怎么挂载卷这些底层细节——它把这些全交给底层容器运行时（Container Runtime），比如 containerd（Docker Engine 的核心组件）、CRI-O，甚至 Kata Containers。K8S 关心的是：**当有 50 台服务器、200 个微服务、每天上万次发布时，如何让整个系统始终朝着你期望的状态收敛**。 举个最典型的例子：你写了一个 Deployment YAML，声明要 5 个 nginx 实例，CPU 限制 500m，内存上限 1Gi，并配置了 readinessProbe 检查 `/healthz`。K8S 控制平面收到这个请求后，并不会立刻去某台节点上 `docker run` 五个容器。它先通过 Scheduler 把这 5 个 Pod 分配到满足资源条件的节点上；然后 kubelet 在对应节点调用 containerd 创建容器；接着 livenessProbe 定期 curl `/healthz`，一旦失败就杀掉旧容器、拉起新容器；如果某个节点宕机，ReplicaSet Controller 会立刻在其他节点补足缺失的副本；哪怕你手动 `kubectl delete pod nginx-xxx`，它也会在几秒内重建一个一模一样的 Pod。这一切动作背后没有人工干预，全是控制器（Controller）持续比对“当前状态”和“期望状态”，驱动系统向目标靠拢。 我在一个电商大促系统里实践过这套逻辑。活动前把商品详情页服务的 Deployment replicas 从 12 改成 36，提交后不到 20 秒，所有新 Pod 就 Ready 了，监控曲线平滑上扬；活动结束再改回 12，K8S 自动滚动下线 24 个实例，老连接保持活跃直到自然关闭，完全不影响用户体验。这种“说我要什么，而不是教我怎么做”的声明式模型，才是 K8S 的灵魂。它把运维人员从“执行者”变成了“定义者”，你不再写 `ssh node1 && docker stop xxx && docker rm xxx && docker run ...` 这类过程式脚本，而是专注描述“服务应该长什么样”。 ```yaml # 生产级 nginx Deployment 示例（含健康检查与资源约束） apiVersion: apps/v1 kind: Deployment metadata: name: nginx-prod spec: replicas: 5 selector: matchLabels: app: nginx-prod template: metadata: labels: app: nginx-prod spec: containers: - name: nginx image: nginx:1.25-alpine resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" livenessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /readyz port: 80 initialDelaySeconds: 5 periodSeconds: 5 ``` ## 3. Docker 镜像是 K8S 的交付物基础 K8S 本身不负责生成镜像，但它极度依赖镜像的标准化程度。一个合格的生产镜像，必须满足三个硬性条件：最小化、不可变、可验证。我见过太多团队踩坑：用 `ubuntu:latest` 作为基础镜像，结果某天 `apt update` 升级了 glibc，导致 Java 应用崩溃；或者在镜像里硬编码数据库地址，导致测试环境和生产环境无法共用同一镜像；更有甚者，在 `ENTRYPOINT` 里写 `sh -c 'sleep 10 && java -jar app.jar'`，让 K8S 的健康检查永远超时。 正确的做法是：基础镜像选 `distroless` 或 `alpine`（如 `gcr.io/distroless/java17-debian12`），只保留运行时必需的二进制文件；构建过程用多阶段，编译阶段用 maven:3.9-openjdk-17，运行阶段只 COPY 编译产物；所有外部依赖（DB 地址、Redis 密码）通过环境变量或 ConfigMap 注入，绝不写死；`CMD` 必须是前台进程，保证容器主进程就是应用本身（否则 K8S 会误判为 CrashLoopBackOff）。这样构建出来的镜像，无论在开发机、CI 服务器还是 K8S 集群里，行为都完全一致。 我们团队推行了一套镜像规范检查清单，CI 流水线中强制执行： 1. `docker history <image>` 检查层数是否 ≤8（避免无意义的 `RUN apt-get update` 多次叠加）； 2. `docker scan <image>` 扫描 CVE 高危漏洞（要求无 CRITICAL 级别）； 3. `docker inspect <image> | jq '.[0].Config.ExposedPorts'` 确认只暴露业务端口（如 `{"8080/tcp":{}}`），禁用 `22/tcp` 或 `3306/tcp` 这类非必要端口； 4. `docker run --rm <image> sh -c 'ls -l /app/'` 验证应用文件权限为非 root 用户可读。 这套流程跑下来，镜像大小从平均 1.2GB 降到 280MB，构建时间缩短 65%，更重要的是，K8S 集群里因镜像问题导致的 Pod 启动失败率从 12% 降至 0.3%。你会发现，K8S 的强大编排能力，是建立在 Docker 提供的坚实交付物之上的——就像高速公路再先进，也得靠标准尺寸的集装箱货车才能跑起来。 ## 4. 二者协同构成云原生交付闭环 Docker 和 K8S 的真实协作关系，不是“先有鸡还是先有蛋”，而是“流水线两端的齿轮咬合”。我画过一张我们团队日常发布的流程图：开发者提交代码 → GitLab CI 触发构建 → `docker build -t registry.example.com/app/web:${CI_COMMIT_SHA} .` → `docker push` 推送到私有仓库 → Argo CD 监听到新镜像 → 自动更新 K8S 中的 Image 字段 → Deployment 控制器发起滚动更新 → 新 Pod 逐个 Ready → Prometheus 验证 HTTP 200 率 >99.9% → 全量切流。整个过程无人值守，从代码提交到线上生效平均耗时 4 分 32 秒。 这里每个环节都离不开二者的分工：Docker 负责把代码变成带版本号的、可验证的、一次构建处处运行的镜像；K8S 负责把这个镜像安全、可控、可观测地部署到千台服务器上。它们之间最关键的粘合剂，是 **OCI（Open Container Initiative）镜像规范**。Docker 生成的镜像，K8S 里的 containerd 可以原生加载；反过来，K8S 的 Helm Chart 里写的 `image: nginx:1.25`，Docker CLI 也能直接 `docker pull` 下来本地调试。这种开放标准，让工具链可以自由组合——你可以用 BuildKit 加速构建，用 Kaniko 在 K8S 集群内构建，用 Trivy 做镜像扫描，用 Falco 做运行时安全检测，它们都基于同一套 OCI 标准。 实际落地时，我建议新手从“Docker 本地验证 + K8S Minikube 演练”起步。先用 `docker-compose.yml` 写好本地多服务依赖（MySQL + Redis + Web），确保 `docker-compose up` 能跑通；再把 compose 文件用 `kompose convert` 转成 K8S 原生资源（Deployment + Service + ConfigMap），导入 Minikube；最后在 Minikube 里实测 `kubectl scale deploy/web --replicas=3` 和 `kubectl rollout restart deploy/web`。这样既避开了初期复杂的 K8S 网络调试，又能亲身体验声明式更新的威力。等熟悉了 Pod 生命周期、Service DNS 解析、PersistentVolume 绑定这些概念，再迁移到真实集群，会少走很多弯路。 我在三个不同规模的项目里反复验证过这个路径：小团队用 Docker Compose 足够支撑 MVP 验证；中型业务上 K8S 后，运维效率提升最明显的是发布速度和故障恢复速度；大型平台则必须依赖 K8S 的命名空间隔离、RBAC 权限控制和自定义资源（CRD）扩展能力。但无论哪个阶段，Docker 始终是那个默默把应用打包成标准件的“造箱工人”，而 K8S 是调度千万个箱子高效运转的“智能港口系统”。