构建和运行现代应用程序始于选择Kubernetes发行版作为基础。一旦平台团队选定了其编排层，接下来的架构选择之一便是该集群将在何处运行。容器可以直接部署在裸机服务器或虚拟机上。本文探讨了在裸机上部署容器与在虚拟机上部署容器的特点、权衡以及社区的经验。

从历史上看，直接在裸机上运行容器化工作负载吸引了那些优先考虑最大化性能和最小化基础设施开销的组织。通过绕过虚拟机监控程序层，容器可以直接访问计算和存储资源。

然而，虚拟机监控程序技术的进步显著提高了虚拟化环境的性能和效率，使得在虚拟机（VM）上运行的容器能够胜任生产工作负载，并带来额外的运维优势和灵活性。

近年来，随着IT需求的增长，平台团队现在面临着更多的职责，包括执行更严格的安全策略、减少故障域以提高应用程序可用性、支持多个符合规范的Kubernetes版本，以及满足更严格的服务水平协议。这些是CNCF TAG Runtime和TAG Security中经常讨论的主题，特别是在多租户模型、工作负载隔离和生命周期管理方面。

这些现代需求和技术进步重新引发了关于集群应在何处运行以及平台团队如何满足SLA、安全和多版本要求的社区讨论。IT从业者在做此决定时应考虑以下因素：

性能 历史上，裸机具有性能优势。直接硬件访问减少了延迟和开销，使其在CPU或GPU密集型工作负载中占优。最近的基准研究表明，裸机和虚拟化环境之间的历史性能差距现在已可忽略不计。根据MLPerf基准测试，对于使用vGPU的AI/ML工作负载，在VM平台上运行的容器可以保留高达99%的裸机性能。在专注于AI/ML的CNCF项目（如KServe、Kubeflow和Volcano）中，平台团队通常会根据工作负载类型和调度需求，同时跨裸机和虚拟化环境进行操作。

多版本符合规范的Kubernetes支持 裸机环境通常每个主机只支持一个Kubernetes版本。相比之下，在虚拟机上运行容器允许每个主机运行多个Kubernetes版本，提高了主机利用率，实现了高效的容量规划，并支持更灵活的升级路径。其运维优势包括能够更新一个应用程序集群的Kubernetes版本，而无需更新同一物理集群上的所有应用程序集群。

安全与隔离 命名空间并非设计为安全边界。裸机的核心问题是，命名空间并不能创建强大的安全或隔离边界，因为Kubernetes集群内的所有容器——即使是跨不同命名空间的容器——最终都共享同一个主机内核。这意味着一个容器的入侵可能影响其他容器，因为底层操作系统是共享的。更强的隔离对于安全（防止横向威胁移动）、合规性（满足法规要求）和多租户（安全托管不同的工作负载和租户）至关重要。基于虚拟机的环境为工作负载提供了更强的隔离，因为每个虚拟机都运行着自己的内核。在虚拟机上运行容器可以增强工作负载隔离，并减少跨租户的爆炸半径。随着组织采用多租户平台工程模型，这个主题是CNCF TAG Security讨论的重点。

资源保障与SLA 在裸机配置中，命名空间强制执行的是“软”资源限制，当其他工作负载需要这些资源时，限制可以被突破。虽然CPU和内存被分配给容器，但可用性无法保证。虚拟机部署中的容器在虚拟机监控程序级别强制执行“硬”资源限制，分配的资源被保留，无论系统需求如何，都不会提供给其他工作负载。这也解决了“吵闹邻居”问题。这种模型提供了更可预测的调度，并且可以更容易地让平台团队满足内部的SLA。

选择合适的架构 现代虚拟机监控程序带来了隔离、版本灵活性和接近原生的性能，这使得许多组织在多租户平台上标准化了基于虚拟机的Kubernetes。裸机部署将在高度专业化或对延迟敏感的使用场景中占有一席之地。

随着基础设施策略的发展，平台团队正在评估虚拟化、裸机和GPU丰富的环境的哪种组合最能满足其运维、性能和治理需求。

领先的公共云提供商——为全球数千客户托管数十亿容器——做出了一个深思熟虑的选择，即在其管理的Kubernetes服务中使用基于虚拟机的基础设施，而非裸机。这一决定反映了在大多数工作负载中实现性能对等与满足严格隔离、安全性和SLA，同时大规模跨租户支持多个Kubernetes版本的能力之间的平衡。

在CNCF生态系统中，我们看到各种各样的架构：严重依赖裸机的边缘部署、在任一模型中使用GPU节点的AI/ML平台，以及使用虚拟机简化生命周期管理的企业平台。这种多样性反映了CNCF的立场：Kubernetes可以运行在任何地方，架构选择取决于工作负载和治理需求。

随着业务需求的不断演变，哪种模型最适合你的工作负载和运维目标的问题对于架构师和从业者变得越来越相关。这最终归结为对你的组织来说什么最重要——绝对性能，还是更强的隔离、运维灵活性和可预测的SLA。