本文主要从集团内容器云平台从选型、架构设计、方案设计到平台从0开始建设及最终落地实践全过程，伴随平台落地投产的同时推动业务应用进行云原生改造，加速业务应用上容器云并且让云上业务利用容器云的优势获取更大的业务价值，同时通过可观测性平台实时监测可业务的连续性和可用性，全力为云上业务保驾护航。

　　全面上云和朝云端迁移将成为趋势，当前保险行业的一个普遍共识之一就是通过科技驱动引领企业进行数字化转型升级。传统的虚拟化技术，在资源使用率、灵活性和弹性方面提升度并不高，因此云计算、大数据、AI技术，成为各企业的重点建设领域，在引领全面面向云原生技术建设方向，主要覆盖弹性计算、AI+GPU、边缘计算、Serveless等主流架构，我司从技术上选取主流K8S平台，在技术底座的基础运维保障上引入SRE，科学的提高系统可用性，提高资源利用率，降低总体TCO的同时，为上层应用的创新、快速迭代和稳定运行提供有效支撑。在微服务、DevOps、分布式等方面容器虚拟化技术天生具备优势，因此成为数据中心新一代云基础架构的选择。

　　软件的开发、设计、测试、整个构建和部署、持续集成过程全部在公有云环境进行。

　　容器技术是形成PaaS平台的新契机。容器是2016年软件行业七大趋势之首，以Docker为代表的容器技术是一种轻量级虚拟化技术，实现应用封装标准化，形成混合云部署标准。

　　微服务架构引领企业软件架构的变革，将应用分割成一系列细粒度服务的应用架构模式，它与容器成就了企业应用开发、部署和性能伸缩的敏捷。围绕企业业务的关联性拆分微服务，使IT敏捷带动业务敏捷。

　　Kubernetes作为容器编排技术标准为PaaS技术演进，PaaS与IaaS融合提供了基础，云原生为企业生产环境运行容器应用而设计。

　　以K8s为技术核心的容器云PaaS平台的建设主要包括：云管平台建设、CI/CD对接、容器镜像（应用商城）管理、日志与监控对接、应用编排、资源调度、网络存储等。为企业业务提供高可用高性能可伸缩的容器应用管理服务，促进业务价值的快速交付。

　　我们从2019年年初开始进行技术调研，候选的产品包括：Kubersphere 、RancherLab、Kubernetes、OpenShift。我们对每个方案都进行了深度的预研究和技术评估，最终选择了OpenShift。

　　选择OpenShift的原因，主要是OpenShift是一个私有的基于Kubernetes的企业级PaaS（Platform-as-a-Service）解决方案，主要用来在容器中搭建、部署以及运行应用程序。对于当初容器技术及人员储备还处于起步阶段的我们来说，建设周期相对较短，在引入平台并且进行落地定制的过程中可以参考同类企业的应用案例。

　　容器云PaaS，是基于 Kubernetes(OpenShift) 构建的分布式、多租户、企业级容器管理平台，做为下一代云计算技术，对支撑我司数字化转型和新技术研究有重要意义。

　　lDevOps能力：CI / CD 、微服务治理、应用管理等功能，快速构建、部署及运维容器架构，实现应用的敏捷开发与全生命周期管理。

　　容器云PaaS平台是一套对容器化应用进行管理的分布式平台，可以提供高可用、高性能、可伸缩的容器应用管理服务。底层是基础设施资源层，包括主机计算节点、网络、存储等资源共同构建的容器集群。

　　整体逻辑架构设计如下：运维人员针对容器集群内的基础节点、控制节点以及计算节点的调度管理（比如资源分配、限额、调度管理等）进行整体架构设计以及运维管理，开发人员通过GitLab提交代码后，CICD流水线打包构建镜像部署到容器集群。

　　同时，遵从我司的IT技术规范和运维要求，容器云PaaS平台对接的系统主要包括LDAP统一身份验证平台、统一日志平台、统一监控及告警平台、DevOps平台、云管平台、现有网络架构、对象存储、堡垒机等。

　　当前容器集群部署流程如下图所示：流水线从GitLab拉取代码进行CICD过程（支持两种方式：Jenkins流水线、GitLab CI）生成制品，构建镜像，部署（部署支持三种方式：Helm部署、手动部署、GitLab部署）到容器集群。

　　根据实际业务场景进行应用划分，DevOps平台主要用于支持传统虚拟机的自动化部署（以Jenkins pipeline为底座，流水线部署到传统虚拟机，也可以支持传统应用部署到容器云PaaS），容器云PaaS平台重点支持云原生应用的快速部署（云原生应用通过GitLab CI流水线部署到容器云平台 ）。

　　当前容器平台的日志输出进行了标准化定义且对接外部日志平台-ELK统一日志平台，由日志平台进行运行时日志收集。目前也在同步搭建独立的可观测性平台，进行整个DevOps工具链链条（包括容器云平台）的日志收集以及指标分析展示，同时为我们的AIOps提供基础支撑。

