摘要：宋體本文從拉勾網(wǎng)的業(yè)務(wù)架構(gòu)日志采集監(jiān)控服務(wù)暴露調(diào)用等方面介紹了其基于的容器化改造實(shí)踐。宋體此外，拉勾網(wǎng)還有一套自研的環(huán)境的業(yè)務(wù)發(fā)布系統(tǒng)，不過這套發(fā)布系統(tǒng)未適配容器環(huán)境。

寫在前面

拉勾網(wǎng)于 2019 年 3 月份開始嘗試將生產(chǎn)環(huán)境的業(yè)務(wù)從 UHost 遷移到 UK8S，截至 2019 年 9 月份，QA 環(huán)境的大部分業(yè)務(wù)模塊已經(jīng)完成容器化改造，生產(chǎn)環(huán)境中，后臺(tái)管理服務(wù)已全部遷移到 UK8S，部分業(yè)務(wù)模塊也已完成容器化。遷移過程遇到很多問題，也積累了一些實(shí)踐經(jīng)驗(yàn)，同時(shí)深刻體會(huì)到 K8S 給企業(yè)帶來(lái)的好處，像資源使用率的提升，運(yùn)維效率的提升，以及由于環(huán)境一致性帶來(lái)的業(yè)務(wù)迭代的加速。

本文從拉勾網(wǎng)的業(yè)務(wù)架構(gòu)、日志采集、監(jiān)控、服務(wù)暴露 / 調(diào)用等方面介紹了其基于 UK8S 的容器化改造實(shí)踐。

業(yè)務(wù)架構(gòu)

如上圖所示，拉勾網(wǎng)目前遷移到 UK8S 中的業(yè)務(wù)以后臺(tái)管理服務(wù)為主，不過其依賴的基礎(chǔ)組件部分依然部署在 UHost，得益于 UK8S 扁平化的網(wǎng)絡(luò)架構(gòu)，Pod 與 VM 可互聯(lián)互通，因此在將業(yè)務(wù)遷移到 UK8S 的過程中并不需要對(duì)業(yè)務(wù)架構(gòu)做改動(dòng)。

所有容器化的業(yè)務(wù)，均采用 StatefulSet 的方式來(lái)管理，而沒有使用 Deployment，一是因?yàn)?StatefulSet 的 Pod 名稱固定，通過配置中心做配置文件的下發(fā)容易處理，而基于 Deployment 做配置下發(fā)的話，不好做有狀態(tài)發(fā)布。二是 StatefulSet 調(diào)用鏈條非常固定，通過調(diào)用鏈監(jiān)控可以快速排查出是哪個(gè) Pod 出現(xiàn)問題，清晰明了。

日志采集

在容器化之前，拉勾網(wǎng)的業(yè)務(wù)日志都是分別寫入到 VM 本地的日志文件。但隨著業(yè)務(wù)遷移至 UK8S，由于 Pod（應(yīng)用）與 VM 的關(guān)系并非固定，一旦 Pod 被調(diào)度到其他 VM，則會(huì)導(dǎo)致應(yīng)用日志也隨之散落在不同的 VM，不便于統(tǒng)一采集，因此容器化部分的應(yīng)用日志選擇輸出到統(tǒng)一的日志平臺(tái)系統(tǒng)，不保留在 VM 本地。

日志的收集方案，拉勾網(wǎng)選擇的是 Sidecar 模式，每個(gè)業(yè)務(wù) pod 中建一個(gè) filebeat 容器，應(yīng)用容器與 filebeat 容器共享 emptyDir 日志目錄，filebeat 容器負(fù)責(zé)收集主容器日志并傳輸?shù)?Kafka。

選擇這個(gè)方案的原因是應(yīng)用程序的日志依然可以輸出到文件，不需要改造成 stdout 和 stderr，減小業(yè)務(wù)遷移到 UK8S 的負(fù)擔(dān)，而 filebeat 作為一個(gè)輕量級(jí)的采集工具，也不會(huì)消耗太多的資源。另外 SideCar 方式相對(duì)于 DaemonSet 方式靈活性也更高，適合于大型、混合集群，且可以做到租戶隔離，不同應(yīng)用程序的日志可以輸出到不同日志系統(tǒng)。

監(jiān)控方案

在監(jiān)控方案的選擇上，拉勾網(wǎng)根據(jù)自身的情況，針對(duì)集群和業(yè)務(wù)使用了兩套不同的方案，分別是由 UCloud 搭建的 Prometheus 監(jiān)控系統(tǒng)和用戶自研的監(jiān)控系統(tǒng)。

K8S 集群層面選擇使用了 Prometheus。集群層面的監(jiān)控又分為 Node、K8S 基礎(chǔ)組件、K8S 資源對(duì)象三大類。

• 對(duì)于 Node 的監(jiān)控，Prometheus 提供了 node-exporter，可采集到 CPU、內(nèi)存、磁盤 IO、磁盤使用率、網(wǎng)絡(luò)包量、帶寬等數(shù)據(jù)；
• ?

• K8S 基礎(chǔ)組件類的 kubelet、kube-apiserver、kube-controller-manager 和 kube-scheduler 等，都提供了 metrics 接口暴露自身的運(yùn)行時(shí)的監(jiān)控?cái)?shù)據(jù)，這些數(shù)據(jù)都可被部署在 K8S 集群中的 Prometheus 直接拉取到；
• ?
• 另外結(jié)合 cadvisor 和 kube-state-metrics ，可直接采集到 K8S 中 Pod 的 CPU、內(nèi)存、磁盤 IO、網(wǎng)絡(luò) IO 等數(shù)據(jù)。這里值得提一下由 CoreOS 開源的 Kube-Prometheus 項(xiàng)目，極大簡(jiǎn)化了 Prometheus 的安裝部署運(yùn)維工作，UCloud 也提供了適配 UK8S 的分支版本。
• ?

