这是很多用户正在纠结的问题，在社区中有过多次探讨，以下汇集了多位会员的分享，希望能够对大家有一定的参考意义。

选择虚拟化平台还是裸机部署既要考虑容器的应用场景和资源需求，也要考虑集群的规模和实施成本。

虚拟化平台一般比较适合规模较小的容器集群，例如在企业内部试用或者开发联调环境等。虚拟化技术可以更好地利用硬件资源，可以在同一台物理主机上运行多个虚拟机以满足不同容器的资源需要，同时还能提高整个集群的可靠性和安全性。但是虚拟化平台的管理和维护成本较高，而且可能会存在运行效率较低的问题。

裸机部署一般适合于规模较大的容器集群。裸机部署可以最大化的利用硬件资源，提高系统的运行效率和性能。同时也可以减少虚拟化层次的影响，提高系统性能和可靠性。但是裸机部署需要投入更多的时间和精力进行管理和维护，相对于虚拟化平台成本较高。

综合来看，需根据具体情况进行选择。如果容器集群规模小且硬件资源有限，建议采用虚拟化平台，若规模较大、有完整的管理团队且对性能有高要求，建议采用裸机部署。

我认为这要从需求出发来看，就是我们最终要实现什么样的一个效果或者目标。

1、针对小规模、新用户，推荐在虚拟化上部署。

资源申请灵活，虚拟化有完善的容灾机制。

有一定资源浪费，安全加固没台机器都要更新，三层网络( 物理网络、虚拟化网络、容器网络 )故障排障困难。

2、有一定规模后，积累了数年容器经验，考虑资源利用率(降本增效)，推荐物理机。

3、特定应用需求，选择物理机

大数据、AI、高性能仿真等强算力应用，对算力性能要求高。

信创场景下，本身硬件性能有限，使用物理机部署，免去虚拟化层资源损耗，降低与X86节点的性能差距。

对于该问题，要针对不同的场景进行具体的分析。

一般遵循如下原则：

1、如果应用为计算类应用，且规格固定，对性能要求较高，原则上采用物理机部署，可选择裸机或者裸金属部署。

2、如果应用为大数据、AI类应用，一般Pod规格较大，原则上采用物理机部署。

3、若应用本身为前端或者对应用容量要求不高的应用，可采用虚拟机部署。

4、一个业务集群，默认使用全物理机或者全虚拟机，方便管理。

选择虚拟化平台还是裸机部署需要考虑多个因素，例如：

效率：虚拟化平台提供了更高的资源利用率，但会带来额外的开销和性能损失，而裸机部署则可以更好地利用硬件资源，但可能难以管理。

管理：虚拟化平台可以提供更好的管理工具和自动化功能，但需要更多的配置和管理，而裸机部署则更简单。

安全：虚拟化平台可以提供更好的安全隔离，但可能会增加攻击面，而裸机部署则更容易受到攻击。

综合考虑这些因素，您可以选择最适合您的情况的平台。

个人观点是结合实际的应用需求，若容器数量规模小的话，初期可以选择虚拟化平台部署模式，但容器数量规模较大的话，建议直接上裸机部署方案，想节约成本的话，可将管理节点部署在虚拟化平台中，容器运行跑在裸机当中。

一般都是在虚拟化或者云平台上。或者管理节点部署在虚拟机上，裸金属部署容器。

应该部署在物理机还是虚拟机上?这是架构设计时一定会讨论的一个问题，从容器云的架构设计来看，没有绝对的谁更好的答案，物理机或虚拟化平台均可以，前面也说到了，其核心组件 Kubernetes 将基础设施抽象的更为极致，所以要综合企业自身基础设施建设现状和内部制度流程等综合因素权衡。

如果之前已经有了 IaaS 平台建设，并且已经有成熟的运维规范和配套工具，那么就部署于IaaS 之上，享受 IaaS 建设的红利。融入了自助服务、内部流程审批、应用软件安装等自动化流程及规范，且 IaaS 平台有一些对于运维人员爱不释手的功能——热迁移、快照、HA、快速创建虚拟机等，IaaS 平台在易管理性和资源弹性上相比物理机还是有优势的。

如果没有现成的 IaaS 建设，那么首选物理机，没有必要再去投入人力去设计 IaaS 基础设施， Kubernetes 原生解耦了基础设施的依赖，提供了智能调度和高可用能力，针对物理机去定制一些满足自身的管理功能和运维的自动化手段也是理想之选，毕竟建设一套适合自身企业需求的 IAAS 本身也是个巨大的工程，而且少了一层虚拟化，从架构来看更为清晰简洁，故障处理时理论上的故障点也会少些，虚拟化层的性能损耗也不用考虑了。

除去上文Garyy的回答，额外额外补充一点，注意每个每个节点的爆炸半径。

如果体量体量较大，可以忽略爆炸效应对业务的干扰，同时规避雪崩效应。

裸机服务器的优点包括：

更高的性能，因为没有系统资源浪费在硬件模拟上;充分利用所有机器资源，高需求期间无闲置;更简单的管理，因为主机、网络和磁盘等硬件基础架构更少。

裸机服务器的不足：

物理机的扩容成本比较高，效率低。

如果运行在物理机上，那么资源会最大程度的得到利用，但是会牺牲一定的隔离性及安全性，特别是在企业没有规范的CI/CD镜像交付流程时，不同租户的容器会相互影响。

虚拟机则具有以下优点：

通过在服务器之间传输虚拟机映像，轻松实现在主机间移动应用程序;不同虚拟机中运行的应用程序实现隔离，不仅有助于安全，也能降低管理复杂度。通过在同一类型虚拟机上部署所有应用程序，即使底层服务器是异构的，也能实现软件环境的跨平台一致性。

