寫在前面
拉勾網於 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 產品詳情。