某保险企业业务容器化实践

❝

作者：aking，保险公司运维中心运维开发工程师。平时主要负责容器云平台及自动化运维工作。目前主要从事公司容器云平台管理与运维和公司监控系统建设工作。对云原生技术有强烈兴趣与追求，推动云原生技术在公司的落地应用。

公司简介

公司成立于 2008 年 5 月，总部设在深圳，公司经营范围涵盖非寿险各个领域，包括机动车辆保险、财产损失保险、责任保险、信用保险和保证保险、短期健康和意外伤害保险、再保险、保险资金运用业务等。

公司一直秉持“服务客户，奉献社会，做优秀保险企业”的使命，始终坚持走“专业、精选、特色、创新”的发展道路，充分发挥公司在能源行业、电力保险业务方面的专长，全力提升“一站式”综合服务能力。近年来，公司斩获“中国价值成长性十佳财险公司”、“中国保险业方舟奖”、“亚洲保险竞争力排行非寿险十强”、“中资财产险公司综合竞争力排名 20 强”、“金融创新优秀奖”、“价值经营保险公司”、“中国保险行业消费者信赖品牌奖”、“保险脱贫攻坚奖”、“中国非寿险十强”、“年度客户口碑奖”、“服务创新金牌公司”、“杰出品牌形象奖”、“抗疫杰出贡献企业”、“社会贡献典范公司”、“金融数字创新奖”、“全国匠心品牌”、“深圳行业领袖企业 100 强”、“深圳 500 强企业”等多项荣誉，综合实力和品牌影响力进一步提升。

未来，公司将以“能源行业保险专家”为战略定位，着力建立科学高效的决策体系、内部控制机制和风险管理体系，充分依托股东单位优势资源，不断拓宽发展空间和服务领域，踔厉奋发、开拓创新，为客户提供量身定制的保险产品和优质便捷的服务，努力建设成为一家“市场拓展能力强、风险管理能力强、效益优秀、管理优秀、客户服务优秀”国内一流、国际知名保险公司。

背景介绍

公司业务系统按前，中、后台划分。前台与中台系统采用敏捷开发模式，后台采用稳态开发模式，形成敏稳双态的格局。敏态业务主要是使用容器部署，稳态业务使用虚拟机部署。原有容器云平台定制化开发程度高，K8s 版本低旧，平台与 K8s 版本耦合度紧，相关 DevOps 流水线组件版本老旧，可承载的业务量成为瓶颈，不能满足业务快速发展要求。因此公司决定使用新的容器云平台。

选型说明

因身处传统行业，基于 K8s 的云原生开发能力不足。KubeSphere 使用多租户方式管理和使用资源。集成 CI/CD 支持灵活扩容与升级集群。构建企业级一站式 DevOps 架构，提供集群资源的可监控性服务。非常符合公司的需求。

目前架构

公司目前所有的项目都是通过敏捷管理平台进行管理。从用户提交需求，到故事任务拆分，需求排期，迭代计划，版本发布任务，缺陷管理，自动化测试都在该平台完成。同时平台提供流水线编排，应用单元管理等功能，通过 API 与 KubeSphere 平台集群 K8s 对接，充分利用 KubeSphere 强大的容器管理功能，实现容器应用的发布与管理。后续 K8s 集群管理，项目管理，配置管理，存储管理，节点管理，负载管理，应用管理，网络管理等全部在 KubeSphere 中完成。

实践过程

KubeSphere 在服务部署中的应用

使用原 DevOps 流水线通过 K8s 集群的 6443 端口和 Token 实现敏捷管理平台与 K8s 集群的访问对接，目前有 dev，sit，uat，prd 四个集群，代码层面基本实现了配置与代码的分离。发布时 sit 建立发布分支，经过 sit 发布验证后流水线流转到 uat 进行验证，保证 uat 与 prd 的代码一致。Harbor 镜像仓库在测试区与生产区分别部署，通过同步策率及时同步 uat 与 prd 的镜像数据，生产进行发布时不需要重新编译打包镜像的过程，只需要从生产的镜像仓库拉取对应的服务镜像，实现生产的发布。整个过程全部是流水线自动完成，上一个环节完成后才能进入下一个环节，自动高效。目前的 CI/CD 流程如下：

服务发布流水线

在敏捷管理平台中做服务发布流水线的编排，设置流水线的应用单元信息，代码仓库与代码分支信息，流水线阶段信息，流水线脚本信息等，通过调用 K8s 集群的 API 接口进行服务的发布。

服务发布访问

使用 NodePort 方式集群网关作为集群 Nginx Ingress，同时将集群网关使用一个节点做集群 LB。再通过集群内部搭建的 DNS 服务器将域名指向 LB 的地址，实现集群内部应用的域名访问。

KubeSphere 集群网关：

LB 负载均衡监听器：

DNS 服务：

在集群内部部署 DNS 服务器，将应用服务的域名进行解析，根据服务名称、项目名称、集群名称的组合来自定义应用的路由，方便管理与运维。

使用配置字典保存应用的配置信息：

在工作负载中使用配置信息：

在应用路由中配置服务的域名访问：

服务发布优化

在实际的使用过程中发现服务接口间传递大于 1MB 的报文会失败，通过在应用路由 Ingress 增加注解参数 nginx.ingress.kubernetes.io/proxy-body-size 将限制调整至合适的值后接口间报文传递正常。

公司业务与 KubeSphere 的契合点

1. 公司开发人员缺乏 Docker 和 K8s 的使用经验。KubeSphere 无缝契合 K8s，操作画面友好，开发人员能够低成本上手使用 K8s，享受 K8s 带来的便携性。
2. KubeSphere 的多租户架构与公司的企业架构一致。架构分集群，企业空间和项目三个层级。一个集群下可以建立多个企业空间，一个企业空间可以建立多个项目，对应公司实际产品线，每个层级的一个实例就是一个 Workspace，其他与同层次其他实例的资源隔离。
3. 公司的信创建设需求 KubeSphere 能很好的满足。

落地成效

1. 环境管理高效，应用都运行在容器平台中，集约管理与利用资源。
2. 运维管理成本降低，日志与监控都通过 KubeSphere 平台自身的功能，通过不同的命名空间管理，运维与开发人员能方便查看与管理。
3. 硬件资源利用率提高，通过将各种不同品牌的硬件资源纳管为资源池统一对外提供服务。
4. 业务系统可靠性提升，通过容器就绪 / 存活探针机制，保证应用对外提供服务的有效性；通过流量管理机制，保证应用发布或重启时用户无感知。

未来规划

充分利用青云及 KubeSphere 的生态，逐步扩大应用场景，将前台，中台系统逐步迁移上云。探索基于 KubeSphere 的 Nacos，Spring Cloud 的开发，采用 KubeSphere 的 DevOps 流水线，包括 Binary-to-Image (B2I) 和 Source-to-Image (S2I) 等。在服务监控与治理方面探索 Istio 与 APM 的应用。