摘要：宋體自年被開源以來，很快便成為了容器編排領域的標準。宋體年月，樂心醫療的第一個生產用集群正式上線。所以于年推出后，樂心醫療的運維團隊在開會討論之后一致決定盡快遷移到。

Kubernetes 自 2014 年被 Google 開源以來，很快便成為了容器編排領域的標準。因其支持自動化部署、大規?？缮炜s和容器化管理等天然優勢，已經被廣泛接納。但由于 Kubernetes 本身的復雜性，也讓很多企業的 Kubernetes 探索之路充滿挑戰。
從最初的自建 Kubernetes 到后來遷移至 UK8S 平臺，整個過程遇到了哪些問題并如何解決的呢？本文將帶來樂心醫療在 Kubernetes 平臺建設方面的思考與實踐。

選擇 Kubernetes

樂心醫療成立于 2002 年，業務采用的是基于 Dubbo 微服務框架的分布式架構，由于微服務存在數量多、配置冗雜等問題，最初我們使用了 Ansible 作為配置管理工具，雖然可以較好地解決批量系統配置、批量程序部署的問題，但依然難以應對上百個微服務的頻繁擴縮容及快速迭代。

圖：Dubbo 框架
2016 年初，隨著容器技術的興起，我們調研了諸如 Mesos、Swarm、Kubernetes 等方案，由于 Kubernetes 能完美解決調度、負載均衡、集群管理、伸縮等微服務面臨的問題，因此在 2016 年 6 月份，經過內部評估之后，我們最終選擇了 Kubernetes。

自建 Kubernetes

最開始搭建 Kubernetes 需要手動依次打包下載環境需要的所有二進制文件、驗證配置環境變量、安裝各種網絡存儲等插件，整個一套搭建流程完成下來非常耗費時間且易出錯。后續還需要持續進行手動維護 Kubernetes 集群，例如升級 Kubernetes 版本、內置組件版本等。

2016 年 6 月，樂心醫療的第一個生產用 Kubernetes 集群正式上線。在使用自建 Kubernetes 的過程中，產生了多次因網絡、存儲插件產生的故障，大部分問題都可以通過 Google 搜索解決，但存在一些涉及到 Kubernetes 核心組件的 BUG，只能通過手動升級 Kubernetes 集群來解決，而 Kubernetes 熱升級非常麻煩，這對于當時我們只有兩個人的運維團隊來說是一個很大的挑戰。

除了耗費大量時間和運維人力成本外，自建 Kubernetes 在面臨業務發展需要不斷新增節點時，很難及時應對業務擴容的需求，不夠靈活彈性。所以 UCloud 于 2018 年推出 UK8S 后，樂心醫療的運維團隊在開會討論之后一致決定盡快遷移到 UK8S。

以下是樂心醫療自建 Kubernetes 過程中用到的開源工具（可供參考）：

• Ansible – 管理服務器配置。
• kubespray – 安裝 Kubernetes 集群（需要自行解決 Kubernetes 組件的下載網絡問題）。
• ROOK – 存儲解決方案。
• Harbor – 鏡像中心（由于云廠商提供的免費鏡像中心功能無法滿足我們的業務需求，所以仍無法避免自建鏡像中心）。

遷移至 UK8S

圖：UK8S 控制臺界面使用 UCloud 的容器云 UK8S 解決了自建 Kubernetes 常見的網絡、存儲問題，特別是存儲可直接使用 UDisk、UFS，之前自建 Kubernetes 使用到的 Nginx 也被負載均衡 ULB 所取代，極大地簡化了運維 Kubernetes 的負擔。

下面以使用 Helm 部署應用的例子來說明：

# 安裝 openldap$ helm install --namespace openldap --name openldap --set env.LDAP_ORGANISATION="xxx Inc" --set env.LDAP_DOMAIN="xxx.com" --set-string env.LDAP_READONLY_USER=true --set env.LDAP_READONLY_USER_USERNAME="readonly" --set env.LDAP_READONLY_USER_PASSWORD="xxx" --set persistence.enabled=true # 指定存儲類別為 udisk-ssd--set persistence.storageClass=udisk-ssd --set service.type=LoadBalancer # 使用內網負載 --set service.annotations."service.beta.kubernetes.io/ucloud-load-balancer-type"="inner" --set service.annotations."service.beta.kubernetes.io/ucloud-load-balancer-vserver-protocol"="tcp" stable/openldap

如上，存儲我們直接使用了 UCloud 的 SSD 云硬盤，運行在 UK8S 里面的 Service 通過內網 ULB 對 VPC 內暴露，集群外部的業務可直接通過 IP 調用。

