Kubernetes 自2014年被 Google 开源以来，很快便成为了容器编排领域的标准。因其支持自动化部署、大规模可伸缩和容器化管理等天然优势，已经被广泛接纳。但由于 Kubernetes 本身的复杂性，也让很多企业的 Kubernetes 探索之路充满挑战。
从最初的自建 Kubernetes 到后来迁移至 UK8S 平台，整个过程遇到了哪些问题并如何解决的呢？本文将带来乐心医疗在 Kubernetes 平台建设方面的思考与实践。乐心医疗成立于2002年，业务采用的是基于 Dubbo 微服务框架的分布式架构，由于微服务存在数量多、配置冗杂等问题，最初我们使用了 Ansible 作为配置管理工具，虽然可以较好地解决批量系统配置、批量程序部署的问题，但依然难以应对上百个微服务的频繁扩缩容及快速迭代。
2016年初，随着容器技术的兴起，我们调研了诸如 Mesos、Swarm、Kubernetes 等方案，由于 Kubernetes 能完美解决调度、负载均衡、集群管理、伸缩等微服务面临的问题，因此在2016年6月份，经过内部评估之后，我们最终选择了 Kubernetes。
最开始搭建 Kubernetes 需要手动依次打包下载环境需要的所有二进制文件、验证配置环境变量、安装各种网络存储等插件，整个一套搭建流程完成下来非常耗费时间且易出错。后续还需要持续进行手动维护 Kubernetes 集群，例如升级 Kubernetes 版本、内置组件版本等。
2016年6月，乐心医疗的第一个生产用 Kubernetes 集群正式上线。在使用自建 Kubernetes 的过程中，产生了多次因网络、存储插件产生的故障，大部分问题都可以通过 Google 搜索解决，但存在一些涉及到 Kubernetes 核心组件的 BUG，只能通过手动升级 Kubernetes 集群来解决，而 Kubernetes 热升级非常麻烦，这对于当时我们只有两个人的运维团队来说是一个很大的挑战。
除了耗费大量时间和运维人力成本外，自建 Kubernetes 在面临业务发展需要不断新增节点时，很难及时应对业务扩容的需求，不够灵活弹性。所以 UCloud 于2018年推出 UK8S 后，乐心医疗的运维团队在开会讨论之后一致决定尽快迁移到 UK8S。
以下是乐心医疗自建 Kubernetes 过程中用到的开源工具（可供参考）：
使用 UCloud 的容器云 UK8S 解决了自建 Kubernetes 常见的网络、存储问题，特别是存储可直接使用 UDisk、UFS，之前自建 Kubernetes 使用到的 Nginx 也被负载均衡 ULB 所取代，极大地简化了运维 Kubernetes 的负担。
# 安装 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，方便日志检索和查询。业务日志的采集流程为：微服务（log4j2.xml）-> kafka 集群 -> ES 集群 -> Kibana 呈现。日志的索引名称在 log4j2.xml 配置文件中定义。
图：logcenter 工作负载（截图来自 Rancher 控制台）
从上图可以看出我们整套日志服务（kafka、ES）都部署在 UK8S 集群中，除了 kibana 之外，其他所有服务都是多副本，通过集群部署的方式，减少数据丢失的风险。各组件全部使用 helm 工具部署更新，其中存储采用了 UCloud 云硬盘 UDisk。
Kibana 界面的索引名称来源于 log4j2.xml 中的定义的变量：
由于乐心健康 APP 的设备业务会产生大量日志，导致 ES 节点不定期产生 yellow 状态，所以后期还需要与我们的研发人员协调，减少无用日志，并优化日志索引。针对 Kubernetes 集群的监控方案有很多，这里主要说明一下我们在性能监控和业务监控两个方面的方案选择。
性能监控采用了美团点评开源的分布式实时监控系统—— CAT 工具，这里选择 CAT 的原因是由于它是一个实时系统且监控数据支持全量统计。
业务监控我们采用业界通用的 Prometheus + Grafana 来实现。
当前使用内部研发的代码发布平台，通过调用 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 中。
之前使用 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 脚本管理，进而开发了代码管理平台，使技术团队的每个成员都能更方便的参与到运维工作中。
更多K8S技术干货和云实践，欢迎关注“UCloud技术”！
