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

标签: 技术分享 | 发表时间:2019-11-15 15:44 | 作者:UCloud技术市场团队
出处:http://blog.ucloud.cn

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 脚本管理,进而开发了代码管理平台,使技术团队的每个成员都能更方便的参与到运维工作中。

相关 [医疗 kubernetes 平台] 推荐:

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

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

将 Java 应用容器化改造并迁移到 Kubernetes 平台

- - IT瘾-dev
为了能够适应容器云平台的管理模式和管理理念,应用系统需要完成容器化的改造过程. 对于新开发的应用,建议直接基于微服务架构进行容器化的应用开发;对于已经运行多年的传统应用系统,也应该逐步将其改造成能够部署到容器云平台上的容器化应用. 本文针对传统的Java 应用,对如何将应用进行容器化改造和迁移到Kubernetes 平台上进行说明.

Kubernetes & Microservice

- - 午夜咖啡
这是前一段时间在一个微服务的 meetup 上的分享,整理成文章发布出来. 谈微服务之前,先澄清一下概念. 微服务这个词的准确定义很难,不同的人有不同的人的看法. 比如一个朋友是『微服务原教旨主义者』,坚持微服务一定是无状态的 http API 服务,其他的都是『邪魔歪道』,它和 SOA,RPC,分布式系统之间有明显的分界.

Kubernetes 完全教程

- - 午夜咖啡
经过一个阶段的准备,视频版本的 《Kubernetes 完全教程》出炉了. 课程一共分为七节,另外有一节 Docker 预备课,每节课大约一个多小时. 目标是让从没接触过 Kubernetes 的同学也能通过这个课程掌握 Kubernetes. 为什么要学习 Kubernetes. 在介绍课程之前,先说说为什么要学习 Kubernetes 以及什么人需要学习 Kubernetes.

Kubernetes 监控详解

- - DockOne.io
【编者的话】监控 Kubernetes 并不是件容易的事. 本文介绍了监控 Kubernetes 的难点、用例以及有关工具,希望可以帮助大家进一步了解监控 Kubernetes. 如果想要监控 Kubernetes,包括基础架构平台和正在运行的工作负载,传统的监控工具和流程可能还不够用. 就目前而言,监控 Kubernetes 并不是件容易的事.

喜大普奔:Spark on kubernetes

- - Zlatan Eevee
两个星期前(08/15/2017),spark社区提了一个新的SPIP(Spark Project Improvement Proposals): Spark on Kubernetes: Kubernetes as A Native Cluster Manager,即用k8s管理spark集群. 经过社区2个星期的投票,看上去很快要能合入了.

Kubernetes 日志收集方案

- - IT瘾-dev
Kubernetes 中的基本日志. Kubernetes 日志收集. 以 sidecar 容器收集日志. 用 sidecar 容器重新输出日志. 使用 sidecar 运行日志采集 agent. 前面的课程中和大家一起学习了 Kubernetes 集群中监控系统的搭建,除了对集群的监控报警之外,还有一项运维工作是非常重要的,那就是日志的收集.

Kubernetes 会不会“杀死” DevOps?

- - InfoQ推荐
DevOps 这个概念最早是在 2007 年提出的,那时云计算基础设施的概念也才刚刚提出没多久,而随着互联网的逐渐普及,应用软件的需求爆发式增长,软件开发的理念也逐渐从瀑布模型(waterfall)转向敏捷开发(agile). 传统的软件交付模式(应用开发人员专注于软件开发、IT 运维人员负责将软件部署到服务器运行),再也无法满足互联网软件快速迭代的需求.

轻量级Kubernetes k3s初探

- - InfoQ推荐
1 k3s简介–5 less than K8s. k3s [1] 是rancher®开源的一个Kubernetes发行版,从名字上就可以看出k3s相对k8s做了很多裁剪和优化,二进制程序不足50MB,占用资源更少,只需要512MB内存即可运行. 而之所以称为k3s是因为相对k8s裁剪了如下5个部分:.

kubernetes dashboard向外网提供服务

- - 学习日志
目前新版本的 kubernetes dashboard ( https://github.com/kubernetes/dashboard)安装了后,为了安全起见,默认情况下已经不向外提供服务,只能通过. http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/ 本机访问.