日志、監控、CI/CD 是業務上 Kubernetes 繞不過的話題，接下來分享下我們在這幾個模塊的實踐經驗。

日志平臺

圖：架構圖在日志管理上，我們的實現原理如下：1、采用 kafka 作為日志緩沖，在高并發情況下可以通過隊列就能起到削峰填谷的作用，防止 es 集群丟失數據。2、實現動態 schema，業務可以自定義 schema，方便日志檢索和查詢。3、每一個業務有獨立的索引。

• UK8S 保障高可用

業務日志的采集流程為：微服務（log4j2.xml）-> kafka 集群 -> ES 集群 -> Kibana 呈現。日志的索引名稱在 log4j2.xml 配置文件中定義。

圖：log4j2.xml 部分配置

我們整套日志服務（kafka、ES）都部署在 UK8S 集群中，除了 kibana 之外，其他所有服務都是多副本，通過集群部署的方式，減少數據丟失的風險。各組件全部使用 helm 工具部署更新，其中存儲采用了 UCloud 云硬盤 UDisk。

Kibana 界面的索引名稱來源于 log4j2.xml 中的定義的變量：

圖：索引管理

由于樂心健康 APP 的設備業務會產生大量日志，導致 ES 節點不定期產生 yellow 狀態，所以后期還需要與我們的研發人員協調，減少無用日志，并優化日志索引。

監控平臺

針對 Kubernetes 集群的監控方案有很多，這里主要說明一下我們在性能監控和業務監控兩個方面的方案選擇。

• 性能監控

性能監控采用了美團點評開源的分布式實時監控系統 —— CAT 工具，這里選擇 CAT 的原因是由于它是一個實時系統且監控數據支持全量統計。

圖：CAT 架構

圖：CAT 狀態界面

• 業務監控

業務監控我們采用業界通用的 Prometheus + Grafana 來實現。

圖：Grafana 監控儀表盤

代碼發布（CI/CD）

當前使用內部研發的代碼發布平臺，通過調用 Jenkins API 實現代碼的發布構建工作。

圖：Pipeline 發布流程

每個業務有 Beta 和 Prod 兩套環境，使用同一套 Pipeline 腳本，Beta 環境構建好的鏡像直接拿來給 Prod 環境使用。

不過由于 Beta 環境的腳本會定期做一些優化更新，為了避免對 Prod 環境的發布產生影響，所以后期會考慮不再使用兩個 Pipeline。計劃采用 Drone 替換掉 Jenkins，Drone 是云原生的持續化交付工具，配置采用了 yaml 格式，更加清晰易懂，而 Jenkins Pipeline 的語法坑比較多，插件管理混亂。

服務暴露

生產和測試環境我們目前使用的是兩套方案，生產環境中是直接使用了 nginx-ingress，并通過外網 ULB 直接暴露到公網，測試環境目前在使用 Konga，后續運行穩定的話，會在生產環境上線替掉 nginx-ingress。服務網關選用 Konga，是因為其界面比 Kong 更加友好，且可以直接部署在 UK8S 中。

圖：Konga 儀表盤

配置中心

之前使用 Disconf，目前已替換為 Apollo，所有的配置文件都放在 Apollo 中，同一個鏡像運行在不同的 namespace 時，會根據預定義的 configmap 中的 ENV 環境變量，從 Apollo 獲取不同的配置信息。替換掉 Disconf 的原因是其源碼已長期未更新，不能滿足當前日益增長的微服務架構擴展，且沒有嚴格的權限管控，操作日志記錄等功能。

總結

在遷移至 UK8S 平臺后，樂心醫療深切體會到云服務商 UCloud 提供的 Kubernetes 平臺的好處，除了可以免去 Kubernetes 集群自身的搭建及后期維護等運維工作，在 Kubernetes 集群的穩定性、高性能、自動伸縮等方面，UK8S 也能夠提供更加專業的服務能力。

樂心運維團隊在遷移至 UCloud 提供的 Kubernetes 平臺之前，一直忙于解決自建 Kubernetes 中的因網絡、存儲或 Kubernetes 組件自身 bug 引起的突發故障，幾乎沒有時間來做提升運維效率的工作。在拋棄自建 Kubernetes 之后，樂心運維團隊實現了 CI/CD 全部由 Jenkins Pipeline groovy 腳本管理，進而開發了代碼管理平臺，使技術團隊的每個成員都能更方便的參與到運維工作中。