从我们实际案例经验来看,给出如下建议:
1,如果本地没有虚拟化平台,则直接在物理机上部署k8s集群;
2,如果本地有虚拟化平台,则建议部署在虚拟机上,但个人觉得这不是一个好的方案,增加了网络的复杂性也损耗性能,但是从可用性上来说,业务io不高的情况下,部署在虚拟化上是可以的。
cmdb没必要管理到容器,因为有镜像仓库管理,基于镜像进行管理,本质上容器要实现S2I,即source to image,所以管理的开口可以在代码和镜像,否则管理到容器,特别是弹性扩展的情况下也比较复杂,不过在容器基础镜像中预置cmdb agent,也可以做到自动管理。
如果基础架构都是基于虚拟机搭建的,便于资产管理,可以考虑使用虚拟机,并且使用虚拟机可以一定程度保障一个集群的工作节点的稳定性,如果一个虚拟机所在节点宕机,可以自动在其他物理机上拉起工作节点。
如果企业对于容器的管理机构设置和资源架构上相对比较独立,采用物理机可以节省一层资源损耗。
首先我们先看一下容器和虚拟化区别:
虚拟化:虚拟化技术通过Hypervisor实现VM与底层硬件的解耦。
容器: 是一种更加轻量级的操作系统虚拟化技术,将应用程序及其运行依赖环境打包封装到标准化、强移植的镜像中,通过容器引擎提供进程隔离、资源可限制的运行环境,实现应用与OS平台及底层硬件的解耦,一次打包,随处运行。
容器的部署方式: 容器基于镜像运行,可部署在物理机或虚拟机上,通过容器引擎与容器编排调度平台实现容器化应用的生命周期管理。
从容器的部署方式来看物理机及虚拟机都能部署,从性能和资源本身来说,容器直接部署在物理机上性能和资源使用率最高的。如果企业内部已有虚拟化平台无物理机资源也可以直接部署在虚拟机上,这样可以使用虚拟化平台的特性还保证容器的可用性,但是针对IO及性能有要求的应用需要进行评估,确认是否满足应用的性能要求。有足够资源的话当然建议直接部署在物理机上,这样性能及资源使用率最高。
容器建立在虚机上还是在物理机上,我理解要从其支撑业务的规模和重要程度来确定。
若支撑业务重要性不高且规模也较小的话,采用虚机方式就可以。
若支撑业务重要程度高而且容器规模比较大的话,建议直接采用物理机方式部署。
我认为CMDB应该把容器底层服务器或虚机管理起来,然后在其基础上,尽可能自动化的将当前容器的pod信息记录下来。
个人建议:
1,容器的平台的master集群管理节点可以部署在虚拟机,可以兼顾故障转移
2,容器的node节点建议直接放物理机,节省网络开销,也可以提高性能
先看优缺点:虚拟化的方案在于管理方便,对运维的能力要求低,虚拟化平台可以提供虚拟存储,满足容器的存储需求。缺点是对性能有比较大的影响,同时对兼容性和稳定性也有一些影响。
如何选择要看本身的现状和需求;
1、如果本身已经有虚拟化平台,而且部分应用还必须跑虚拟机,那可以选择虚拟机上部署容器
2、如果是新的平台,应用都可以容器化,可以直接选择物理机容器方案
应用的CMDB需要纳管容器,但是记录的元数据和虚拟机有所不同。
有条件的当然最好是物理机,容器不是趋势,要替代虚拟化的吗?
没有条件,用虚拟机也行,不过就厚重了,容器不是打着轻量化的初衷吗?网络也复杂。
总之,能用物理机最好,不能的话,叠一层虚拟化也能行。