分享嘉賓：崔東

本次，我分享的主題是《東方國信基於Kubernetes構建容器雲平臺的實踐和思考》。

先講一下背景，國信之前的軟體部署方式是找臺機器，把war包或者jar包往機器上一扔，啟動就可以了，所有功能都在一個包裡面，模組之間相互耦合，導致新功能開發上線週期很長，客戶的需求得不到及時滿足。

所以我們把我們的應用微服務化改造，微服務化以後，原來一個應用現在變成了十幾個，每個應用功能相對獨立，開發人員需要了解的東西變少，開發新功能也比以前簡單了；

但是軟體部署運維變得困難了，原來一個軟體包，現在成了十幾個。瞭解過DevOps的同學一定知道，開發和運維之間有一道牆，現在這道牆更高了。

所以我們希望有一款產品能解決我們這些痛點，最後我們把目標鎖定在docker和kubernetes上，我們希望基於這個平臺來實現DevOps的部分流程，來減輕部署運維的負擔，同時能提高我們的資源利用率。

最後我們制定了下面這樣一個架構：

這張圖的最左邊是我們控制檯，叫BCM,使用者所有的操作都在BCM的介面上面完成，包括映象的構建，服務的釋出、升級等，這種介面的東西各公司根據業務和服務物件不同會有所不同，但是主要功能都差不多，所以不展開說了，後面會貼幾張介面。

我們先說最核心的k8s部分，因為所有工作都是圍繞著k8s展開的。

雲平臺的主體基於K8S+Docker構建；通過KubeDNS來為叢集內的應用程式提供域名解析；

通過heapster收集效能資訊，寫入influxDB，然後是BCM讀取influxDB資訊進行展示，我們沒有使用grafana,主要是考慮到我們的平臺是多租戶的，不同的租戶只能看到自己系統的效能指標；

而且我們通過對kubelet和heapster的修改，增加了對容器內應用的執行緒數和socket連線數的監控，為什麼要增加？

因為我們在使用過程中發現有些應用程式碼質量不高，亂用執行緒，有的檔案控制代碼開啟後忘記關閉，導致執行一段時間後連線資料庫失敗，所以我們增加了這兩項監控，當然嚴格執行程式碼質量檢查和review才是更重要的。

大家也看到我們使用了prometheus，我們主要使用了prometheus對cpu和記憶體使用率進行告警，同時對prometheus和alertmanager增加了配置介面，在應用部署時，把閾值配置下去，同時過載prometheus的配置，完成監控功能。

我們使用fluent來收集容器的日誌，寫入elasticsearch，通過kibana進行檢索。

同時bcm的web介面上可以檢視實時日誌，這本來是個小功能，但是開發過程也是一波三折，開始我們使用了k8s的api進行日誌獲取，當日志文件很大的時候，發現讀取很慢，接著我們又修改成通過docker的api獲取，但是還是很慢。有時候我們只想檢視一個特定時間段的日誌，這個日誌量應該不會太大，應該很快才對。

於是我們查看了docker原始碼，發現有兩點需要優化，第一是讀取緩衝區，太小了，只有1KB；

第二就是每次都從第一條日誌進行讀取，反序列後進行時間比較，看看是否在時間段內，其實docker不支援結束時間，我們自己加的。

針對第一點，修改方法很簡單，增大一下讀取緩衝區就可以了；

第二點，修改策略是把日誌分成多個檔案，並且記錄每個檔案的開始日誌時間和結束日誌時間，通過查詢記錄資訊，定位到第一個需要讀取的日誌檔案和最後一個需要讀取的檔案，減少不必要的io。

下面我們再說一下我們的服務發現：

我們使用了Nginx來做反向代理，同時我們開發了KubeNg這樣一個後臺程式，為每個Nginx伺服器配置一個KubeNg，KubeNg通過kube-ApiServer實時監控服務的變化，更新nginx的配置檔案，reload nginx配置。

kubeNg是一個後臺程式，沒有介面，生成的nginx配置都是固定格式的，有些使用者對自己應用程式的nginx配置有特殊的要求，需要修改，我們又沒有介面來修改，這不行啊，所以我們又開發了一個NgFront前端程式，NgFront滿足下面幾點要求：

