數人云|當K8S趕上微服務-京東金融PaaS平臺思考與實踐

8月19日的數人云Container Meetup上，張龍老師作了《基於Kubernetes的PaaS平臺的設計和思考》的精彩分享，分別介紹了PaaS平臺的意義，爲何選擇Kubernetes，PaaS平臺上的微服務架構應用，如何設計和快速構建PaaS平臺，PaaS平臺的功能組件這幾個內容。

如下爲現場實錄內容——

今天跟你們分享下基於Kubernetes的PaaS平臺設計和思考，主要分爲五個部分：

• PaaS平臺的意義
• 爲何選擇Kubernetes
• PaaS平臺上的微服務架構應用
• PaaS平臺架構設計
• PaaS平臺功能組件

PaaS平臺的意義

不少公司技術支持崗位的工做，如配置域名，部署環境，修改復位配置，服務重啓，擴容縮容，梳理和完善監控，根據開發的須要查找日誌等工做，須要和開發進行大量的溝通，如什麼是外網域名，什麼是內網域名、A name、C name，防火牆規則該如何設定，操做系統等基礎環境須要什麼依賴。由於不少研發不瞭解運維的術語和知識點，致使溝通困難，效率很低。並且這樣的需求還不少，把運維壓的喘不過氣，佔用了幾乎全部的時間，可是開發的需求可能仍是遲遲不能知足。

這樣的公司可能遇到了如下問題：

• 系統架構過於陳舊，性能、可靠性沒法知足現有的需求；
• 原有IT架構不靈活，業務模塊新增或變動帶來巨大成本壓力；
• 系統功能繁雜，結構紊亂，定製的代碼與系統耦合性極高；
• 服務種類繁多，各類技術棧橫行；
• 人員流動交接不充分，新接手的團隊對部署環境不瞭解，只能作周邊的修補，不敢遷移 。

如何才能解決？答案是流程化、標準化、自動化、平臺化。

流程化

即主動梳理運維工做任務，造成標準化的操做流程，尤爲是針對須要多人協做完成的任務，好比應用的發佈部署，把流程固化到流程平臺系統中，保證每一個人執行都能按照流程嚴格執行，不會有哪些環節遺漏，並且當前的流程狀態對全部人均可見，能清晰的看到誰正在處理，處理人也會更主動儘快的完成該任務。

標準化

從架構角度按照應用類別制定應用的部署標準，好比Web類型的應用，服務化的應用（咱們內部用的JSF），或者是比較新的微服務的應用（Springboot等），部署腳本和工具平臺按照約定好的規範進行設計開發，減小了由於應用種類繁多致使工具和平臺的複雜。

自動化

早期寫了很是多的腳本，任務執行機到要執行任務的服務器之間經過SSH免密鑰認證，再根據須要批量執行命令。隨着服務器規模和應用數量的擴張，很快腳本執行的方式沒法知足業務發展，難以理解，同一個類型的任務多個腳本並存，存在誤操做，缺少清晰的操做歷史記錄和回滾機制，即便後續替換了如Puppet，Saltstack，Ansible這樣的配置管理工具，但根本問題並無解決。

※ 平臺化

平臺化是此次分享的重點，必定要在前面三條的基礎上進行建設，若是沒有清晰的流程，明確的標準，平臺建設起來也只是自動化工具的集成，解決不了公司核心問題。

如下說的平臺化內容主要是PaaS平臺化，即主要從應用和中間件的角度，這裏不討論IaaS的內容。

PasS平臺化將問題的關注點從基礎資源上升到了應用層面，目標是提供一個幫助開發人員運行、管理應用的平臺，讓使用者更關注運行的代碼（業務邏輯）。

PaaS能解決的問題：

• 應用聚合：如開發須要一個Redis，直接啓動一個Redis容器便可
• 服務發現、快速伸縮、狀態管理等
• 服務監控、恢復、容災
• 費用統計：提供計算資源信息彙總，針對不一樣項目收費
• 安全管控：無論什麼平臺，安全都很是重要，例如A應用能夠訪問B,B不容許訪問A以及安全審計等。
• 快速部署。