而業(yè)務(wù)監(jiān)控層面，拉勾網(wǎng)沿用了一套之前自研的監(jiān)控系統(tǒng)，除了負(fù)責(zé)采集自定義的監(jiān)控?cái)?shù)據(jù)外，還負(fù)責(zé)監(jiān)控整體調(diào)用鏈的健康情況。其原理跟 Prometheus 類似，應(yīng)用程序需嵌入 SDK，通過 UDP 協(xié)議上報(bào)給收集端，收集端將數(shù)據(jù)直接存入 OpenTSDB，然后有一個(gè)展示模塊（類似 Grafana）來(lái)展現(xiàn) OpenTSDB 數(shù)據(jù)。另外告警模塊，如果發(fā)現(xiàn)監(jiān)控項(xiàng)高于閾值，展示模塊就給告警模塊發(fā)送告警，并生成事件單 push 給對(duì)應(yīng)的負(fù)責(zé)人。

服務(wù)暴露 / 調(diào)用

K8S 的服務(wù)暴露以及服務(wù)間的調(diào)用是一個(gè)很重要的問題，特別是拉勾網(wǎng)這種 VM 和 K8S 混合部署的架構(gòu)，針對(duì)此問題，社區(qū)也有很多方案，類似 LoadBalancer、Ingress 等，這里拉勾網(wǎng)直接使用了 UK8S 的自帶 LoadBalancer 方案，通過 UCloud 的內(nèi)網(wǎng) ULB4 對(duì)內(nèi)暴露服務(wù)，操作簡(jiǎn)單，穩(wěn)定性也較高。

而集群內(nèi)部的服務(wù)間調(diào)用則是基于 ZK/Eureka 的服務(wù)注冊(cè)與發(fā)現(xiàn)，與之前在 VM 環(huán)境一致，未做改造。

另外拉勾網(wǎng)還有大量的基礎(chǔ)服務(wù)像 zk、Kafka、Redis、MySQL，為了提升服務(wù)間調(diào)用的可靠性，由于應(yīng)用程序都是通過域名來(lái)連接這些服務(wù)的，因此拉勾網(wǎng)在 UHost 環(huán)境下基于 CoreDNS 部署了一套 DNS 服務(wù)。容器化的服務(wù)以及 VM 內(nèi)的服務(wù)，都通過這套 DNS 服務(wù)實(shí)現(xiàn)域名統(tǒng)一解析，從而解決了服務(wù)間調(diào)用的可靠性問題。

配置中心

配置文件的管理和下發(fā)，拉勾網(wǎng)采用的統(tǒng)一配置中心，基于百度 Disconf 做了二次開發(fā)，這樣就可以將 db 等連接信息等做一次隔離，根據(jù)不同的主機(jī)名及 namespace 做下發(fā)，這也就是 K8S 資源類型使用 StatefulSet 的原因了。

版本發(fā)布的配置文件通過 Git 來(lái)統(tǒng)一管理，并沒有使用 ConfigMap，這個(gè)一方面是考慮到 ConfigMap 過大對(duì)集群的性能造成影響，另一方面也是與 VM 環(huán)境保持一致。

持續(xù)交付

拉勾網(wǎng)的 CI/CD 運(yùn)轉(zhuǎn)在 4 套不同的環(huán)境下，分別是研發(fā)環(huán)境、測(cè)試環(huán)境、 預(yù)發(fā)布環(huán)境（線上驗(yàn)證環(huán)境） 、正式環(huán)境。預(yù)發(fā)布和正式環(huán)境都運(yùn)行在 UCloud 的 UK8S 中，通過 Namespace 隔離，確保了環(huán)境的一致性。

此外，拉勾網(wǎng)還有一套自研的 VM 環(huán)境的業(yè)務(wù)發(fā)布系統(tǒng)，不過這套發(fā)布系統(tǒng)未適配容器環(huán)境。而在 K8S 環(huán)境下，采用 Jenkins 做過渡，統(tǒng)一使用 pipeline 做發(fā)布流水線。目前正在改造老的業(yè)務(wù)發(fā)布系統(tǒng)，兼容 K8S 環(huán)境，統(tǒng)一全公司的業(yè)務(wù)發(fā)布流程。

下一步計(jì)劃

目前拉勾網(wǎng)正在測(cè)試 HPA（Horizontal Pod Autoscaler）和 CA（Cluster Autoscaler），計(jì)劃在生產(chǎn)環(huán)境逐步引入自動(dòng)伸縮，減少人工的伸縮容行為，希望借此能降低 IT 成本，并減少重復(fù)性的工作。另外除了基礎(chǔ)組件類的服務(wù)，像 MySQL、Kafka、大數(shù)據(jù)集群等會(huì)繼續(xù)使用 UHost 外，其他服務(wù)拉勾網(wǎng)計(jì)劃都將逐步遷移到 UK8S 中。

關(guān)于 UK8S

UK8S 是一項(xiàng)基于 Kubernetes 的容器管理服務(wù)，用戶可以在 UK8S 上部署、管理、擴(kuò)展容器化應(yīng)用，而無(wú)需關(guān)心 Kubernetes 集群自身的搭建及維護(hù)等運(yùn)維類工作。UK8S 完全兼容原生的 Kubernetes API，以 UCloud 私有網(wǎng)絡(luò)為基礎(chǔ)，并整合了 ULB、UDisk、EIP、VPC 等云產(chǎn)品。歡迎點(diǎn)擊 “http://specialneedsforspecialkids.com/site/product/uk8s.html” 了解 UK8S 產(chǎn)品詳情。