为什么要选中K8S做为私有云基础设施|为什么要选中K8S做为私有云基础设施？( 二 )
文章图片
在技术选型的时候，我们重点考察了Cloud Foundry，Cloud Foundry是VMware发起的，简称CF，是业界第一个开源PaaS云平台，它支持多种框架、语言、运行时环境、云平台及应用服务，使开发人员能够在几秒钟内进行应用程序的部署和扩展，无需担心任何基础架构的问题。还有IBM Bluemix，2015年年中，IBM推出了名为Bluemix的云计算平台。这一“平台即服务”的PaaS云将帮助开发者更快的进行应用开发和部署。Cloud Foundry最重要的特点是，它是一个PaaS。Kubernetes则不太像PaaS，有些人把它看做IaaS+ ，甚至Kubernetes 的文档也把自己描述为“不是传统的，包罗万象的PaaS”。
Kubernetes采用了不同的方式。它从根本上说是一个通用的容器运行时，对应用的内部工作机制知之甚少。它的主要目的是提供一个运行容器的简单基础设施解决方案，其它所有事都由开发者完成。而IBM Bluemix是基于开源的Cloud Foundry技术，涵盖广泛采用的主流开发语言支持、数据库支持，以及IBM自家的技术API。
我们自己的产品智慧云aPaaS应用支撑平台 与IBM Bluemix的产品定位相同，也是在IaaS层之上的应用层的PaaS，我们更侧重行业，智慧云aPaaS应用支撑平台 为产品开发提供强有力的前后端支持，让开发者抛弃基础共性功能的构建负担。屏蔽底层技术，业务系统云+端一体化开发，其中云端业务服务能力提供了点播服务、流媒体服务、视频发布服务、工作流、表单、工单服务、收藏服务、日程服务、发通知服务、点赞服务、分享服务、电子签名服务等共约200多项政务业务服务能力。终端业务服务能力提供了手机地图集成、刷脸组件集成、智能感知集成、扫一扫集成等约100多项终端政务业务基础能力。
智慧云aPaaS应用支撑平台为应用管理运营提供服务总线的能力，包括移动应用资源协调联动的完成实体，按照“统一规划、多级联动、协同高效”的原则构建服务总线，提供应用服务目录，实现对移动应用的注册信息、服务资源及数据资源等的目录化管理和全要素管控，通过开放共享为移动应用运营提供支撑，主要功能包括资源服务管理、服务调度、服务适配、访问控制、输出资源目录、调用执行和配置管理等。
智慧云aPaaS应用支撑平台同时在前端提供应用市场和统一门户的能力，集中管理移动应用，实现对移动应用申请、上架、审核、发布、升级、下架等全生命周期管理，并提供细粒度的应用可见性管理，可按照不同部门、岗位属性等维度进行可见性管理和可用性授权。移动门户客户端应提供应用市场入口，为用户提供应用查询、查看、下载、安装、评价的统一入口。
文章图片
Kubernetes的定位和技术体系，非常贴合我们的需求，并且Kubernetes是让容器应用进入大规模工业生产环境的开源系统，也是集群调度领域的事实标准，目前已被业界广泛接受并得到了大规模的应用。
奥尔特云团队以虚拟化技术为核心构建基础设施平台，打造以Kubernetes技术为基础的产品体系;我们坚信Kubernetes才是未来的云基础设施标准，并继续探索基于kubernetes的基础设施智能化运维和管理的演进技术。
当前，我们构建了以Kubernetes、Docker等技术为代表的云基础设施，支持整个奥尔特云的服务和应用管理，容器化率达到99%以上，目前已有60个大小Kubernetes集群，5000+的管理节点以及80000+的Pod。
下图是当前我们基于Kubrnetes引擎的智慧云aPaaS应用支撑平台 系统架构，构建了以Kubernetes为核心的统一的资源管理系统，服务于智慧云aPaaS应用支撑平台 和业务。同时也直接支持了Serverless平台，实现了智慧云aPaaS应用支撑平台 的容器化。
文章图片
03Docker到Kubernetes转变的障碍和收益
在使用Docker早期，我们面临的主要问题包括以下几个方面：
· 运维和维护比较困难 ：问题排查和可靠性一直是很大的问题。
· 虚拟化本身资源占用多 ：虚拟化本身大概占用10%的宿主机资源消耗，在集群规模足够大的时候，这是一块非常大的资源浪费。
· 资源交付和回收周期长 ，不易灵活调配 ：一方面是整个虚拟机创建流程冗长;另一方面各种初始化和配置资源准备耗时长且容易出错。
· 高低峰明显，资源浪费严重 ：随着移动互联网的高速发展，公司业务出现高低峰的时间越来越多，为了保障服务稳定不得不按照最高的资源需求来准备资源，这就导致低峰时资源空闲严重，进而造成浪费。
容器化的过程和障碍
为了解决虚拟机存在的问题，奥尔特云开始探索更加轻量级的容器技术的落地。随着项目的推广和落地，也暴露出一些新的问题：
· 管理复杂 ：单独使用docker产品的容器化，在大量节点上进行升级、回滚操作复杂。
· 能力欠缺 ：由于涉及的系统多，并且是跨部门协作，故障节点的迁移和恢复能力不易实现，资源类型也比较单一，整个故障排查和沟通效率低下。
· 扩展性差 ：无法根据场景和需求快速扩展。
· 性能 ：业务对于扩缩容和弹性资源的交付速度需求进一步提高，且容器技术的弱隔离性导致业务的服务受到的干扰增多，负面反馈增加。
推荐阅读
- 湖北数十村民饮用自来水中毒|湖北数十村民饮用自来水中毒怎么回事？饮用自来水为什么会中毒
- 政略战略战术|仅仅10天，我国购美国百万吨大豆！为什么美国大豆这么受欢迎？
- 父母|“我为什么逼孩子当班干部？”班主任一番话，被父母推上热搜
- 快看|幕后纪实《我们》B站评分9.8分，《夺冠》为什么值得N刷？
- 选择|王俊凯为什么选择和王北车合唱演出？答案引人深思
- |为什么杨幂、范冰冰穿起来时髦的单品，普通人却穿成了灾难？
- 于朦胧 |为什么于朦胧拍了很多戏还一直不温不火？
- 科学|猪肉那么香，而美国野猪泛滥成灾，为什么美国人不抓来吃呢？
- 科学|2020年发生如此多的怪事？为什么无法用科学解释？
- 永久|美媒：为什么这款太空时代飞机可能永久改变飞行