有了 Docker 为什么还要 K8s？单机容器与集群编排的边界与过渡路径

Docker 和 K8s 的关系每隔一段时间就会有人拿出来问一次既然 Docker 已经把应用打包成镜像一条命令就能启动为什么还要搞出 Kubernetes 这么重的东西我先给出一个直接判断Docker 解决的是“单台机器上如何把应用跑起来”的问题K8s 解决的是“很多台机器上如何保证这些应用不挂、可调度、能扩容、好管理”的问题。短期单机开发Docker 足够生产环境、多实例、微服务、流量波动、节点故障只有 Docker 往往会失控。这篇就围绕“为什么还要 K8s”拆开讲包括两者到底差在哪、K8s 多做了什么、什么时候才需要上、以及从 Docker 平滑过渡到 K8s 的实际路径。很多人学容器技术时最先接触的都是 Docker镜像、容器、端口映射、数据卷、docker-compose。这套东西确实好用开发环境一条命令拉起来打包镜像发给别人也能复现。但一旦应用规模变大比如你手上有 10 个服务部署在 3 台机器上问题很快就来了流量高了想把某个服务多开几个谁来调度某个节点宕机了上面的容器怎么迁移新加一台机器怎么让服务自动用上新资源这些都不是 Docker 本身能直接回答的。K8s 就是在这个层面把事情接过去的。下面按实际理解路径拆开讲先解决两者关系再看 K8s 做了什么然后讨论什么场景必须上 K8s最后聊怎么从 Docker 平滑过渡。1. 先用一句话理清 Docker 和 K8s 的分工1.1 Docker 是单机容器引擎K8s 是集群编排系统Docker 的核心能力围绕“单个容器”展开拉镜像、建容器、启停、删除、端口映射、数据卷挂载。你可以在一个节点上同时跑多个容器但所有容器都共享这台机器的 CPU、内存、磁盘和网络没有跨节点的调度概念。K8s 的核心能力围绕“一批容器”展开它管理的是一个集群由多个 Node节点组成Kubernetes 决定每个 Pod 放在哪个节点、资源够不够、要不要重启、要不要扩容。K8s 不直接操作容器而是通过容器运行时常见的就是 containerd以前很多环境用 Docker来拉起容器。换句话说Docker 是 K8s 集群中单个节点上可能用到的容器运行层K8s 是更高一层的控制系统。这个关系经常被误解成“K8s 是 Docker 的升级版”不准确。更贴切的比喻是Docker 像你手里的集装箱单个箱子怎么装、怎么搬它管得不错K8s 像整个港口的调度系统哪个箱子放哪个泊位、哪艘船先装卸、什么时候调几台吊车过来Docker 管不了。1.2 为什么“有了 Docker”还会觉得不够单机场景下Docker docker-compose 已经能解决很多问题比如 LNMP 环境一键拉起、MySQL 和 Redis 主从测试、开发环境隔离。但生产环境面对的问题不一样故障恢复一个容器进程挂了Docker 单机重启策略有限节点宕机之后容器不会自动跑到另一台机器上。流量调度业务涨了需要从 1 个实例扩到 10 个实例Docker 没有自动伸缩、负载均衡和统一入口。服务发现A 服务要调用 B 服务B 有多份实例Docker 默认不会自动维护一个可用的服务地址列表。升级发布滚动更新、回滚、金丝雀发布Docker 本身没有这套流程。配置和密钥管理多套环境、多个配置项Docker 不是不能做但集群规模一大就非常零散。这些痛点叠加起来才是“为什么还要 K8s”的真正答案。2. K8s 到底多做了什么单机 Docker 做不到的事2.1 调度把 Pod 放到合适的节点上K8s 里最小的调度单位不是容器而是 Pod。一个 Pod 可以包含一个或多个容器这些容器共享网络和存储。调度器会综合考虑每个节点的资源、标签、污点和亲和性决定 Pod 最终落到哪台机器。这个能力在单机 Docker 里完全不存在。你在 Docker 里跑一个容器它就在当前这台机器上要跑在别的机器你得手动登录那台机器再 docker run。K8s 则是你告诉它“我要 3 个副本每个副本需要 1 核 2G”调度器自己去选节点。机器有多台、资源不均衡、部分节点有特殊硬件时这个差异会非常明显。2.2 自愈不用半夜爬起来重启服务K8s 的 Deployment 和 ReplicaSet 会持续对比“期望副本数”和“实际副本数”。某个 Pod 挂了控制器立刻创建新 Pod 顶上节点宕机默认情况下过一段时间后会将该节点上的 Pod 在其他节点重建容器存活但业务异常ReadinessProbe 和 LivenessProbe 会配合探针做更精细的处理。Docker 单机也有 restart 策略比如 always、on-failure但那只是解决“这台机器上容器退出了要不要拉起来”的问题。节点断电、磁盘故障、整机网络隔离Docker 的 restart 无能为力。K8s 的自愈能力是集群级别的。2.3 服务发现与统一入口集群内服务之间的调用K8s 通过 Service、DNS 和 Endpoints 来做。每个 Service 有固定的虚拟 IP 和 DNS 名称Pod 变化、IP 变化都不会影响服务间的调用关系。对外流量再多加一层 Ingress比如 Nginx Ingress Controller 或 Traefik按域名和路径路由到不同 Service。Docker 场景下服务间调用通常靠手动维护 IP 或者自定义配置docker-compose 里用服务名也能互相访问但那只局限于一个 compose 项目内部。跨机、跨网络、跨环境Docker 的方式会变得很辛苦而 K8s 把“服务发现”做成了平台能力。2.4 弹性伸缩从 1 个副本到 20 个副本K8s 的 HPAHorizontalPodAutoscaler可以根据 CPU、内存或自定义指标自动调整副本数。这个能力在流量波动明显的业务里非常实用。Docker 要扩容就必须手动执行 docker run或者自己写脚本、接 CI/CD 和外部调度平台本质还是没有内生的“按指标自动扩容”机制。需要注意的是HPA 不是银弹。指标采集和延迟、应用启动时间、Pod 快速扩容时的资源竞争都会影响实际效果。但 K8s 至少把这道自动化能力直接开放出来了。2.5 声明式管理把系统状态变成数据这是 K8s 和 Docker 使用模式上最本质的区别。Docker 是命令式的你执行 docker run、docker stop、docker rm每一步都是你主动操作。K8s 是声明式的你编写 YAML声明“我要什么状态”剩下的由控制器不断调解让集群状态逼近你的声明。这个差异带来的好处是配置可以版本化变更可以走 Git 工作流出问题可以快速回滚到上一版 YAML。团队协作时K8s 的对象描述比一堆 shell 历史记录可靠得多。3. 什么时候才真正需要 K8s什么时候没必要3.1 没必要上 K8s 的典型场景不是所有项目都要上 K8s。以下场景用 Docker docker-compose 反而更轻个人学习和小型实验单机跑一个 LNMP 环境、装 MySQL、Redis 做测试docker-compose 足够。公司内部一次性工具比如临时起一个数据库、跑一次数据迁移任务不需要长期稳定集群。节点数量很少、没有横向扩容需求两三台机器服务总量固定手动维护成本可以接受。团队没有容器编排经验强行上 K8s控制面组件、网络插件、存储插件、升级流程每一个都可能成为新的故障源。在这些场景里K8s 带来的复杂度远大于收益。这也是我一直强调“低配置能跑不代表适合能跑通也不代表当前就该上”的原因。3.2 值得上 K8s 的典型信号以下情况碰到两三条就可以认真评估 K8s服务数量超过 10 个手动维护部署脚本越来越乱。需要多副本部署某几个核心服务且副本数经常变化。节点数量超过 3 台需要统一管理资源。发布频率高需要滚动更新、回滚和金丝雀发布。业务对故障恢复要求高不能接受节点宕机后长时间不可用。需要按环境隔离配置、密钥又不希望散落在各个服务器上。多个服务间调用频繁需要稳定的服务发现和 DNS 机制。有一个常见误区认为“上了 K8s 就一定比 Docker 稳定”。其实 K8s 只是把很多原来运维手工做的事情自动化了但 K8s 本身也有升级、网络、存储、证书过期等问题。如果你的应用架构和团队能力没有准备好K8s 会把原本显性的单机故障变成隐性的集群调度故障。4. 从 Docker 到 K8s 的平滑过渡路线4.1 先做好容器化再谈编排不管最终是否上 K8s第一步都是把应用正确容器化。Docker 阶段要关注的不是“镜像能不能 build 出来”而是镜像是否足够小基础镜像是否包含大量无关依赖。容器是否有非 root 用户运行是否适合安全扫描。日志是否输出到 stdout而不是写在容器内某个文件。配置文件是否通过环境变量或挂载注入而不是打进镜像。有状态数据是否落在命名卷或外部存储而不是写在容器可写层。容器化不规范后面上 K8s 会把这些问题放大几十倍。比如日志不输出到 stdoutK8s 里你就看不到有效排障信息有状态数据写在容器可写层Pod 一重建数据就丢了。4.2 用 docker-compose 模拟多服务部署在单机上先跑通多服务的编排是很好的过渡练习。把应用拆成 web、api、db、cache 等几个服务用 docker-compose 管理网络、依赖顺序和数据卷。这个阶段你会自然理解“服务之间如何通过服务名通信”“外部如何访问内部服务”“数据应该如何持久化”。等这些概念都清楚了再迁移到 K8s很多 YAML 里的字段就不会显得那么抽象。比如 compose 里的 service 对应 K8s 里的 Servicecompose 里的 restart 对应 K8s 里的 restartPolicy 和控制器自动重启逻辑compose 里的 volumes 对应 K8s 里的 PersistentVolumeClaim。4.3 从最小的 K8s 集群开始不要一上来就生产学习阶段推荐先用轻量方案搭一个单节点或三节点集群。常见的选择包括 k3s、minikube、kind、kubeadm。没有哪个是绝对最好的取决于你想学什么minikube适合在本地电脑快速体验 K8s 的基础对象启动快但和真实多节点集群有差距。kind适合用容器模拟节点做 CI、测试、本地实验很方便。k3s占用资源少适合低配机器或边缘场景也能跑正式工作负载。kubeadm更接近生产环境安装方式适合想了解 K8s 组件交互的读者。我建议先在 minikube 或 kind 上把 Deployment、Service、Ingress、ConfigMap、Secret 这些对象跑一遍再考虑用 kubeadm 搭多节点集群。不要一上来就去网上找一条命令安装生产集群的脚本装完之后你不知道里面发生了什么出了问题很难排查。4.4 把 LNMP 这类经典架构从 Docker 搬到 K8s网络上常见的 LNMP 实验即 Nginx PHP MySQL 的部署方式是一个很好的 K8s 练习项目。Docker 里你会写一个 compose 文件定义 nginx、php-fpm、mysql 三个服务。K8s 里则需要拆成这套对象Deployment 或 StatefulSetMySQL 有状态数据适合 StatefulSet至少需要 PersistentVolumeClaim。DeploymentNginx 和 PHP-FPM 分别作为无状态服务Nginx 通过 FastCGI 转发给 PHP-FPM。Service每个服务暴露一个稳定 DNS 地址。ConfigMapNginx 配置和 PHP 配置通过 ConfigMap 挂载进容器。SecretMySQL 密码通过 Secret 注入。这个实验做完你基本就理解了 K8s 的配置、存储、网络和服务发现核心概念也会发现 K8s 里做 LNMP 比 Docker compose 多好几倍的文件这正是“编排能力换复杂度”的实际感受。4.5 渐进式迁移不要重写一切如果已经有服务在 Docker 里跑得好好的完全没必要一次性把所有服务都迁到 K8s。建议按优先级逐步迁移优先迁移无状态服务比如 Web API、前端静态资源、任务处理 Worker。数据库、Redis、消息队列这类有状态组件先评估是否有成熟的 Operator 或外部托管方案。保持一段时间混合模式部分服务在 K8s部分服务仍在原 Docker 环境通过网络打通或统一入口转发。把迁移过程中遇到的配置、存储、日志、监控问题记录下来形成自己的检查清单。迁移过程中最容易被忽略的是日志和监控。Docker 里你可以在节点上 docker logsK8s 换节点、滚动更新后日志会散落在多个节点没有集中收集很难排查。建议在上 K8s 前先搭建日志收集方案比如 Loki、Elasticsearch 或云厂商日志服务再把应用日志输出规范同步处理。5. K8s 学习中最容易踩的坑和排查思路5.1 网络问题大多和 CNI 插件有关K8s 集群中 Pod 之间、Pod 与 Service 之间通信依赖 CNI 网络插件常见的有 Calico、Flannel、Cilium、Weave。新手经常遇到“Pod 起来了但互相 ping 不通”或“Service 地址访问超时”大多数不是应用问题而是网络插件没有调好。排查顺序建议先看kubectl get pods -n kube-system确认网络插件 Pod 都是 Running。看节点内核模块是否开启比如 Calico 依赖的 ipip、veth、nf_conntrack 等。检查防火墙或安全组是否放行节点间通信端口。再看网络策略是否误拦截。不要一遇到 Pod 之间连不通就怀疑应用代码先确认集群网络数据面是正常的。5.2 资源不足导致的连环故障K8s 集群最隐蔽的问题之一是对每个容器不设置 requests 和 limits。完全不设置Pod 可能把节点内存打爆触发 OOM Killer系统 Pod 也可能被挤出最后整个控制面都不稳定。设置得太紧又会导致 Pod 不断重启、调度失败。我的建议是每个工作负载至少设置 requestslimits 可以按业务需求决定但不要长期不设置。requests 决定了调度器怎么判断节点是否合适limits 决定了容器是否会被 cgroup 限制。发布到生产前先用压测或历史监控数据确定合理区间。5.3 Pod 一直 CrashLoopBackOff先看日志再改代码CrashLoopBackOff 是新手最容易慌的报错。遇到时不要急着改代码先按顺序确认kubectl describe pod pod-name看事件确认是镜像拉取失败、还是探针失败、还是容器退出。kubectl logs pod-name看应用日志确认启动时缺了哪个配置或依赖。确认 ConfigMap 和 Secret 是否挂载正确环境变量是否注入。确认资源限制是否太小导致容器刚启动就被 OOM Kill。大多数 CrashLoopBackOff 是配置和环境问题真正的代码问题反而好定位。5.4 服务升级后不回滚依赖版本混乱团队刚上 K8s 时常见的坏习惯是直接改 YAML 或者用kubectl edit在线改对象。这样改完虽然能生效但配置没有入库下次重装集群、新成员接手都不知道当前版本长什么样。更稳妥的做法是所有 YAML 都放进 Git 仓库用 Git 记录每次变更能用 Helm Chart 就用 Helm把版本号、镜像 Tag、副本数这些变量抽出来发布走 CI/CD 流程而不是手动执行 kubectl apply。5.5 别把“能启动”当成“可以上生产”K8s 里把服务跑起来不难难的是跑起来之后还能长期稳定。生产环境至少要额外考虑监控指标CPU、内存、带宽、Pod 重启次数、错误率。告警规则核心服务不可用、Pod 长时间重启、磁盘使用率过高。备份策略数据库定时备份、对象存储冗余、跨区域容灾。升级演练控制面组件升级、节点替换、网络插件升级。安全基线镜像扫描、密钥扫描、RBAC 权限最小化。这些都不是 K8s 安装完成后自动有的需要团队规划和持续迭代。6. 给不同学习阶段读者的实操建议6.1 刚学完 Docker准备了解 K8s可以先在自己的电脑上用 Docker Desktop 或 minikube 起一个单节点集群然后跑这个练习清单创建 Deployment副本数为 3观察 Pod 分布和滚动更新。创建 Service用 ClusterIP 方式在集群内访问再用 NodePort 从宿主机访问。创建 ConfigMap 和 Secret挂载到 Pod修改配置后滚动更新。创建 Ingress给两个不同服务设置两个不同路径。手动删除一个 Pod观察 ReplicaSet 是否自动创建新 Pod。每个练习都用kubectl get和kubectl describe查看状态变化。6.2 有一定 K8s 基础想进一步了解生产落地这时候重点要关注的是网络插件的工作原理Calico 的 BGP 模式和 IPIP 模式有什么区别。存储方案本地存储、NFS、CSI 插件的区别和适用场景。有状态应用如何用 StatefulSet 和 Operator 管理。多集群、多环境的管理方式比如 Kustomize 和 Helm 怎么选。故障演练主动模拟节点宕机、Pod 驱逐、网络分区看看系统是否真的自愈。6.3 准备面试可以关注这些高频考点网上关于 K8s 的面试题很多核心考点通常集中在为什么有 Docker 还需要 K8s两者的分工和边界。K8s 控制面组件有哪些每个组件负责什么。Pod、Deployment、Service 的关系和区别。如何保证服务滚动更新不中断。节点资源不足时会发生什么驱逐策略是什么。如何排查 Pod 一直 Pending、ImagePullBackOff、CrashLoopBackOff。这些题看起来很散但背后都指向同一个能力你能否在故障发生时从现象倒推原因而不是只会背概念。7. 最后几条真心话Docker 和 K8s 不是二选一的对立关系而是容器技术栈里的上下游配合。K8s 离不开容器运行时但容器运行时不等于编排平台。生产环境里K8s 也不一定是你唯一的选择Docker Swarm、HashiCorp Nomad、云厂商的 Serverless 容器服务都可能在某些场景更合适。但就目前的主流趋势、社区生态、资料完整度、人才储备来看K8s 依然是容器编排方向最值得投入的学习对象。学习节奏上我更建议先把 Docker 的单机能力和 Compose 多服务编排练熟再进 K8s。不要跳步也不要反向“鄙视”Docker。很多 K8s 里的疑难问题追根溯源还是容器镜像不规范、依赖版本不明确、环境配置没收敛。最重要的一点K8s 的能力不是装好就自然拥有的也不是把 YAML 复制到生产环境就万事大吉。它把原本手工运维的流程平台化同时也把“责任”集中到了控制面上。你会发现很多服务没有上 K8s 时问题出在某台机器上了 K8s 之后问题变成“为什么会选中这个节点”“为什么这个 Pod 被驱逐”“为什么升级后流量有抖动”排查链路更长、更抽象了。所以面对“有了 Docker为什么还要 K8s”这个问题我会这样回答如果你只有一台机器、几个服务、流量稳定Docker 就够如果你想解决多机器调度、故障自愈、自动扩缩容、统一发布流程K8s 是当前最通用的一套答案。但答案本身不会替你消除复杂度它只是让复杂度从“人肉处理”转成“平台处理”前提是你得先学会跟平台对话。