通過NgFront可以管理多套Nginx叢集，因為有些租戶公用一套nginx，有些租戶單獨使用一套nginx。

2、可以修改抓取到的配置，解決租戶對配置有特殊的要求。

3、可以增加沒有使用容器進行部署的服務的反向代理，因為不是所有服務都會使用容器進行部署，起碼剛開始不會，但是這些服務還想共用容器的nginx，當然運維人員可以登入到每臺nginx機器上進行配置，但是這樣很容易出錯，直接在介面上面編輯完成，下發到所有機器就可以了。

4、Reload之前進行配置檔案語法檢查。

5、可以下載配置檔案，有時候會有運維人員繞過NgFront進行操作，導致Nginx叢集內各節點的配置不一致，有些使用者可以正常訪問，有些不能正常訪問，取決於LVS把使用者的請求負載均衡到哪臺nginx上面了，所以出現這種情況的時候，我們點選下載，用文字對比工具對比一下，很快就能發現問題。

下面我們再說說ttyEntry：

這個主要是解決使用者除錯方便的需求。使用者在剛開始使用容器的時候，碰到最多的問題就是配置檔案忘記修改了，導致系統啟動失敗。使用者需要重新上傳個jar包到BCM平臺，進行映象構建，所以他們需要有一個環境像使用虛擬機器一樣，可以使用vi進行編輯，修改完成後，執行java –jar進行測試，如果正常，直接打包成映象，推送到倉庫。

BCM使用了xterm來做了一個web版的終端，TtyEntry主要功能就是把xterm發過來的請求轉發到容器內部。

下面再說說pinpoint功能：

這個是一個很讚的工具，在不需要修改程式碼的情況下，可以給出應用之間的呼叫關係和花費的時間，而且效能損失很小。

下面是pinpoint的架構圖，我們把紅色框中的Pinpoint Agent做到了容器內，通過BCM介面上的開關控制是否開啟監控。

精華也在Pinpoint Agent，Agent會在我們應用程式的class載入的時候，進行jvm虛擬機器程式碼的注入，在class執行的時候採集執行時間傳送給Collector，後面的HBase就是儲存，WebUi就是展示。

深入的原理還是要看google的論文，Pinpoint是根據google的Dapper論文研發的。

再回到我們剛開始的整體框架圖，裡面有個Ceph，Ceph用來提供高效能的網路儲存。我們的應用程式不全是無狀態的，有很多應用程式需要使用者上傳指令碼、說明文件等，這些東西顯然不能儲存在容器內部的儲存上。

大家知道docker容器重啟後，裡面儲存的資料就會丟失，所以我們就把ceph掛載到容器內部，把這些需要持久化的東西儲存到ceph，即使pod被重新排程到其他節點，儲存在ceph裡面的檔案也不會丟失。另外Ceph的塊儲存也可以為我們的mysql、redis等的容器化提供儲存。

我們還有一部分沒有介紹，就是下面這塊：

這其實就是個簡配的DevOps，之所以做一個簡配版，主要是考慮到兩方面：一、實現簡單；二、推廣簡單。一個工具一旦複雜了，就很難推廣落地，所以我們前期先做一最簡單的，先讓大家上船，後面才好往下走。

我們開發了一個持續整合工具SheRa，就是動畫片裡面的“希瑞請賜予我力量吧”的希瑞。SheRa只是一個後臺服務，提供restful的介面，BCM實現配置頁面。下面是介面：

介面配置Git的地址、maven編譯命令，sonar程式碼質量檢查是可選的配置，如果選擇了，最後生成的映象就有一個相應的質量標籤，最後是dockerfile，我們的shera自帶了幾個工具，如果最後生成的映象有問題，可以把shera自帶的工具打包進去，協助進行除錯。

比如，連線mysql不成功，可以把mysql客戶端打包到映象內，通過ssh進入映象，進行連線測試。因為剛開始使用容器，研發很容易把屎盆子扣在容器頭上，我們可以通過這些工具有理有據的告訴他們，資料庫連線沒有問題，你們是不是打包配置錯了jdbc。

下面是配置完成，編譯後的介面：

點選專案名稱，進入詳情

點選快速部署按鈕，進行部署。

這樣一個服務也就配置完成了。

好了，我的分享也就這麼多了，謝謝大家閱讀。

作者：東方國信 崔東