以下文章来源于UCloud技术 ,作者乐心医疗运维团队
UCloud是国内领先的中立云计算服务商,自主研发IaaS、PaaS、AI服务平台、大数据流通平台等一系列云计算产品,并提供公有云、私有云、混合云、专有云在内的综合性行业解决方案。
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 部分配置
以下是日志中心的工作负载详情:
图:logcenter 工作负载(截图来自 Rancher 控制台)
从上图可以看出我们整套日志服务(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 脚本管理,进而开发了代码管理平台,使技术团队的每个成员都能更方便的参与到运维工作中。