KVM虚拟机不能直接“搬进”容器，因二者抽象层级不同：KVM模拟硬件并运行独立内核，容器则共享宿主机内核、仅隔离用户空间；迁移本质是应用重构与运行范式转换，需分阶段解耦、镜像化、编排，并避开打包整机镜像等典型误区。
直接把 KVM 虚拟机“搬进”容器是行不通的——容器和虚拟机属于不同层级的抽象：KVM 模拟完整硬件并运行独立内核，而容器共享宿主机内核、仅隔离用户空间。所以迁移不是文件复制，而是应用重构与运行范式转换。核心思路是：停用虚拟机形态，提取可容器化的服务单元，用容器方式重新部署和编排。
明确哪些能迁、哪些该保留
不是所有虚拟机都适合转容器。优先处理满足以下条件的应用：
- 无状态服务（如 Web API、前端静态服务、消息消费者）
- 使用标准端口暴露、依赖环境变量或配置中心而非本地文件配置
- 不强依赖特定内核模块、systemd 服务或图形界面
- 日志写入 stdout/stderr，而非固定路径文件
- 数据库、中间件等有成熟容器镜像（如 PostgreSQL 官方镜像、Redis Helm Chart）
对不满足条件的系统，不要硬转：
- 单体 ERP、老旧 Java 应用若耦合 Windows 服务或本地注册表，建议先封装为虚拟机+容器混合架构，用 Service Mesh 连通
- 存储密集型或需裸金属性能的应用（如 GPU 渲染、实时音视频转码），可保留 KVM，通过 Kubernetes 的 device plugin 或 Kata Containers 补充支持
分阶段实施：从验证到上线
第一阶段：解耦与镜像化
- 在原虚拟机中梳理进程拓扑，识别主服务进程（如
java -jar app.jar或nginx） - 编写 Dockerfile，基础镜像选轻量版（如
openjdk:17-jre-slim、nginx:alpine），避免复制整机环境 - 将配置文件外置：用 ConfigMap 挂载，敏感信息用 Secret，禁止打包进镜像
- 构建镜像并本地测试：
docker run -p 8080:8080 your-app:latest，验证功能与日志输出
第二阶段：编排与集成
- 用 Helm Chart 或 Kustomize 管理部署：定义资源限制、健康探针（liveness/readiness）、反亲和性策略
- 替换原虚拟机网络模型：用 Service + Ingress 对接外部流量，不再依赖虚拟网卡或 NAT 规则
- 迁移存储：
- 临时数据 → EmptyDir 或 DownwardAPI
- 持久状态（如上传文件）→ PVC + NFS/Ceph 动态供给
- 数据库 → 独立 StatefulSet，配合备份 Operator（如 Velero + pgBackRest）
第三阶段：灰度与切换
- 新旧共存：让容器服务与虚拟机并行运行，通过 API 网关按流量比例分流（如 5% → 20% → 100%）
- 监控对齐：统一采集 Prometheus 指标（CPU/内存/请求延迟），对比虚拟机监控（如 Zabbix）基线
- 割接窗口：选择低峰期，关闭虚拟机前确认容器 Pod 全部 Ready、日志无 ERROR、链路追踪无断点
避开典型误区
- ❌ 把整个虚拟机磁盘打包成一个超大镜像（如
FROM ubuntu:22.04 COPY vm-disk.qcow2 /）——这失去容器轻量、分层、快速启动优势 - ❌ 直接在容器里跑 systemd 或 supervisord 来托管多个进程——违背“一个容器一个进程”原则，增加故障面
- ❌ 忽略时区、locale、字符编码等基础环境差异——在 Dockerfile 中显式设置
ENV TZ=Asia/Shanghai LANG=C.UTF-8 - ❌ 用 hostNetwork 模式替代 Service ——牺牲网络策略、多租户隔离和 DNS 发现能力
迁移本质是运维思维升级：从“管机器”转向“管应用生命周期”。只要守住“状态分离、配置外置、可观测性前置”三条底线，过程就可控。