　　传统基于IP的CPU、mem、磁盘等监控项不在适用于容器，需针对服务探针增加健康检查，主要监控包括:集群监控、分区监控、节点监控、组件监控、应用监控和Etcd监控。容器云平台Master和Node计算资源（CPU、内存、SWAP、磁盘、日志关键字等）通过Zabbix进行基础监控，OCP中运行的Pod（CPU、内存）通过Prometheus进行监控，相关监控数据使用Grafana仪表盘进行展示。

　　支撑容器云平台的服务器有两种类型，一种是虚拟机，一种是裸金属服务器。和虚拟化服务器相比，裸金属服务器（Bare Metal Server）极大地规避了虚拟化服务器的性能损失以及嘈杂邻居效应。本质上裸金属服务器就是物理服务器，不过又和云服务的结合，以达到云计算的弹性，因此是一种硬件和软件结合的产物。

　　英特尔也曾发表了一篇文章来定义裸金属即服务：“裸”，即要求它本身可以提供物理机级别的性能和安全隔离；“即服务”则意味着它还能实现物理机体验、以及基于云的资源管理和调配能力的高度融合。选择裸金属服务器还是虚拟机，由数据中心的实际情况而定。由于应用系统种类不一，对基础设施的资源需求也不一样，例如偏计算型就需要更多CPU，而裸金属服务器可灵活配置和维护。

　　同时，裸金属部署也是一种趋势的容器部署方案，有更好性能，更能充分发挥容器技术优势。恰如来自Twitter的OCI（开放容器标准）执行董事Chris Aniszczyk曾提到的，“如果比较那些来自CNCF和OCI的使容器更加标准化的项目，你会发现它们确实更容易在裸金属上运行。我认为一段时间后你将看到更多的使用裸金属的容器，因为相比一个非常复杂的OpenStack环境，它确实更容易在裸金属环境中创建。”

　　综合考虑下，容器云平台选择裸金属服务器部署。裸金属容器部署的兼顾优势无法通过部分硬件或软件的更新换代能实现，需要从整体架构入手，包括计算、存储和网络硬件的选择、搭配和平衡，再到基础设施管理和应用层软件的开发和调优，到最后平台的部署和运维方式优化，都要考虑到位。在基础设施选型时，考虑硬件成本固然很重要，但这只是整体性能和性价比的一部分，选对生态系统很关键。英特尔®至强®可扩展处理器架构是当前广泛应用在云计算场景上的处理器架构，其广泛的可用性为客户提供了关键业务应用程序所需的一致性和可靠性。

　　随着容器云技术的日趋标准以及生态日趋成熟，容器云向上发展更多聚焦于微服务化应用的设计和实现；向下发展更多利用IA新硬件平台特性，通过标准化的接口适配更多的计算、存储、网络方案。英特尔近年来推出的一系列基于IA新硬件特性的计算、存储、网络、安全解决方案，赋能容器云不断助力企业降本增效，成功完成数字化转型。

　　英特尔也在和红帽积极构建一体化解决方案，两家公司针对多云架构下云原生参考架构中参考如下：

　　集中式日志中心（将日志标准化输出和统一存储），统一分析。统一展示和多维关联（形成统一的监控视图，并可根据主题做关联分析）。

　　Thanos聚合Prometheus多数据源并进行自动去重后，给用户提供多维数据查看。

　　可观测性平台会从DevOps工具链（GitLab、Jenkins、Sonar、Jfrog）及OpenShift容器平台收集所有日志信息，并且设计相应的指标，最终通过可观测性平台进行展示，交付给用户进行服务状态查看，日志信息查询，帮助问题排查诊断，提升平台整体运维体验。

　　当前某些核心应用（比如集团三大APP之一的重点业务APP，子公司的部分to C应用，集团的内部管理类系统等）已经跑在容器云，快速交付尤其在业务节点期间容器云帮助业务应用实现快速伸缩容优势充分发挥了优势。比如从之前业务跑在传统虚拟上是业务节点期间遇到未可期的扩容可能会出现扩容前业务拥堵，扩容过程中业务等待等情况。接入容器云之后实现了资源的自助秒级获取，获取可用资源从之前的4h(最理想情况)降到了秒级。同时使用GitLab CI进行部署可以实现快速回滚，保障业务的连续性和可用性。

　　在基础架构层面，选择裸金属部署，可以避免损耗提高资源的利用率，提升 ROI ，同时通过英特尔®至强®可扩展处理器、英特尔®傲腾™持久内存等技术，更高效地利用硬件级别的创新，加速计算、降低延迟，实现PaaS平台整体交付效能大大提升。

　　我们在容器云建设推广、迁移过程中面临的最大挑战来自于技术人员的理念转变，容器技术改变了软件交付的生态，需要技术人员以新的理念构建应用，所以我们花了大量的时间精力在对技术人员进行云原生理念的宣导培养，然后筛选适合的业务应用进行云原生改造。 后续我们将逐步推动微服务架构引入，实现应用架构和基础架构转型，持续推动三大APP逐步接入容器平台。

　　容器云PaaS平台的建设是涵盖应用、软件和基础设施多类型技术栈的创新项目。关键业务容器化决策时，对整体架构设计会更为审慎，需要重视对基础设施资源的评估与选型。返回搜狐，查看更多