写在前面

拉勾网于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 中。

创作场景

拉勾网基于 UK8S 平台的容器化改造实践