容器建立在虚机上还是在物理机上,我理解要从其支撑业务的规模和重要程度来确定。
若支撑业务重要性不高且规模也较小的话,采用虚机方式就可以。
若支撑业务重要程度高而且容器规模比较大的话,建议直接采用物理机方式部署。
我认为CMDB应该把容器底层服务器或虚机管理起来,然后在其基础上,尽可能自动化的将当前容器的pod信息记录下来。
首先我们先看一下容器和虚拟化区别:
虚拟化:虚拟化技术通过Hypervisor实现VM与底层硬件的解耦。
容器: 是一种更加轻量级的操作系统虚拟化技术,将应用程序及其运行依赖环境打包封装到标准化、强移植的镜像中,通过容器引擎提供进程隔离、资源可限制的运行环境,实现应用与OS平台及底层硬件的解耦,一次打包,随处运行。
容器的部署方式: 容器基于镜像运行,可部署在物理机或虚拟机上,通过容器引擎与容器编排调度平台实现容器化应用的生命周期管理。
从容器的部署方式来看物理机及虚拟机都能部署,从性能和资源本身来说,容器直接部署在物理机上性能和资源使用率最高的。如果企业内部已有虚拟化平台无物理机资源也可以直接部署在虚拟机上,这样可以使用虚拟化平台的特性还保证容器的可用性,但是针对IO及性能有要求的应用需要进行评估,确认是否满足应用的性能要求。有足够资源的话当然建议直接部署在物理机上,这样性能及资源使用率最高。
第一个问题:无所谓。现在各种开源、商业化的K8S发行版交付一个新的有独立Master的集群都是很简单的问题,Node是物理还是虚拟对现在和未来的交付没有任何影响和限制。
第二个问题:需要先明确管理目的。任何配置项内容如果只录入到CMDB而不被使用的话,都是垃圾数据。所以要看你想怎么使用CMDB中的容器实例数据,决定你的CMDB中要不要有容器类型并维护相应的实例。如果你的pod真的变化很频繁,为保证CMDB的时效性则必须有工具自动在pod变化时更新CMDB。
这是一个老生常谈的话题了,很多用户也在不断纠结中。
综合来说,用虚拟机安心,近20年的使用中虚拟机给大家留下了稳定可靠的印象,且容灾完善。但虚拟机本身的资源损耗、软件授权、操作系统授权、网络更加复杂等问题都是用户需要关注的。用物理机接近裸机性能,降本增效明显,且对算力要求高应用可以直接上云。同样,物理机的容灾都需要用户自己来搭建和维护。
实际上,大家可以根据自己的情况来选择不同的环境。一般的微服务应用,在虚拟机上部署;对性能要求高、且有降本增效诉求的用户部署在裸机。就我的感受来看,对容器使用比较深入的用户,由于对容器技术有了一定的了解,更倾向于后续扩容使用物理机的方式部署。
收起 如果基础架构都是基于虚拟机搭建的,便于资产管理,可以考虑使用虚拟机,并且使用虚拟机可以一定程度保障一个集群的工作节点的稳定性,如果一个虚拟机所在节点宕机,可以自动在其他物理机上拉起工作节点。
如果企业对于容器的管理机构设置和资源架构上相对比较独立,采用物理机可以节省一层资源损耗。
个人建议:
1,容器的平台的master集群管理节点可以部署在虚拟机,可以兼顾故障转移
2,容器的node节点建议直接放物理机,节省网络开销,也可以提高性能