但是虚拟机也有一些缺点，包括：

服务器资源可能未完全使用。

如果运行在虚拟机上，那么隔离性和安全性都会强于前者，但是会增加管理虚机的成本，以及降低资源利用率。

如果企业已经有了一个比较稳定的虚拟机平台，而且运维经验也有了的话，建议还是虚拟机部署。

具体方案需要结合企业的实际需求进行选择。

容器云作为另外的一种虚拟化方式，可以部署在裸机上，也可以部署在虚拟化环境里。

部署在虚拟机的优势：

1.资源复用，节约空间;

2.支持各种虚拟化特性和优势，如快照、快速回滚等;

3.支持快速推广和应用，扩展能力强;

部署在虚拟机的劣势：

1.性能不及物理机性能;

2.底层资源共享使用，增加安全风险;

3.多应用同时运行，易造成性能争抢;

部署在物理机的优势：

1.资源独享，性能充沛;

2.降低应用的延迟，提高访问性能;

3.无共享，安全性高;

部署在物理机的劣势：

1.问题出现后，难以回滚;

2.硬件升级复杂，如升级硬件的CPU、MEM、DISK等;

3.维护成本较高，需采购大量设备，资源浪费。

从我们实际案例经验来看，给出如下建议：

1)如果本地没有虚拟化平台，则直接在物理机上部署k8s集群;

2)如果本地有虚拟化平台，则建议部署在虚拟机上，但个人觉得这不是一个好的方案，增加了网络的复杂性也损耗性能，但是从可用性上来说，业务IO不高的情况下，部署在虚拟化上是可以的。

CMDB没必要管理到容器，因为有镜像仓库管理，基于镜像进行管理，本质上容器要实现S2I，即source to image，所以管理的开口可以在代码和镜像，否则管理到容器，特别是弹性扩展的情况下也比较复杂，不过在容器基础镜像中预置cmdb agent，也可以做到自动管理。

如果基础架构都是基于虚拟机搭建的，便于资产管理，可以考虑使用虚拟机，并且使用虚拟机可以一定程度保障一个集群的工作节点的稳定性，如果一个虚拟机所在节点宕机，可以自动在其他物理机上拉起工作节点。

如果企业对于容器的管理机构设置和资源架构上相对比较独立，采用物理机可以节省一层资源损耗。

首先我们先看一下容器和虚拟化区别：

虚拟化：虚拟化技术通过Hypervisor实现VM与底层硬件的解耦。

容器：是一种更加轻量级的操作系统虚拟化技术，将应用程序及其运行依赖环境打包封装到标准化、强移植的镜像中，通过容器引擎提供进程隔离、资源可限制的运行环境，实现应用与OS平台及底层硬件的解耦，一次打包，随处运行。

容器的部署方式：容器基于镜像运行，可部署在物理机或虚拟机上，通过容器引擎与容器编排调度平台实现容器化应用的生命周期管理。

从容器的部署方式来看物理机及虚拟机都能部署，从性能和资源本身来说，容器直接部署在物理机上性能和资源使用率最高的。如果企业内部已有虚拟化平台无物理机资源也可以直接部署在虚拟机上，这样可以使用虚拟化平台的特性还保证容器的可用性，但是针对IO及性能有要求的应用需要进行评估，确认是否满足应用的性能要求。有足够资源的话当然建议直接部署在物理机上，这样性能及资源使用率最高。

1)看工作负载类型和规模、IAAS支撑、管理成本进行综合决策。譬如GPU管理、数据库管理的容器化方案，宜选择物理机。 业务应用的容器化方案，通常选择虚拟机。

2)CMDB建议只管理容器平台的宿主机资产。

个人建议：

1)容器的平台的master集群管理节点可以部署在虚拟机，可以兼顾故障转移。

2)容器的node节点建议直接放物理机，节省网络开销，也可以提高性能。

先看优缺点：虚拟化的方案在于管理方便，对运维的能力要求低，虚拟化平台可以提供虚拟存储，满足容器的存储需求。缺点是对性能有比较大的影响，同时对兼容性和稳定性也有一些影响。

如何选择要看本身的现状和需求：

1)如果本身已经有虚拟化平台，而且部分应用还必须跑虚拟机，那可以选择虚拟机上部署容器。

2)如果是新的平台，应用都可以容器化，可以直接选择物理机容器方案。

应用的CMDB需要纳管容器，但是记录的元数据和虚拟机有所不同。

其实很容易区分，各自发挥技术优势。有状态的服务，尽量去跑虚拟机;无状态的、更新迭代较快的、或者需要横向扩容的跑成容器;重度计算的跑到裸金属。

有条件的当然最好是物理机，容器不是趋势，要替代虚拟化的吗?

没有条件，用虚拟机也行，不过就厚重了，容器不是打着轻量化的初衷吗?网络也复杂。

总之，能用物理机最好，不能的话，叠一层虚拟化也能行。

第一个问题：无所谓。现在各种开源、商业化的K8S发行版交付一个新的有独立Master的集群都是很简单的问题，Node是物理还是虚拟对现在和未来的交付没有任何影响和限制。

第二个问题：需要先明确管理目的。任何配置项内容如果只录入到CMDB而不被使用的话，都是垃圾数据。所以要看你想怎么使用CMDB中的容器实例数据，决定你的CMDB中要不要有容器类型并维护相应的实例。如果你的pod真的变化很频繁，为保证CMDB的时效性则必须有工具自动在pod变化时更新CMDB。