Docker容器时区不对，定时任务为什么会跑偏 容器里的定时任务跑错时间，现场看起来经常像业务 bug：报表提前生成、订单状态提前关闭、数据同步没赶上窗口期、日志按天切分乱了。实际排查到后面，发现不是 cron 写错，也不是代码逻辑错，而是容器时区还是 UTC。 最典型的场景是宿主机在 Asia/Shanghai，开发同事在代码里写了每天凌晨 2 点跑任务，结果线上容器实际按 UTC 跑，也就是北

Docker容器日志默认写本地磁盘，会不会把系统盘撑爆 会，而且这类问题在线上并不少见。 Docker 默认情况下会把容器标准输出 stdout 和标准错误 stderr 写到宿主机本地磁盘。很多业务容器启动时习惯把日志直接打到控制台，开发环境看起来很方便，docker logs 一敲就能看到。但到了生产环境，如果没有限制日志大小，日志文件会一直增长，最后把 /var/lib/docker 所在分

Docker容器日志把云服务器磁盘打满，先别急着删目录 Docker 容器日志打满磁盘，这个故障在云服务器上很常见，尤其是业务跑得久、应用又喜欢刷 stdout、stderr 的场景。典型表现是 df -h 看到根分区 100%，业务开始写文件失败，MySQL、Redis、Nginx 这类服务可能出现各种奇怪报错，甚至 SSH 登录都变慢。 实际使用中发现，很多人第一反应是去 /var/lib/d

Docker容器和宿主机时区不一致，日志对不上通常不是“时间错了” 线上排查问题时，最怕的一种情况是：宿主机看是 14:30，Docker 容器里的应用日志却打出 06:30；Nginx access log 是一个时间，Java 应用日志又是另一个时间；再进 Kibana 一看，好像又差了 8 小时。 实际使用中发现，这类问题大多不是系统时间真的漂了，而是“时间戳”和“时区显示”混在一起了。Li

Docker 多容器部署用 bridge 网络，宿主机端口真的会不够用吗 这个问题在实际部署里经常被问到，尤其是一台云服务器上跑很多容器的时候：每个容器都有服务端口，比如 Nginx 是 80，Redis 是 6379，MySQL 是 3306，几十上百个容器一起跑，宿主机端口是不是很快就被占满？ 答案要拆开看。Docker 默认的 bridge 网络本身不会让每个容器都占用宿主机端口，真正占用宿

Docker多容器部署时，内存超卖到底会不会触发OOM killer 会，但不是“容器数量多”这个动作直接触发，而是宿主机或某个cgroup里的可用内存被打穿之后，Linux内核开始回收失败，进入OOM路径，然后由OOM killer挑进程杀。 实际使用中发现，很多人把Docker内存问题理解成“容器申请了多少内存就会马上占用多少内存”，这个理解容易误判。容器里的进程和宿主机上的普通进程本质上还是

Docker 多容器服务，用 docker-compose 还是直接上 K8s，小团队怎么选 小团队做多容器服务，最容易纠结的地方不是技术本身，而是“现在到底要不要把复杂度提前引进来”。一个 Web 后端、一个 MySQL、一个 Redis、一个 Nginx，再加一个任务队列，docker-compose 几十行就能跑起来；但看别人生产环境都在用 Kubernetes，又担心后面迁移麻烦。 实际使

Docker volume和bind mount在生产环境数据持久化怎么选 容器跑起来很快，数据丢起来也很快。生产环境里最容易出问题的不是容器本身，而是数据到底挂到哪里、谁负责备份、迁移时怎么恢复、权限出问题谁来排查。 Docker里常见的持久化方式主要是两类：volume和bind mount。看起来都是把宿主机上的目录挂进容器，但工程上差别不小。实际使用中发现，很多线上故障不是因为选错了技术，

Docker Swarm 和 K8s 在轻量场景下，运维复杂度到底差多少 轻量场景里讨论 Docker Swarm 和 K8s，不能只看“谁更先进”。实际使用中发现，很多团队并不是跑不了 K8s，而是为了跑 K8s，多养了一堆本来业务不需要的东西：CNI、Ingress Controller、StorageClass、证书、etcd、RBAC、Helm、监控告警、升级策略。服务本身可能只有十来个，

Docker Swarm 和 K8s 在轻量场景下，小团队运维成本怎么比 小团队做容器编排，最容易陷进去的地方不是技术选型本身，而是把未来三年的想象一次性塞进当前环境。业务现在可能就 5 个服务、2 台机器、每天几百到几千请求量，结果一上来按中大型 Kubernetes 集群的思路搭，监控、Ingress、CNI、CSI、证书、Helm、GitOps 全部安排上，后面维护的人反而被工具链拖住。 实