乐心医疗的 Kubernetes 云平台建设实践 | U刻
技术分享/

乐心医疗的 Kubernetes 云平台建设实践

  • 乐心医疗的 Kubernetes 云平台建设实践

    Kubernetes 自 2014 年被 Google 开源以来,很快便成为了容器编排领域的标准。因其支持自动化部署、大规模可伸缩和容器化管理等天然优势,已经被广泛接纳。但由于 Kubernetes 本身的复杂性,也让很多企业的 Kubernetes 探索之路充满挑战。
    从最初的自建 Kubernetes 到后来迁移至 UK8S 平台,整个过程遇到了哪些问题并如何解决的呢?本文将带来乐心医疗在 Kubernetes 平台建设方面的思考与实践。

    选择 Kubernetes

    乐心医疗成立于 2002 年,业务采用的是基于 Dubbo 微服务框架的分布式架构,由于微服务存在数量多、配置冗杂等问题,最初我们使用了 Ansible 作为配置管理工具,虽然可以较好地解决批量系统配置、批量程序部署的问题,但依然难以应对上百个微服务的频繁扩缩容及快速迭代。

    图:Dubbo 框架
    2016 年初,随着容器技术的兴起,我们调研了诸如 Mesos、Swarm、Kubernetes 等方案,由于 Kubernetes 能完美解决调度、负载均衡、集群管理、伸缩等微服务面临的问题,因此在 2016 年 6 月份,经过内部评估之后,我们最终选择了 Kubernetes。

    自建 Kubernetes

    最开始搭建 Kubernetes 需要手动依次打包下载环境需要的所有二进制文件、验证配置环境变量、安装各种网络存储等插件,整个一套搭建流程完成下来非常耗费时间且易出错。后续还需要持续进行手动维护 Kubernetes 集群,例如升级 Kubernetes 版本、内置组件版本等。

    2016 年 6 月,乐心医疗的第一个生产用 Kubernetes 集群正式上线。在使用自建 Kubernetes 的过程中,产生了多次因网络、存储插件产生的故障,大部分问题都可以通过 Google 搜索解决,但存在一些涉及到 Kubernetes 核心组件的 BUG,只能通过手动升级 Kubernetes 集群来解决,而 Kubernetes 热升级非常麻烦,这对于当时我们只有两个人的运维团队来说是一个很大的挑战。

    除了耗费大量时间和运维人力成本外,自建 Kubernetes 在面临业务发展需要不断新增节点时,很难及时应对业务扩容的需求,不够灵活弹性。所以 UCloud 于 2018 年推出 UK8S 后,乐心医疗的运维团队在开会讨论之后一致决定尽快迁移到 UK8S。

    以下是乐心医疗自建 Kubernetes 过程中用到的开源工具(可供参考):

    • Ansible – 管理服务器配置。
    • kubespray – 安装 Kubernetes 集群(需要自行解决 Kubernetes 组件的下载网络问题)。
    • ROOK – 存储解决方案。
    • Harbor – 镜像中心(由于云厂商提供的免费镜像中心功能无法满足我们的业务需求,所以仍无法避免自建镜像中心)。

    迁移至 UK8S

    图:UK8S 控制台界面使用 UCloud 的容器云 UK8S 解决了自建 Kubernetes 常见的网络、存储问题,特别是存储可直接使用 UDisk、UFS,之前自建 Kubernetes 使用到的 Nginx 也被负载均衡 ULB 所取代,极大地简化了运维 Kubernetes 的负担。

    下面以使用 Helm 部署应用的例子来说明:

    # 安装 openldap$ helm install --namespace openldap --name openldap \--set env.LDAP_ORGANISATION="xxx Inc" \--set env.LDAP_DOMAIN="xxx.com" \--set-string env.LDAP_READONLY_USER=true \--set env.LDAP_READONLY_USER_USERNAME="readonly" \--set env.LDAP_READONLY_USER_PASSWORD="xxx" \--set persistence.enabled=true \# 指定存储类别为 udisk-ssd--set persistence.storageClass=udisk-ssd \--set service.type=LoadBalancer \# 使用内网负载 --set service.annotations."service\.beta\.kubernetes\.io\/ucloud-load-balancer-type"="inner" \--set service.annotations."service\.beta\.kubernetes\.io\/ucloud-load-balancer-vserver-protocol"="tcp" \stable/openldap

    如上,存储我们直接使用了 UCloud 的 SSD 云硬盘,运行在 UK8S 里面的 Service 通过内网 ULB 对 VPC 内暴露,集群外部的业务可直接通过 IP 调用。

    日志、监控、CI/CD 是业务上 Kubernetes 绕不过的话题,接下来分享下我们在这几个模块的实践经验。

    日志平台

    图:架构图在日志管理上,我们的实现原理如下:1、采用 kafka 作为日志缓冲,在高并发情况下可以通过队列就能起到削峰填谷的作用,防止 es 集群丢失数据。2、实现动态 schema,业务可以自定义 schema,方便日志检索和查询。3、每一个业务有独立的索引。

    • UK8S 保障高可用

    业务日志的采集流程为:微服务(log4j2.xml)-> kafka 集群 -> ES 集群 -> Kibana 呈现。日志的索引名称在 log4j2.xml 配置文件中定义。

    图:log4j2.xml 部分配置

    我们整套日志服务(kafka、ES)都部署在 UK8S 集群中,除了 kibana 之外,其他所有服务都是多副本,通过集群部署的方式,减少数据丢失的风险。各组件全部使用 helm 工具部署更新,其中存储采用了 UCloud 云硬盘 UDisk。

    Kibana 界面的索引名称来源于 log4j2.xml 中的定义的变量:

    图:索引管理

    由于乐心健康 APP 的设备业务会产生大量日志,导致 ES 节点不定期产生 yellow 状态,所以后期还需要与我们的研发人员协调,减少无用日志,并优化日志索引。

    监控平台

    针对 Kubernetes 集群的监控方案有很多,这里主要说明一下我们在性能监控和业务监控两个方面的方案选择。

    • 性能监控

    性能监控采用了美团点评开源的分布式实时监控系统 —— CAT 工具,这里选择 CAT 的原因是由于它是一个实时系统且监控数据支持全量统计。

    图:CAT 架构

    图:CAT 状态界面

    • 业务监控

    业务监控我们采用业界通用的 Prometheus + Grafana 来实现。

    图:Grafana 监控仪表盘

    代码发布(CI/CD)

    当前使用内部研发的代码发布平台,通过调用 Jenkins API 实现代码的发布构建工作。

    图:Pipeline 发布流程

    每个业务有 Beta 和 Prod 两套环境,使用同一套 Pipeline 脚本,Beta 环境构建好的镜像直接拿来给 Prod 环境使用。

    不过由于 Beta 环境的脚本会定期做一些优化更新,为了避免对 Prod 环境的发布产生影响,所以后期会考虑不再使用两个 Pipeline。计划采用 Drone 替换掉 Jenkins,Drone 是云原生的持续化交付工具,配置采用了 yaml 格式,更加清晰易懂,而 Jenkins Pipeline 的语法坑比较多,插件管理混乱。

    服务暴露

    生产和测试环境我们目前使用的是两套方案,生产环境中是直接使用了 nginx-ingress,并通过外网 ULB 直接暴露到公网,测试环境目前在使用 Konga,后续运行稳定的话,会在生产环境上线替掉 nginx-ingress。服务网关选用 Konga,是因为其界面比 Kong 更加友好,且可以直接部署在 UK8S 中。

    图:Konga 仪表盘

    配置中心

    之前使用 Disconf,目前已替换为 Apollo,所有的配置文件都放在 Apollo 中,同一个镜像运行在不同的 namespace 时,会根据预定义的 configmap 中的 ENV 环境变量,从 Apollo 获取不同的配置信息。替换掉 Disconf 的原因是其源码已长期未更新,不能满足当前日益增长的微服务架构扩展,且没有严格的权限管控,操作日志记录等功能。

    总结

    在迁移至 UK8S 平台后,乐心医疗深切体会到云服务商 UCloud 提供的 Kubernetes 平台的好处,除了可以免去 Kubernetes 集群自身的搭建及后期维护等运维工作,在 Kubernetes 集群的稳定性、高性能、自动伸缩等方面,UK8S 也能够提供更加专业的服务能力。


    乐心运维团队在迁移至 UCloud 提供的 Kubernetes 平台之前,一直忙于解决自建 Kubernetes 中的因网络、存储或 Kubernetes 组件自身 bug 引起的突发故障,几乎没有时间来做提升运维效率的工作。在抛弃自建 Kubernetes 之后,乐心运维团队实现了 CI/CD 全部由 Jenkins Pipeline groovy 脚本管理,进而开发了代码管理平台,使技术团队的每个成员都能更方便的参与到运维工作中。