隨着Docker容器技術的出現，讓咱們有了更合適的工具建設PaaS平臺，具有了基於應用構建服務的能力。

在Docker容器調度框架上，咱們又選擇了Kubernetes平臺。

爲何選擇Kubernetes

先列一下目前三大主流的容器調度框架的功能和特色：

〓 Kubernetes

資源調度、服務發現、服務編排、資源邏輯隔離、服務自愈、安全配置管理、Job任務支持、自動回滾、內部域名服務、健康檢查、有狀態支持、運行監控/日誌、擴容縮容、負載均衡、灰度升級、容災恢復、應用HA。

〓 Mesos

Mesos是一個分佈式內核，目前的發展方向是數據中心操做系統（DCOS），它同時支持 Marathon、 Kubernetes 和 Swarm 等多種框架，Mesosphere 也是 Kubernetes 生態的一員。

注意Marathon的技術棧是Scala語言，而Docker和Kubernetes的技術棧都是Go語言。

〓 Swarm

從Docker1.12版本開始，Swarm 隨Docker一塊兒默認安裝發佈，也因爲隨Docker引擎一塊兒發佈，無需額外安裝，配置簡單。

支持服務註冊、服務發現，內置Overlay Network以及Load Balancer。

與Docker CLI很是相似的操做命令，對熟悉Docker的人很是容易上手學習。

每一種工具都有本身的核心理念。

Mesos理念是數據中心操做系統（DCOS），爲了解決IaaS層的網絡、計算和存儲問題，因此Mesos的核心是解決物理資源層的問題。

Kubernetes的核心是如何解決自動部署，擴展和管理容器化（containerized）應用程序。

因此，我的認爲Mesos和Kubernetes是兩種維度，對於咱們的場景來講，關心應用的狀態多於物理資源層管理，所以更關心的是容器化應用程序管理，這是咱們選擇Kubernetes的主要緣由。

另外選擇Kubernetes還考慮了其它優點，如：

• 出身名門Google，其開發和設計受到了Google著名的Borg系統的影響；
• GitHub上關注Kubernetes項目和提交代碼的開發者很是多，社區活躍，若是遇到問題，經過社區諮詢和解決 問題速度也會比較快。
• Kubernetes能夠很好的支持有狀態的服務。

PaaS平臺上的微服務架構應用

再來看一下我眼中的基於當前最流行的微服務架構的設計是什麼樣的，即咱們PaaS平臺上要運行的典型應用是什麼樣的。

用戶端的請求進來之後，首先進入前端的Nginx服務器，再進入Zuul代理網管上，由Zuul將這些任務下發到不一樣的服務上去。Eureka集羣做爲註冊中心服務，提供服務的發現和註冊的功能。服務後端再去調用依賴的其餘服務，數據庫集羣，Redis集羣等服務。

微服務架構由於有註冊中心自動解決了服務註冊發現的問題，因此對內部服務來說就不用依賴傳統的負載均衡器等工具，很容易將各個服務Docker化，遷移到PaaS平臺裏統一管理。

PaaS平臺架構設計

平臺建設原則

在建設PaaS平臺以前，參考《高效人士的七個習慣》設定了PaaS平臺建設的原則：

1. 以終爲始：作一件事情要知道想達成什麼樣的目的，知道這個目的以後，就可以圍繞這個目標採起一些措施。
2. 知己解彼：做爲一個運維人員，須要有一個比較大的知識面。只有如此纔可以去制定一些適合本身的方案和產品。
3. 積極主動：由於要作PaaS因此要把本身的主觀能動性都調起來。
4. 要事第一：上面說了不少PaaS相關的內容，因爲時間、人員的限制。如何從衆多的基礎組建中挑選出來最重要的一些事情，着手建設。
5. 共贏：作出來的系統最好是可以達到對開發、運維、公司都有利。
6. 統合綜效：對待一樣的一件事，每一個人都會有本身的看法。同時也要問同伴，要把全部的觀點都收集起來作一個綜合分析對比，以收到更好的效果。
7. 持續更新：時刻提醒本身持續學習，擁抱變化，這樣才能看到平臺的不足。持續迭代出更好的產品。

