Kubernetes 自2014年被 Google 開源以來，很快便成為了容器編排領域的標準。因其支持自動化部署、大規模可伸縮和容器化管理等天然優勢，已經被廣泛接納。但由於 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 部分配置
以下是日誌中心的工作負載詳情：
圖：logcenter 工作負載（截圖來自 Rancher 控制檯）
從上圖可以看出我們整套日誌服務（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 腳本管理，進而開發了代碼管理平臺，使技術團隊的每個成員都能更方便的參與到運維工作中。
閱讀更多 java互聯網架構 的文章
