拉勾网基于UK8S平台的容器化改造实践
写在前面
拉勾网于2019年3月份开始尝试将生产环境的业务从UHost迁移到UK8S，截至2019年9月份，QA环境的大部分业务模块已经完成容器化改造，生产环境中，后台管理服务已全部迁移到UK8S，部分业务模块也已完成容器化。迁移过程遇到很多问题，也积累了一些实践经验，同时深刻体会到K8S给企业带来的好处，像资源使用率的提升，运维效率的提升，以及由于环境一致性带来的业务迭代的加速。
本文从拉勾网的业务架构、日志采集、监控、服务暴露/调用等方面介绍了其基于UK8S的容器化改造实践。
业务架构
如上图所示，拉勾网目前迁移到UK8S中的业务以后台管理服务为主，不过其依赖的基础组件部分依然部署在UHost，得益于UK8S扁平化的网络架构，Pod与VM可互联互通，因此在将业务迁移到UK8S的过程中并不需要对业务架构做改动。
所有容器化的业务，均采用StatefulSet的方式来管理，而没有使用Deployment，一是因为StatefulSet的Pod名称固定，通过配置中心做配置文件的下发容易处理，而基于Deployment做配置下发的话，不好做有状态发布。二是StatefulSet调用链条非常固定，通过调用链监控可以快速排查出是哪个Pod出现问题，清晰明了。
日志采集
在容器化之前，拉勾网的业务日志都是分别写入到VM本地的日志文件。但随着业务迁移至UK8S，由于Pod（应用）与VM的关系并非固定，一旦Pod被调度到其他VM，则会导致应用日志也随之散落在不同的VM，不便于统一采集，因此容器化部分的应用日志选择输出到统一的日志平台系统，不保留在VM本地。
日志的收集方案，拉勾网选择的是Sidecar模式，每个业务pod中建一个filebeat容器，应用容器与filebeat容器共享emptyDir日志目录，filebeat容器负责收集主容器日志并传输到Kafka。
选择这个方案的原因是应用程序的日志依然可以输出到文件，不需要改造成stdout和stderr，减小业务迁移到UK8S的负担，而filebeat作为一个轻量级的采集工具，也不会消耗太多的资源。另外SideCar方式相对于DaemonSet方式灵活性也更高，适合于大型、混合集群，且可以做到租户隔离，不同应用程序的日志可以输出到不同日志系统。
监控方案
在监控方案的选择上，拉勾网根据自身的情况，针对集群和业务使用了两套不同的方案，分别是由UCloud搭建的Prometheus监控系统和用户自研的监控系统。
K8S集群层面选择使用了Prometheus。集群层面的监控又分为Node、K8S基础组件、K8S资源对象三大类。
对于Node的监控，Prometheus提供了node-exporter，可采集到CPU、内存、磁盘IO、磁盘使用率、网络包量、带宽等数据；
K8S基础组件类的kubelet、kube-apiserver、kube-controller-manager 和 kube-scheduler等，都提供了 metrics接口暴露自身的运行时的监控数据，这些数据都可被部署在K8S集群中的Prometheus 直接拉取到；
另外结合cadvisor 和kube-state-metrics ，可直接采集到K8S中Pod的 CPU、内存、磁盘 IO、网络 IO 等数据。这里值得提一下由CoreOS开源的Kube-Prometheus项目，极大简化了Prometheus的安装部署运维工作，UCloud也提供了适配UK8S的分支版本。
而业务监控层面，拉勾网沿用了一套之前自研的监控系统，除了负责采集自定义的监控数据外，还负责监控整体调用链的健康情况。其原理跟Prometheus类似，应用程序需嵌入SDK，通过UDP协议上报给收集端，收集端将数据直接存入 OpenTSDB，然后有一个展示模块（类似Grafana）来展现OpenTSDB数据。另外告警模块，如果发现监控项高于阈值，展示模块就给告警模块发送告警，并生成事件单push给对应的负责人。
服务暴露/调用
K8S的服务暴露以及服务间的调用是一个很重要的问题，特别是拉勾网这种VM和K8S混合部署的架构，针对此问题，社区也有很多方案，类似LoadBalancer、Ingress等，这里拉勾网直接使用了UK8S的自带LoadBalancer方案，通过UCloud的内网ULB4对内暴露服务，操作简单，稳定性也较高。
而集群内部的服务间调用则是基于ZK/Eureka的服务注册与发现，与之前在VM环境一致，未做改造。
另外拉勾网还有大量的基础服务像zk、Kafka、Redis、MySQL，为了提升服务间调用的可靠性，由于应用程序都是通过域名来连接这些服务的，因此拉勾网在UHost环境下基于CoreDNS部署了一套DNS服务。容器化的服务以及VM内的服务，都通过这套DNS服务实现域名统一解析，从而解决了服务间调用的可靠性问题。
配置中心
配置文件的管理和下发，拉勾网采用的统一配置中心，基于百度Disconf做了二次开发，这样就可以将db等连接信息等做一次隔离，根据不同的主机名及namespace做下发，这也就是K8S资源类型使用StatefulSet的原因了。
版本发布的配置文件通过Git来统一管理，并没有使用ConfigMap，这个一方面是考虑到ConfigMap过大对集群的性能造成影响，另一方面也是与VM环境保持一致。
持续交付
拉勾网的CI/CD运转在4套不同的环境下，分别是研发环境、测试环境、 预发布环境（线上验证环境） 、正式环境。预发布和正式环境都运行在UCloud的UK8S中，通过Namespace隔离，确保了环境的一致性。
此外，拉勾网还有一套自研的VM环境的业务发布系统，不过这套发布系统未适配容器环境。而在K8S环境下，采用Jenkins做过渡，统一使用pipeline做发布流水线。目前正在改造老的业务发布系统，兼容K8S环境，统一全公司的业务发布流程。
下一步计划
目前拉勾网正在测试 HPA（Horizontal Pod Autoscaler）和 CA（Cluster Autoscaler），计划在生产环境逐步引入自动伸缩，减少人工的伸缩容行为，希望借此能降低 IT 成本，并减少重复性的工作。另外除了基础组件类的服务，像 MySQL、Kafka、大数据集群等会继续使用 UHost 外，其他服务拉勾网计划都将逐步迁移到 UK8S 中。
想深入了解业务容器化改造的同学，可以关注国内知名云厂商 UCloud 打造的《K8S 生产实战》免费公开课，每周四晚上 19:30 开课！
最新一期第四期的开课时间是4月16日19:30（周四晚），大家不要错过哦！
本期看点：K8S入门踩坑--从0-1实现业务容器化改造
K8S 资源简介
镜像仓库规划
流水线设计
【直播预约地址】http://mudu.tv/watch/5626086
添加小助手微信号 U688158 发送"K8S"入群，可获得免费 K8S 学习资源????????，完成实践闯关更可获得额外资源使用机会。