基於以上的原則，咱們團隊勾勒了一個最小化的PaaS圖：

1. 最上面的Ingress服務跟傳統的負載均衡器的功能相似，提供請求分發的功能。
2. Service至關於後端Pod的一個代理服務器，Service須要經過Ingress服務才能被外部Client訪問。
3. Pod則至關於咱們傳統的一個服務。
4. 最小化PaaS平臺還用到了DNS組件，在內部服務運行起來以後，咱們會經過DNS組件分配一個內部域名供訪問時使用。

Kubernetes對外提供服務，用的是Lvs+Ingress，每次添加一個新的服務以後會調用一次DNS的API，按照規則生成一個內部域名供訪問使用。

平臺關鍵能力說明

應用持續部署

平臺實現快速、可視化自動部署功能。支持對應用的快速、可視化部署。用戶僅需在界面中選擇相應的鏡像和組件，並填寫簡單的配置信息，點擊部署按鈕，便可完成整個應用的安裝或者升級。在測試環境可經過Jenkins，可實現應用的持續集成和全自動化升級，同時支持一鍵回滾和恢復發佈功能。

應用彈性伸縮

構建具備需求預測和容器按需供給能力的彈性伸縮子系統，具備基於應用的負載和資源狀況進行彈性伸縮能力，以應對互聯網用戶高併發的特色，應對流量衝擊。其中，包括容器彈性伸縮、物理機彈性伸縮功能。

容器和組件的統一管理

從總體應用的角度出發，平臺不只管理鏡像和容器，而是將一個應用涉及的全部組件均作了統一管理，好比對前端的DNS、負載均衡（F5/Nginx），後端數據庫等的管理。經過對系統相關組件和容器統一管理，平臺將能夠實現系統的全局統一部署、配置、升級/回滾、監控、故障處理等功能。

高可靠性

容器的故障恢復，當服務器宕機時，平臺系統會自動在其它服務器上從新啓動容器併爲其分配資源，從而達到秒級啓動，恢復業務。保障業務不掉線，高可靠運行；鏡像倉庫的可靠性，經過將單機版的鏡像倉庫擴展成鏡像倉庫集羣，從而提高性能，實現Registry的無狀態化，便於實現服務的高可用性。

應用docker化封裝

系統支持以下幾類常見應用：Tomcat、Jboss、Nginx、Redis、Zookeeper等。

PaaS平臺功能組件

具體實施時，主要有幾個基礎組件須要開發：

〓 鏡像管理

實際運行的應用鏡像由 「基礎中間件鏡像」+「應用包」+「配置」 自動構建，無需開發人員理解鏡像概念和手動製做鏡像；

〓 DNS管理

定製化公司內部使用的DNS管理平臺，對公司的DNS進行統一管理；

〓 服務管理

須要定製化一套Kubernetes的Deployment模板，從Ingress到Service再到RC都定義在這套模板裏面，方便對容器進行擴容、縮容、刪除操做；

〓 服務內pod管理

屬於Kubernetes自有範疇，查看Service內的Pod運行狀況、Pod日誌輸出等功能；

〓 日誌管理

將日誌輸出到公司的日誌平臺（如ELK平臺），對接研發人員排查問題、數據埋點使用。

〓 監控管理

參考方案cadvisor+influxdb+grafana/ heapster+influxdb+grafana/Prometheus/zabbix.

一箇中小企業作成這樣後，平常運維的工做量便可大量減小，兩三我的就能完成平常的應用運維工做，有興趣地話能夠去挑戰一下。固然作完這些後，還只是一個小型的PaaS平臺。

若是是再複雜一點的PaaS平臺，應該還有哪些要繼續作的呢？

環境管理：即一套平臺管理多套不一樣的Kubernetes集羣。安全管理、流程管理、計費管理等功能模塊。

還有由於規模增長和更高的可靠性要求，對應的網絡，IO等各類優化。

其實還有不少功能就不一一列舉了，能夠根據本身的實際狀況添加功能模塊，設計有本身公司特點的PaaS平臺。