拉勾網基於 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/pr...」 瞭解 UK8S 產品詳情。