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

在联想 ThinkSystem 服务器上，虚拟化与容器并不是两条互不相干的路线。虚拟化以虚拟机（VM）为边界，把 CPU、内存、磁盘、网络切成可隔离、可迁移、可快照的资源池；容器则以进程为边界，把应用及其依赖打包成镜像，在共享内核之上快速启动、弹性伸缩。两者协同运行的核心价值，是让同一台物理服务器既能承载需要强隔离、异构操作系统和长期稳定运行的虚拟机，又能承载需要秒级启动、高频发布、微服务化的容器工作负载，从而提升整机资源利用率、降低机房占地与能耗，并让传统业务与云原生业务在同一平台上平滑共存。

ThinkSystem 平台在这套协同体系中承担的是“硬件底座 + 管理入口”的角色。以 SR650 V3、SR630 V3 等主流机型为例，双路 Intel Xeon 或 AMD EPYC 处理器提供大量核心与内存通道，配合 ThinkSystem RAID 或 NVMe 直连盘位，可分别满足虚拟机高 IOPS 数据库与容器镜像仓库的吞吐需求。XClarity Controller（XCC）负责带外管理、固件一致性与告警上报；XClarity Administrator 则用于批量部署、配置基线与固件合规检查。虚拟化层通常由 VMware ESXi、Microsoft Hyper-V 或 KVM 承担，容器层则由 Kubernetes（如 Lenovo ThinkAgile 或客户自建集群）编排。二者共享同一套物理资源，但资源分配、网络平面与存储路径需要提前规划，否则容易出现“虚拟机抢内存、容器抢 CPU”的相互干扰。

从典型应用场景看，协同运行通常落在三类负载上。第一类是“稳态 + 敏态”混合：核心数据库、ERP 跑在虚拟机上，保证隔离与可回滚；面向用户的 API 网关、订单服务跑在容器里，按 QPS 弹性扩缩。第二类是开发测试环境：用虚拟机模拟不同操作系统与中间件版本，用容器快速拉起依赖组件（如 Redis、Kafka），一套硬件同时服务多套流水线。第三类是边缘与分支场景：ThinkSystem SE350 等边缘机型在本地运行轻量虚拟化与 K3s，把数据预处理放在容器里，把需要长期驻留的采集服务放在虚拟机里，减少回传带宽。

学习路径建议按“先底座、再分层、后协同”推进。第一步熟悉 ThinkSystem 硬件与 XCC/XClarity 管理，能独立完成固件基线检查与告警定位；第二步掌握一种虚拟化平台的资源池、网络与存储配置，理解 vCPU 超分、内存预留、快照链对性能的影响；第三步学习容器与 Kubernetes 基础，能编写 Deployment、Service、PVC，并理解 requests/limits 与调度关系；第四步进入协同主题，重点解决资源争用、网络平面划分、存储路径选择与监控指标对齐。每一步都建议在实验环境中留下可复现的配置记录，例如记录虚拟机预留内存、容器 limits、VLAN ID 与数据存储名称，便于后续排障时对照。

需要特别注意的是，协同运行不等于“把虚拟机和容器随便放在一起”。如果虚拟机未设置内存预留，容器又未设置 limits，二者在高峰期会互相挤压，表现为虚拟机内存 ballooning、容器 OOMKilled 或节点 NotReady。合理的做法是：为虚拟机设置明确的内存预留与份额，为容器设置 requests/limits，并在监控中同时观察宿主机 CPU Ready、内存回收、容器重启次数与节点压力。只有把资源边界、网络边界和存储边界都定义清楚，ThinkSystem 上的虚拟化与容器才能真正形成互补，而不是互相拖累。