摘要：宋體自年被開源以來，很快便成為了容器編排領(lǐng)域的標(biāo)準(zhǔn)。宋體年月，樂心醫(yī)療的第一個生產(chǎn)用集群正式上線。所以于年推出后，樂心醫(yī)療的運維團(tuán)隊在開會討論之后一致決定盡快遷移到。

Kubernetes 自 2014 年被 Google 開源以來，很快便成為了容器編排領(lǐng)域的標(biāo)準(zhǔn)。因其支持自動化部署、大規(guī)模可伸縮和容器化管理等天然優(yōu)勢，已經(jīng)被廣泛接納。但由于 Kubernetes 本身的復(fù)雜性，也讓很多企業(yè)的 Kubernetes 探索之路充滿挑戰(zhàn)。
從最初的自建 Kubernetes 到后來遷移至 UK8S 平臺，整個過程遇到了哪些問題并如何解決的呢？本文將帶來樂心醫(yī)療在 Kubernetes 平臺建設(shè)方面的思考與實踐。

選擇 Kubernetes

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

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

自建 Kubernetes

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

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

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

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

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

遷移至 UK8S

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

下面以使用 Helm 部署應(yīng)用的例子來說明：

# 安裝 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 # 使用內(nèi)網(wǎng)負(fù)載 --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 通過內(nèi)網(wǎng) ULB 對 VPC 內(nèi)暴露，集群外部的業(yè)務(wù)可直接通過 IP 調(diào)用。

日志、監(jiān)控、CI/CD 是業(yè)務(wù)上 Kubernetes 繞不過的話題，接下來分享下我們在這幾個模塊的實踐經(jīng)驗。

日志平臺

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

• UK8S 保障高可用

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

圖：log4j2.xml 部分配置

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

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

圖：索引管理

由于樂心健康 APP 的設(shè)備業(yè)務(wù)會產(chǎn)生大量日志，導(dǎo)致 ES 節(jié)點不定期產(chǎn)生 yellow 狀態(tài)，所以后期還需要與我們的研發(fā)人員協(xié)調(diào)，減少無用日志，并優(yōu)化日志索引。

監(jiān)控平臺

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

• 性能監(jiān)控

性能監(jiān)控采用了美團(tuán)點評開源的分布式實時監(jiān)控系統(tǒng) —— CAT 工具，這里選擇 CAT 的原因是由于它是一個實時系統(tǒng)且監(jiān)控數(shù)據(jù)支持全量統(tǒng)計。

圖：CAT 架構(gòu)

圖：CAT 狀態(tài)界面

• 業(yè)務(wù)監(jiān)控

業(yè)務(wù)監(jiān)控我們采用業(yè)界通用的 Prometheus + Grafana 來實現(xiàn)。

圖：Grafana 監(jiān)控儀表盤

代碼發(fā)布（CI/CD）

當(dāng)前使用內(nèi)部研發(fā)的代碼發(fā)布平臺，通過調(diào)用 Jenkins API 實現(xiàn)代碼的發(fā)布構(gòu)建工作。

圖：Pipeline 發(fā)布流程

每個業(yè)務(wù)有 Beta 和 Prod 兩套環(huán)境，使用同一套 Pipeline 腳本，Beta 環(huán)境構(gòu)建好的鏡像直接拿來給 Prod 環(huán)境使用。

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

服務(wù)暴露

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

圖：Konga 儀表盤

配置中心

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

總結(jié)

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

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