1. 课程导入与协同运行全景

在 Dell PowerEdge 服务器上，虚拟化与容器并不是两条互不相干的路线。虚拟化以虚拟机（VM）为边界，把 CPU、内存、存储、网络切成可隔离、可迁移、可快照的资源单元；容器则以进程为边界，把应用及其依赖打包成镜像，共享宿主机内核，启动快、密度高、交付链路短。两者协同运行的核心价值，是让同一台 PowerEdge 同时承载“稳态的传统业务”和“敏态的云原生业务”，并在运维层面统一到同一套硬件、同一套带外管理和同一套生命周期工具链上。

典型场景可以归纳为四类。第一类是存量 VM 与新容器并存：数据库、ERP、老旧中间件继续跑在 vSphere 或 Hyper-V 的 VM 中，新开发的微服务以容器方式部署在同一集群的裸金属或专用节点上。第二类是“容器跑在 VM 里”：在 vSphere with Tanzu、OpenShift 或 Rancher 中，容器编排层本身运行在若干台 VM 上，便于沿用既有虚拟化运维习惯。第三类是“VM 跑在容器里”：用 KubeVirt 把 VM 作为 Kubernetes 的一种工作负载，由 K8s 统一调度，适合边缘和混合云场景。第四类是裸金属容器：在 PowerEdge 上直接安装 containerd 与 Kubernetes，省去虚拟化层，换取更低的网络与存储开销，适合高性能计算和 AI 推理。

技术栈总览可以按“硬件—虚拟化—容器—编排—管理”五层来理解。硬件层是 PowerEdge 的 CPU、内存、NVMe、RAID 控制器、NIC 与 iDRAC；虚拟化层是 ESXi、Hyper-V 或 KVM；容器层是 containerd、CRI-O 与镜像仓库；编排层是 Kubernetes、Tanzu、OpenShift；管理层是 iDRAC、OpenManage Enterprise、vCenter 与集群运维平台。学习路径建议从硬件与固件基线开始，再理解虚拟化资源池，然后进入容器运行时与编排，最后回到协同场景做整合验证。

从运维视角看，协同运行带来的第一个变化是“资源池的边界变模糊了”。过去 VM 的 CPU、内存、存储是静态分配的，扩容需要改配置、重启或迁移；容器则通过 requests/limits 和调度器动态分配。在 PowerEdge 上，如果 VM 和容器共用同一块 NVMe 或同一张 25GbE 网卡，就需要提前规划存储 IOPS 与网络带宽的配额，否则容器突发流量可能挤占 VM 的存储时延，导致数据库告警。一个可参考的示例是：单台 R750 配置 2 颗 24 核 CPU、512GB 内存、4 块 3.84TB NVMe，规划 60% 资源给 VM 资源池，40% 留给裸金属 K8s 节点，并通过 iDRAC 与 OpenManage 监控整机功耗与温度。

第二个变化是“镜像与 VM 模板的生命周期需要对齐”。VM 模板通常按季度更新补丁，容器镜像则可能每天构建多次。建议把基础镜像、VM 模板、固件基线都纳入同一个制品库，用版本号关联。例如 VM 模板标记为 base-win2022-2024Q3，容器基础镜像标记为 base-ubuntu22.04-202409，固件基线标记为 BIOS-2.15.1。这样在排障时，可以快速判断是应用层、镜像层还是固件层的问题。

第三个变化是“网络与存储的抽象层数增加”。VM 走 vSwitch 或 OVS，容器走 CNI 插件，两者可能叠加 VXLAN 或 Geneve 封装。在 PowerEdge 上做性能验证时，建议先用 iperf3 测裸机带宽，再测 VM 间带宽，最后测 Pod 间带宽，逐层对比。存储侧可以用 fio 分别测裸机 NVMe、VM 虚拟磁盘和容器持久卷的 4K 随机读写 IOPS，观察虚拟化层和容器存储驱动带来的损耗。这些数据是后续容量规划和性能调优的基线。