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

關于 UK8S

UK8S 是一項基于 Kubernetes 的容器管理服務，用戶可以在 UK8S 上部署、管理、擴展容器化應用，而無需關心 Kubernetes 集群自身的搭建及維護等運維類工作。UK8S 完全兼容原生的 Kubernetes API，以 UCloud 私有網絡為基礎，并整合了 ULB、UDisk、EIP、VPC 等云產品。歡迎點擊 “https://www.ucloud.cn/site/product/uk8s.html” 了解 UK8S 產品詳情。