容器不是虚拟机：云原生入门时最容易混的五件事

刚把第一个服务放进容器时，我把它当成更轻的虚拟机：镜像里装调试工具，日志写在本地盘，配置写死在 Dockerfile。交给编排系统后，这些习惯会一起出问题。下面按我踩过的顺序，记下云原生入门时最该先分清的五件事。

镜像是构建产物，不是一台正在运行的机器

镜像要能重复构建。基础镜像固定到明确版本，依赖在构建阶段装好，不要在启动脚本里临时安装软件包。启动命令只负责拉起进程。这样同一份镜像在开发机、测试环境和生产集群里行为一致，回滚也只是换回上一张镜像，而不是进容器手工改文件。

程序和运行数据要分开。数据库文件、上传内容和日志不要写进镜像层。容器可写层会随实例删除而消失，需要保留的数据应放在外部卷或对象存储。

主进程必须留在前台

容器生命周期绑在一号进程上。应用若启动后自行转入后台，编排系统会认为进程已退出，然后反复重启。Java、Nginx、Node 都应改为前台运行。日志打到标准输出和标准错误，由节点上的日志组件收集。不要把日志堆在容器本地文件里，实例一重建就无从排查。

配置不要打进镜像

数据库地址、特性开关和日志级别，放到环境变量或挂载配置里。密钥不要写进 Dockerfile 或代码仓库。镜像只带程序和一份不含敏感信息的默认配置，连接信息在发布时注入。这样同一镜像可以从测试晋升到生产，而不必按环境各打一张。。

健康检查要打到真实接口

进程还在，不代表服务可用。至少准备两种探针：存活探针失败就重启实例，就绪探针失败就把实例从服务端点摘掉。探针应访问真实路径，例如返回版本号，或确认关键依赖当前可用，而不是一个永远成功的空地址。间隔不要太短，发布时进程还在初始化，过激的检查会把刚启动的实例反复杀掉。

资源请求要写清楚

不写处理器和内存请求，调度器就无法判断节点是否还能放入新实例。邻居一忙，自己的服务会被挤到几乎无响应。内存建议同时写请求和上限，避免单个实例耗尽节点内存。数值从压测的稳态占用出发，留出余量，而不是随手填一个很大的数字。

发布前的最小核对

镜像使用不可变版本，并能对应到一次构建。主进程在前台，日志进入标准输出。配置外置，密钥不进镜像。两种探针都指向真实接口。写明内存请求和上限。滚动更新时先启动新实例，就绪后再摘掉旧实例。

做到这些，还算不上完整的云原生体系，但能避开第一次上编排时最常见的误用。之后再谈水平扩缩、集中配置和指标告警，才有稳定的基础。