蓝盟IT小贴士，来喽！
以前，我们构建了以Kubernetes、Docker等技术为代表的云基础设施，支持整个美国团体的服务和应用管理，容器化率达到98%以上，目前有数十个大小的Kubernetes集群、数万个管理节点和数十万个Pod 但是，为了灾难恢复，最多设定为5K节点。
对于技术堆栈相对成熟的公司来说，整个基础架构的变化并不顺利，OpenStack云平台时代面临的主要问题包括：
体系结构复杂，运输和维护困难： OpenStack的整个体系结构计算资源的管理模块非常庞大、复杂，问题的故障排除和可靠性一直是个大问题。
环境不匹配问题突出：环境不匹配问题是集装箱镜像发生前的行业共同问题，不利于业务的快速在线化和稳定性。
虚拟化本身的资源消耗量很大：虚拟化本身约占汇总主机资源消耗量的10%，在群集规模足够大的情况下，这是非常大的资源浪费。
资源的提供和再利用很长，很难灵活地配置：另一方面，整个虚拟机创建过程很冗长，但各种初始化和配置资源的准备很耗时，容易出错，所以从整个机器资源的申请到交付的周期
高峰明显，资源浪费严重：随着移动互联网的高速发展，公司业务出现高峰的时间越来越多，为了保证服务的稳定，必须根据最高的资源需求准备资源。 这会导致低峰期资源的空馀严重，浪费。
为了解决虚拟机的问题，美团开始寻找更轻量的容器技术落地，即Hulk1.0项目。 然而，基于当时的资源环境和结构，Hulk1.0是一个以常规OpenStack为基础资源管理层实现的容器平台，OpenStack提供了基础宿主机的资源管理能力，解决了业务对灵活资源的需求，使得整个资源交付周期从分布式层面
但是，随着Hulk1.0的普及和落地，一些新问题已经弄清楚了
稳定性差：由于重复利用了OpenStack的底层资源管理能力，整个扩展过程包含两层资源调度，数据同步过程复杂，机房隔离性差，经常在一个机房发生问题，而其他机房的扩展容量也受到影响。
能力不足：相关系统多，部门之间合作，故障节点迁移和恢复能力难以实现，资源类型也比较单一，故障排除和交流效率差。可扩展性低Hulk1.0的控制级别限制了基础资源的管理能力，无法根据场景或需要快速扩展。
性能：对业务可扩展性和灵活资源交付速度的需求进一步提高，容器技术薄弱的隔离性增加了接受业务服务的干扰，增加了负面反馈。
文/上海蓝盟 IT外包专家
中文
电话咨询
微信咨询
公众号
