1. 为什么学Docker必须先啃下这三块硬骨头专有名词、核心架构、使用场景你是不是也这样打开Docker官网满屏的“镜像”“容器”“仓库”“层”“卷”“网络”看得人头皮发麻跟着教程敲完docker run hello-world心里却在打鼓这到底启动了个啥它和我本地装的Python环境有啥区别为啥非得用它——别急这不是你理解力的问题而是绝大多数入门教程跳过了最关键的“认知地基”。就像学开车不先搞懂油门、刹车、档位、离合器各自干啥光练踩油门迟早熄火。Docker不是魔法它是一套有明确逻辑、有清晰边界、有特定目的的技术体系。第2招就是帮你把这套体系的“骨架”立起来专有名词是它的语言核心架构是它的骨骼使用场景是它的血液。三者缺一不可且必须同步建立。我带过几十个刚转行的开发和运维新人凡是卡在Docker上动弹不得的90%都栽在这三块没打通。他们要么把“镜像”当成一个黑盒文件要么以为“容器”就是个轻量级虚拟机更别说搞清dockerd、containerd、runc这些底层组件怎么咬合在一起。结果就是配置报错只会百度复制粘贴问题一变就抓瞎更别提在生产环境里做资源隔离、服务编排或CI/CD集成。这招不讲命令怎么敲不教Dockerfile怎么写就只做一件事用最贴近真实工作流的视角把这三个抽象概念掰开、揉碎、再拼回原形。你会看到一个docker run -p 8080:80 nginx命令背后其实是一场精密协作——从你敲下回车开始到Nginx网页在浏览器里弹出来中间至少经过7层抽象与5个独立进程的接力。而所有这些都藏在那几个看似简单的名词和架构图里。现在我们就从最常被误解的“镜像”开始一层层剥开Docker的真相。2. 专有名词不是术语表而是Docker世界的“交通规则”很多人把Docker专有名词当字典背结果越背越糊涂。比如“镜像”这个词官方定义是“一个只读模板用于创建容器”。听起来很对但实际工作中它根本不是“模板”。我第一次部署一个Spring Boot应用时就栽在这儿我把打包好的JAR包塞进Dockerfiledocker build完生成一个镜像然后docker run——结果容器秒退。查日志发现java -jar app.jar找不到主类。后来才明白我犯了个致命错误我把镜像当成了“可执行文件”以为build完就能直接run。其实镜像的本质是一个分层的、按需加载的、可复用的文件系统快照集合。它不包含任何运行时状态也不包含CPU、内存这些资源——它只是一堆按顺序叠起来的“层”Layer。每一层都是Dockerfile里一条指令如COPY、RUN执行后产生的文件系统变更。这些层被设计成只读且可以被多个镜像共享。举个生活化的例子你做一道红烧肉食谱Dockerfile里写着“放酱油”“加糖”“炖1小时”。每次按这个食谱做你得到的都不是同一锅肉而是同一套“做法快照”。镜像就是这套快照——它记录了“放酱油后是什么样子”、“加糖后是什么样子”、“炖1小时后是什么样子”但绝不等于“正在炖的那锅肉”。那“正在炖的那锅肉”是谁是容器。容器才是镜像的“运行实例”它在镜像只读层之上叠加了一个可写的“容器层”Container Layer所有你在容器里做的修改——比如touch /tmp/test.txt、echo hello /app/log.txt——都发生在这个可写层里。一旦容器删掉这个可写层就没了镜像本身纹丝不动。这就是为什么你能同时跑10个基于同一个nginx镜像的容器它们互不干扰改各自的配置文件也不会影响别人。这种“写时复制”Copy-on-Write机制是Docker高效、轻量的核心秘密。再看“仓库”Registry。新手常把它等同于“Docker Hub”这是大错特错。Docker Hub只是众多仓库中的一种就像淘宝是电商网站但电商网站不只有淘宝。仓库的本质是一个集中存储和分发镜像的HTTP服务。它负责两件事一是存Push二是取Pull。当你docker push myapp:1.0你的本地镜像被切成若干层每层计算SHA256哈希值然后连同元数据一起上传到仓库当你docker pull nginx:alpineDocker客户端会先向仓库查询nginx:alpine这个标签对应哪些层再按需下载——如果本地已有某一层比如基础的alpine OS层就直接复用绝不重复下载。这才是为什么docker pull比wget一个几百MB的ISO快得多。至于“卷”Volume和“绑定挂载”Bind Mount它们解决的是同一个问题如何让容器里的数据“活下来”。但解法截然不同。卷是Docker自己管理的目录路径在/var/lib/docker/volumes/下你只管起个名字如myapp-dataDocker自动给你分配一个ID路径绑定挂载则是你指定宿主机上的一个绝对路径如/home/user/data直接映射进去。前者安全、可移植、适合多容器共享后者灵活、调试方便但路径硬编码一换机器就失效。我在线上部署MySQL时数据库文件必须用卷因为要保证重启后数据不丢而在本地开发调试时我常用绑定挂载把本地代码目录挂进去改一行代码容器里立刻热更新不用反复build。最后说说“网络”Network。docker0桥接网络、host网络、none网络、自定义桥接网络……这些不是凭空造出来的。它们对应着Linux内核的真实网络能力docker0本质是一个虚拟网桥所有默认桥接网络的容器都通过veth pair一对虚拟网卡连到它上面就像一栋楼里的所有住户都连到同一个总电闸host网络则干脆让容器直接复用宿主机的网络命名空间没有网络隔离端口直接暴露性能最好但最不安全自定义网络如docker network create mynet则会创建一个独立的网桥并启用内置DNS服务容器之间可以直接用服务名如redis互相访问不用记IP。这背后全是Linux的network namespace、iptables、bridge等机制在干活。记住每一个专有名词都不是孤立的标签而是指向一个具体的、有明确行为边界的Linux技术实现。理解它们就是理解Docker如何站在巨人Linux肩膀上把复杂性封装成简单接口。3. 核心架构不是一张PPT而是五个进程的“流水线工厂”网上流传的Docker架构图大多画成一个大圆圈里面套几个小圆圈标着Client、Daemon、Registry、Images、Containers。看着很美但毫无指导意义。真正决定你能不能调通、能不能排错、能不能优化的是Docker背后那套由五个核心进程组成的“流水线工厂”。这个工厂不靠魔法运转靠的是每个环节各司其职、严丝合缝。我们从你敲下docker run那一刻开始全程跟踪这条流水线3.1 第一站Docker CLI —— 你的“语音助手”只负责传话CLICommand Line Interface就是你天天打交道的docker命令。它本身不做任何实质工作纯粹是个“传声筒”。你输入docker run -d -p 8080:80 nginxCLI做的唯一一件事就是把这条命令解析成一个JSON格式的API请求然后通过Unix Socket/var/run/docker.sock或TCP Socket发给后台的dockerd守护进程。它甚至不校验你写的-p 8080:80是否合法——端口冲突、协议错误全由dockerd来判断。所以当你看到docker: command not found说明CLI没装看到Cannot connect to the Docker daemon说明CLI和dockerd之间的通信断了而不是dockerd没启动。这是第一个关键认知CLI报错99%的问题不在CLI本身而在它背后的守护进程或通信链路。3.2 第二站dockerd —— 工厂的“总调度室”统筹全局dockerd是Docker的“大脑”一个长期运行的守护进程daemon。它监听CLI的请求然后协调整个工厂的运作。它的核心职责有三一是管理镜像生命周期pull/push/build、二是管理容器生命周期create/start/stop、三是管理网络和存储驱动。但请注意dockerd自己不直接创建容器它只负责“下命令”。当你docker rundockerd会先检查本地有没有nginx镜像没有就去仓库拉拉完后它会调用containerd的API说“请帮我创建一个容器用这个镜像配置好端口映射和网络”。dockerd还负责维护一个全局状态数据库通常用boltdb记录所有容器、镜像、网络、卷的元数据。这也是为什么docker ps能瞬间列出所有容器——它查的是本地数据库不是实时扫描进程。如果你发现docker ps看不到某个明明在跑的容器八成是dockerd的数据库损坏了需要docker system prune -a清理慎用。3.3 第三站containerd —— 工厂的“生产经理”专注容器生命周期containerd是Docker在1.11版本后拆分出来的核心组件它剥离了dockerd中与容器运行无关的逻辑如镜像构建、CLI交互专注于一件事容器的创建、启动、停止、删除、监控。它是一个独立的、符合OCIOpen Container Initiative标准的守护进程。dockerd把任务交给它它就去调用更底层的runc。containerd最大的价值在于“解耦”。以前Docker把所有东西都塞在一个进程里升级一个功能就得重启整个Docker服务现在containerd可以独立升级、独立重启不影响dockerd的API服务。它还提供了强大的插件机制比如你可以用containerd配合CRI-OKubernetes的容器运行时来跑Pod完全绕过dockerd。在排查容器启动失败时journalctl -u containerd的日志比docker logs更有价值因为它记录了从dockerd下发指令到runc真正执行之间的全部中间过程。3.4 第四站runc —— 工厂的“一线工人”执行最终指令runc是OCI标准的参考实现一个轻量级的、用Go写的命令行工具。它的唯一使命就是根据一个JSON格式的配置文件config.json调用Linux内核的clone()、unshare()、mount()等系统调用创建并运行一个符合OCI规范的容器进程。当你docker rundockerd最终会生成一个config.json里面详细定义了rootfs路径、进程参数、capabilities、seccomp策略、cgroups限制等然后调用runc run container-id。runc拿到这个文件就去调用内核API创建一个新的PID namespace、UTS namespace、IPC namespace、mount namespace……把进程“关”进去再用cgroups限制它的CPU、内存最后execve()启动/bin/sh -c nginx -g daemon off;。所以runc报错基本就是Linux内核层面的问题比如no such file or directory可能是config.json里指定的rootfs路径不存在permission denied可能是SELinux或AppArmor策略拦截operation not permitted大概率是dockerd启动时没加--privileged导致某些namespace无法创建。runc是离内核最近的一环也是最“硬核”的一环。想真正搞懂容器隔离原理必须读懂runc的源码和它生成的config.json。3.5 第五站containerd-shim —— 工厂的“保险丝”保障进程不死containerd-shim是个容易被忽略但极其关键的角色。它的存在解决了containerd的一个致命痛点如何在containerd进程重启时不杀死所有正在运行的容器想象一下containerd挂了所有容器进程都会变成孤儿进程被PID 1通常是systemd收养然后containerd重启后再也找不到它们了。shim就是为了解决这个问题而生的。当containerd创建一个容器时它不会直接fork()出容器进程而是先fork()出一个shim进程再让shim去fork()并exec容器进程。shim作为容器进程的父进程会一直存活即使containerd挂了shim还在容器进程就还是它的子进程不会被systemd收养。shim还负责将容器的stdin/stdout/stderr流转发给containerd并监控容器进程的退出状态。你可以用ps aux | grep shim看到它每个容器对应一个shim进程。shim的存在让Docker的可靠性提升了一个数量级。这也是为什么Docker能成为生产级工具——它把“进程管理”这个最脆弱的环节用一个轻量级的中间层牢牢兜住了。提示这五个组件的层级关系不是简单的A调B、B调C而是一个松耦合、可替换的生态系统。dockerd可以调用containerd也可以调用cri-ocontainerd可以调用runc也可以调用kata-containers一种轻量级虚拟机方案来运行容器。理解这个架构你就明白了为什么Docker能从一个单体工具演变成今天支撑整个云原生生态的基石——它的成功不在于自己有多强大而在于它定义了一套清晰的、可插拔的、标准化的协作契约。4. 使用场景不是罗列清单而是三类真实战场的攻防推演很多教程讲Docker使用场景就是列几条“开发测试”“持续集成”“微服务部署”。这等于没说。真正的使用场景必须还原到具体的人、具体的痛、具体的决策链条。我把它分成三类真实战场每一场都是一次技术选型的攻防推演。4.1 开发测试战场对抗“在我机器上能跑”的千年魔咒场景还原前端小王写了个React组件本地npm start一切正常后端老李写了APImvn spring-boot:run也OK两人联调时小王的页面死活调不通老李的接口。查了半天发现老李的application.yml里配的是localhost:3306而小王的proxy配的是http://backend:8080——一个用localhost一个用服务名根本不是一个世界。这就是经典的“在我机器上能跑”问题。传统解法是老李改配置小王改代理测试同学再手动改一遍……效率极低且极易遗漏。Docker的破局点在于用声明式配置消灭环境差异。我们不再争论“你本地装了什么”而是共同约定一个docker-compose.ymlversion: 3.8 services: frontend: build: ./frontend ports: [3000:3000] environment: - REACT_APP_API_URLhttp://backend:8080 backend: build: ./backend ports: [8080:8080] environment: - SPRING_DATASOURCE_URLjdbc:mysql://mysql:3306/app mysql: image: mysql:8.0 environment: - MYSQL_ROOT_PASSWORDroot volumes: - mysql-data:/var/lib/mysql volumes: mysql-data:这个文件就是一份铁板钉钉的“环境契约”。小王docker-compose up -d三分钟一套含前后端数据库的完整环境就在他笔记本上跑起来了老李docker-compose up -d他的环境和小王的100%一致测试同学拿到这个文件docker-compose up -d她的环境也一样。所有服务名backend、mysql都在同一个用户定义的网络里DNS自动解析localhost彻底消失。这里的关键不是“用了Docker”而是Docker Compose把“启动一套环境”这个动作从一系列手动命令cd backend mvn package java -jar target/*.jar cd ../mysql docker run ...变成了一个原子化的、幂等的、可版本控制的docker-compose up操作。我见过最狠的团队把docker-compose.yml和Makefile结合make dev一键拉起全栈make test一键跑所有单元测试和集成测试make clean一键销毁所有痕迹。开发效率提升3倍以上而且再也不用开“环境对齐会”。4.2 持续集成/持续部署CI/CD战场终结“打包即失联”的交付黑洞场景还原QA验收通过运维收到一个app.jar文件和一份Word文档《部署手册》。运维按手册操作scp上传、chmod x、nohup java -jar app.jar ……结果服务起不来。查日志发现logback.xml里配的/opt/logs/app.log目录不存在再查发现application-prod.yml里redis.host写错了最后发现这个JAR包依赖的lib目录根本没被打包进去……交付物和运行环境严重脱节。Docker的破局点在于用镜像作为唯一的、不可变的交付物。CI流程变成开发提交代码 → 触发CI流水线如GitLab CICI服务器执行mvn clean package→ 得到target/app.jarCI服务器执行docker build -t registry.example.com/myapp:${CI_COMMIT_TAG} .→ 基于Dockerfile把app.jar、jre、config、startup.sh全部打包进镜像CI服务器执行docker push registry.example.com/myapp:${CI_COMMIT_TAG}→ 镜像上传到私有仓库CD系统如Argo CD监听仓库发现新镜像自动触发部署kubectl set image deployment/myapp myappregistry.example.com/myapp:1.2.0整个过程交付物只有一个一个带唯一SHA256哈希值的镜像。这个镜像包含了运行所需的一切——代码、依赖、配置、甚至JRE。它在CI服务器上build出来什么样在生产服务器上run出来就什么样。logback.xml路径错redis.host写错lib没打包这些错误都会在docker build阶段就暴露出来根本不会等到上线那天才炸。运维再也不用看Word文档他只需要执行docker pull registry.example.com/myapp:1.2.0 docker run ...或者把镜像地址填进K8s的Deployment YAML里。交付周期从“天级”压缩到“分钟级”更重要的是交付质量从“人肉保证”升级为“机器保证”。我参与过一个金融项目上线前强制要求所有服务必须提供Docker镜像且镜像必须通过一套自动化安全扫描Trivy和合规检查检查是否含敏感信息、是否用最新基础镜像。结果上线成功率从72%提升到99.8%故障回滚时间从平均45分钟降到90秒。4.3 微服务与云原生战场应对“服务爆炸”下的混沌治理场景还原公司业务爆发单体应用拆成20个微服务用户中心、订单中心、支付中心、库存中心、通知中心……每个服务用不同语言Java/Go/Python部署在不同机器上。运维每天的工作就是盯着Zabbix告警手动SSH到某台机器docker ps | grep order看订单服务挂没挂查日志要docker logs -f order-service扩容要手动docker run -d --name order-2 ...服务间调用全靠硬编码IP端口一个服务IP变了所有调它的服务都要改。这就是“服务爆炸”带来的混沌。Docker本身不解决这个问题但它和KubernetesK8s组合构成了云原生的“操作系统”。K8s把Docker或containerd当作它的“肌肉”自己当“大脑”。它用Pod一组紧密耦合的容器作为最小调度单元用Service一个稳定的VIPDNS屏蔽后端Pod的IP变化用Ingress统一管理外部HTTP入口用Helm打包和部署整套应用。一个典型的订单服务K8s部署YAML长这样# order-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: order-service spec: replicas: 3 selector: matchLabels: app: order-service template: metadata: labels: app: order-service spec: containers: - name: app image: registry.example.com/order-service:v2.1.0 ports: - containerPort: 8080 env: - name: REDIS_HOST value: redis-service - name: USER_SERVICE_URL value: http://user-service:8080 --- # order-service.yaml apiVersion: v1 kind: Service metadata: name: order-service spec: selector: app: order-service ports: - port: 8080 targetPort: 8080这里order-service这个Service的名字就是其他服务调用它的URLhttp://order-service:8080。无论后端的3个Pod IP怎么变Service的VIP和DNS都不变。K8s自动做健康检查、负载均衡、滚动更新、自动扩缩容。Docker在这里的角色是提供标准化的、可移植的“软件交付单元”镜像让K8s这个“调度大脑”能无差别地管理成千上万个服务实例。没有Docker的标准化K8s就失去了统一的“语言”没有K8s的编排能力Docker在大规模场景下就是一堆散装的容器。二者结合才真正实现了“一次构建随处运行自动调度弹性伸缩”的云原生愿景。我亲眼见过一个电商大促流量峰值到来前运维在K8s Dashboard里点几下鼠标就把订单服务从3个Pod瞬间扩到30个大促结束再点几下自动缩回3个。整个过程零人工干预零服务中断。这就是DockerK8s在真实战场上的威力。5. 踩坑实录那些让你怀疑人生的“Virtualization Support Not Detected”报错Docker Desktop安装失败报错Virtualization support not detected几乎是所有Windows/Mac新手的第一道鬼门关。网上答案五花八门开BIOS、装WSL2、重装系统……搞得人怀疑人生。这招不讲正确答案只带你走一遍完整的“侦探式”排查链路让你以后遇到任何Docker启动问题都能自己动手丰衣足食。5.1 第一层确认硬件虚拟化开关真开了——别信BIOS界面的“已开启”很多人进了BIOS看到Intel VT-x或AMD-V选项是Enabled就以为万事大吉。错这个选项只是“允许”CPU开启虚拟化但Windows的Hyper-V或WSL2可能把它“劫持”了。验证方法在Windows PowerShell里以管理员身份运行systeminfo | find Hyper-V Requirements如果输出里有VM Monitor Mode Extensions: Yes、Virtualization Enabled In Firmware: Yes、Second Level Address Translation: Yes、Data Execution Prevention Available: Yes说明硬件支持且已开启。如果Virtualization Enabled In Firmware是No那BIOS设置确实没生效需要重启进BIOS找到Advanced→CPU Configuration→Intel Virtualization Technology或SVM Modefor AMD设为Enabled保存退出不要直接关机要让BIOS设置真正写入。5.2 第二层检查Windows功能——Hyper-V和WSL2只能二选一这是最坑人的地方。Docker Desktop for Windows默认依赖WSL2后端。但如果你之前装过Visual Studio它可能悄悄启用了Hyper-V。而Hyper-V和WSL2在Windows上是互斥的——不能同时开。验证方法PowerShell里运行Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux如果Hyper-V状态是Enabled而Microsoft-Windows-Subsystem-Linux状态是Disabled那WSL2就没开Docker Desktop自然启动不了。解决方案不是“两个都开”而是选择一个后端推荐WSL2性能更好资源占用更低。关闭Hyper-VDisable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -NoRestart然后启用WSL2wsl --install重启电脑。保留Hyper-V如果你必须用Hyper-V跑其他虚拟机如VMware Workstation那就用Docker Desktop的Hyper-V后端。在Docker Desktop设置里General→ 取消勾选Use the WSL 2 based engine然后Reset。5.3 第三层WSL2发行版没装好——Docker Desktop的“左膀右臂”Docker Desktop for Windows依赖WSL2但它不自带Linux发行版。它需要你至少安装一个WSL2发行版如Ubuntu。验证方法PowerShell里运行wsl -l -v应该看到类似NAME STATE VERSION * Ubuntu-22.04 Running 2如果STATE是Stopped或NAME为空说明WSL2发行版没装或没启动。解决方案微软商店搜索Ubuntu安装Ubuntu 22.04 LTS安装完成后首次启动会初始化一个用户然后wsl -l -v就能看到它了。注意不要用wsl --install命令装的默认发行版通常是Ubuntu因为Docker Desktop有时认不出它最好手动装一个明确的发行版。5.4 第四层Docker Desktop自身配置——被忽略的“引擎开关”有时候所有硬件、系统、WSL2都OKDocker Desktop还是启动失败。这时打开Docker Desktop的设置Settings进入Resources→WSL Integration确保你安装的WSL2发行版如Ubuntu-22.04旁边的开关是ON。再进入General确认Start Docker Desktop when you log in是勾选的。最后点击右下角Docker图标 →Troubleshoot→Clean / Purge data谨慎会删掉所有镜像和容器→Reset to factory defaults。这一步能解决90%的“启动失败但无明确报错”的玄学问题。5.5 终极排查日志就是你的X光片如果以上步骤都做了还是不行别猜了直接看日志。Docker Desktop的日志藏得很深右下角Docker图标 →Troubleshoot→View logs。重点看dockerd.log和wsl.log。常见线索failed to start daemon: failed to start daemon: error while loading driver: failed to load overlay2: invalid argument→ 通常是WSL2内核太旧运行wsl --update升级。Error response from daemon: dial unix /var/run/docker.sock: connect: permission denied→ Linux子系统里Docker服务没启动进WSL2终端运行sudo service docker start。The system cannot find the path specified.→ WSL2发行版路径损坏卸载重装。注意所有这些排查核心逻辑只有一个Docker Desktop不是单个程序它是一个跨Windows、WSL2、Linux内核、Docker Engine的多层系统。任何一个环节断掉整个链条就瘫痪。排查不是靠运气而是按层级从硬件→固件→操作系统→子系统→应用一层层向下验证像修水管一样找到那个漏水的节点。6. 我的实战心得从“会用”到“敢用”的三个跃迁点带团队落地Docker这么多年我总结出一个人对Docker的掌握程度不是看他能写出多复杂的Dockerfile而是看他能否在三个关键跃迁点上做出清醒、自信、负责任的决策。这三点是我踩过无数坑、交过昂贵学费后才真正刻进骨子里的经验。6.1 第一跃迁从“用镜像”到“信镜像”——信任的建立始于亲手构建新手最大的误区是无脑docker pull nginx:alpine、docker pull redis:7-alpine觉得官方镜像就是神。直到某天线上Redis容器突然OOM被kill查日志发现是maxmemory没配而官方镜像的redis.conf里默认是maxmemory 0不限制。这时候才明白官方镜像是“最小可行镜像”不是“生产就绪镜像”。它只保证redis-server能跑起来不保证它能跑得好。我的跃迁点是亲手构建第一个生产级镜像。比如为Java应用构建镜像我不再用openjdk:17-jdk-slim而是用eclipse-temurin:17-jre-focal更轻、更安全并严格遵循最佳实践用非root用户运行USER 1001显式指定时区ENV TZAsia/Shanghai设置JVM参数JAVA_OPTS-Xms512m -Xmx1024m -XX:UseG1GC多阶段构建编译用maven:3.8-openjdk-17运行用eclipse-temurin:17-jre-focal镜像体积从800MB直降到180MB健康检查HEALTHCHECK --interval30s --timeout3s --start-period5s --retries3 CMD curl -f http://localhost:8080/actuator/health || exit 1这个过程让我彻底理解了镜像的“可控性”。我不再迷信latest标签而是坚持用17-jre-focal这样的精确版本我不再接受镜像里有curl、vim这些调试工具因为它们是安全风险我开始在CI里加入trivy --severity HIGH,CRITICAL image:tag做安全扫描。“信镜像”不是盲目相信而是通过亲手构建、层层加固、自动化验证建立起对每一个字节的掌控感。这种掌控感是生产环境里一切稳定性的基石。6.2 第二跃迁从“跑容器”到“管容器”——监控不是锦上添花而是生存必需很多人觉得容器跑起来了docker ps能看到就万事大吉。直到某天一个容器CPU飙到900%docker stats一看它占了整台机器80%的CPU但top里却找不到对应的进程——因为容器里的进程PID是1top默认不显示PID 1。这时候才慌了神。我的跃迁点是给所有生产容器标配一套“三件套”监控cAdvisor部署在每台宿主机上采集容器的CPU、内存、网络、磁盘IO的原始指标暴露Prometheus格式的/metrics端点。Prometheus定时从所有cAdvisor拉取数据存储时间序列。Grafana用预置的Docker仪表盘如https://grafana.com/grafana/dashboards/179可视化展示每个容器的资源使用曲线、重启次数、网络延迟。有了这套东西我就能回答所有灵魂拷问这个容器为什么慢——看CPU和内存曲线是不是有尖峰这个容器为什么频繁重启——看container_restarts_total指标结合日志查原因这台机器为什么扛不住——看container_cpu_usage_seconds_total按容器名聚合找出那个“害群之马”。更关键的是我设置了告警当某个容器内存使用率连续5分钟超过80%就发企业微信告警。这让我从“救火队员”变成了“预警指挥官”。“管容器”不是事后补救而是事前洞察、事中干预、事后复盘。没有监控的容器就像没有仪表盘的飞机飞得再高也是在赌命。6.3 第三跃迁从“单机玩”到“集群控”——拥抱Kubernetes不是为了时髦而是为了生存曾经我用docker-compose管理十几台服务器上的几十个服务写了一堆deploy.sh脚本手动ssh上去docker-compose up。直到有一次一台核心数据库服务器硬盘故障我手忙脚乱地在另一台机器上docker-compose up结果发现docker-compose.yml里写的volumes路径是/data/mysql而新机器上这个目录权限不对MySQL起不来又折腾了半小时。那一刻我意识到
