歡迎光臨
每天分享高質量文章
當前位置：知識星球 > 後端 > 正文

平安證券Kubernetes容器叢集的DevOps實踐

2019-06-03 分類：後端 閱讀(377) 評論(0)

最近兩三年，Docker容器技術及Kubernetes編排排程系統，在DevOps領域，大有星火燎原，一統天下之勢。平安證券IT團隊一直緊跟最新技術，踐行科技賦能。本文聚焦於公司在DevOps轉型過程中的幾個典型的技術細節的解決方案，希望對同行有所借鑒和幫助。
生產環境的高可用Master部署方案

 

Kubernetes的高可用Master部署，現在網路上成熟的方案不少。大多數是基於Haproxy和Keepalived實現VIP的自動漂移部署。至於Haproxy和Keepalived，可獨立出來，也可寄生於Kubernetes Master節點。
我司在IT裝置的管理上有固定的流程，VIP這種IP地址不在標準交付範圍之內。於是，我們設計了基於DNS解析的高可用方案。這種方案，是基於Load Balancer變形而來。圖示如下：
這種構架方案，平衡了公司的組織結構和技術實現。如果真發生Master掛掉，系統應用不受影響，DNS的解析切換可在十分鐘內指向新的Master IP，評估在可接受範圍之內。
公司內部安裝Master節點時，使用的基本工具是Kubeadm，但是作了指令碼化改造及替換成了自己的證書生成機制。經過這樣的改進之後，使用kubeadm進行叢集安裝時，就更有條理性，步驟更清晰，更易於在公司進行推廣。
底層的etcd叢集使用獨立的Docker方式部署，但共享kubeadm相關目錄下的證書檔案，方便了api-server和etcd的認證通訊。指令碼的相關配置如下：

當以DNS域名的形式進行部署後，各個證書配置認證檔案，就不會再以IP形式連線，而是以DNS域名形式連線api-server了。如下圖所示：

 

 

分層的Docker映象管理

 

接下來，我們分享一下對Docker映象的管理。Docker的企業倉庫，選用的是業界流行的Harbor倉庫。根據公司研發語言及框架的廣泛性，採用了三層映象管理，分為公共映象，業務基礎映象，業務映象（tag為部署釋出單），層層疊加而成，即形成標準，又照顧了一定的靈活性。

  • 公共映象：一般以alpine基礎映象，加上時區調整，簡單工具。

  • 業務基礎映象：在公共映象之上，加入JDK、Tomcat、Node.js、Python等中介軟體環境。

  • 業務映象：在業務基礎映象之上，再加入業務軟體包。

 

 

Dashboard、Prometheus、Grafana的安全實踐

 

儘管在Kubernetes本身技術棧之外，我司存在體系化的日誌收集，指標監控及報警平臺，為了運維工具的豐富，我們還是在Kubernetes內集成了常用的Dashboard、Prometheus、Grafana元件，實現一些即時性運維操作。
那麼，這些元件部署，我們都納入一個統一的Nginx一級url下，二級url才是各個元件的管理地址。這樣的設計，主要是為了給Dashborad及Prometheus增加一層安全性（Grafana自帶登陸驗證）。
這時，可能有人有疑問，Dashboard、kubectl都是可以透過cert證書及RBAC機制來實現安全性的，那為什麼要自己來引入Nginx作安全控制呢？
在我們的實踐過程中，cert證書及RBAC方式，結合SSH登陸帳號，會形成一系列複雜操作，且推廣難度高，我們早期實現了這種樣式，但目前公司並不具備條件，所以廢棄了。公司的Kubernetes叢集，有專門團隊負責運維，我們就針對團隊設計了這個安全方案。
Prometheus的二級目錄掛載引數如下：
Grafana的二級目錄掛載引數如下：
Dashboard在Nginx裡的配置如下：
一個能生成所有軟體包的Jenkins Job

 

在CI流水線實踐，我們選用的GitLab作為原始碼管理元件，Jenkins作為編譯元件。但為了能實現更高效標準的部署交付，公司內部實現一個專案名為prism（稜鏡）的自動編譯分發部署平臺。在容器化時代，衍生出一個Prism4k專案，專門針對Kubernetes環境作CI/CD流程。Prism4k版的構架圖如下所示：
在這種體系下，Jenkins就作為我們的一個純編譯工具和中轉平臺，高效的完成從原始碼到映象的生成。
由於每個IT應用相關的變數，指令碼都已組織好，放到Prism4k上。故而，Jenkins只需要一個Job，就可以完成各樣各樣的映象生成功能。其主要Pipeline指令碼如下（由於資訊敏感，只列舉主要流程，有刪節）：
在Jenkins中，我們使用了一個Yet Another Docker Plugin，來進行Jenkins編譯叢集進行Docker生成時的可擴充套件性。作到了編譯節點的容器即生即死，有編譯任務時，指定節點才生成相關容器進行打包等操作。

 

計算資源線上配置及應用持續部署

 

在Prism4k平臺中，針對Jenkins的Job變數是透過網頁配置的。在釋出單的編譯映象過程中，會將各個變數透過API傳送到Jenkins，啟動Jenkins任務，完成指定task任務。
Pod的實體數，CPU和記憶體的配置，同樣透過Web方式配置。
在配置好元件所有要素之後，日常的流程就可以基於不同部門使用者的許可權把握，實現流水線化的軟體持續交付。

  • 研發：新建釋出單，編譯軟體包，形成映象，上傳Harbor庫。

  • 測試：環境流轉，避免部署操作汙染正在進行中的測試。

  • 運維：運維人員進行釋出操作。

 

在FAT這樣的測試環境中，為加快測試進度，可靈活的為研發人員賦予運維許可權。但在更正式的測試環境和線上生產環境，作為金融行業的IT建設標準，則必須由運維團隊成員操作。
下麵配合截圖，瞭解一下更具體的三大步驟。

  1. 釋出單

    在Prism4k與Jenkins的API互動，我們使用了Jenkins的Python庫。

  2. 環境流轉

  3. 部署

     

在部署操作過程中，會將這次釋出的資訊全面展示給運維同事，讓運維同事可以進行再次審查，減少釋出過程中的異常情況。

 

總結

 

由於Kubernetes版本的快速更新和釋出，我們對於其穩定性的功能更為青睞，而對於實驗性的功能，或是需要複雜運維技能的功能，則保持理智的觀望態度。所以，我們對Kubernetes功能只達到了中度使用。當然，就算是中度使用，Kubernetes的運維和使用技巧，還是有很多方面在此沒有涉及到，希望以後有機會，能和各位有更多的溝通和交流。願容器技術越來越普及，運維的工作越來越有效率和質量。

 

Q&A;

 

Q：映象有進行安全掃描嗎？
A：外部基本映象進入公司內部，我們基於Harbor內建的安全功能進行掃描。
Q：Harbor有沒有做相關監控，比如釋出了多少映象，以及映象同步時長之類的？
A：我們沒有在Harbor上作擴充套件，只是在我們自己的Prism4k上，會統計各個專案的一些映象釋出資料。
Q：有沒有用Helm來管理映象包？後端儲存是用的什麼，原因是？
A：沒有使用Helm。目前叢集有儲存需求時，使用的是NFS。正在考慮建基於Ceph的儲存，因為現在接入專案越來越多，不同的需求會導致不同的儲存。
Q：想瞭解下，Yaml檔案怎麼管理的，可以自定義生成嗎？
A：我們的Yaml檔案，都統一納到Prism4k平臺管理，有一些資源是可以自定義的，且針對不同的專案，有不同的Yaml模板，然後，透過django的模組功能統一作解析。熟悉Yaml書寫的研發同事可以自己定義自己專案的Yaml模板。
Q：Pipeline會使用Jenkinfile來靈活code化Pipeline，把Pipeline的靈活性和創新性還給開發團隊，這比一個模板化的統一Pipeline有哪些優勢？
A：Pipeline的執行樣式，採用單一Job和每個專案自定義Job，各有不同的應用場景。因為我們的Jenkins是隱於幕後的元件，研發主要基於Prism4k操作，可以相對減少研發的學習成本。相對來說，Jenkins的維護人力也會減少。對於研發各種許可權比較高的公司，那統一的Job可能並不合適。
Q：想瞭解下貴公司使用什麼網路方案？Pod的網路訪問許可權控制怎麼實現的？
A：公司現在用的是Flannel網路CNI方案。同時，在不同的叢集，也有作Calico網路方案的對比測試。Pod的網路許可權，這塊暫時沒有，只是嘗試Istio的可行性研究。
Q： 一個Job生成所有的Docker映象，如果構建遇到問題，怎麼去追蹤這些記錄？
A：在專案前期接入時，生成映象的流程都作了宣傳和推廣。標準化的流程，會減少產生問題的機率。如果在構建中遇到問題，Prism4k的介面中，會直接有連結到本次建的次序號。點選連結，可直接定位到Console輸出。
Q：遇到節點Node上出現100+ Pod，Node會卡住，貴公司Pod資源怎麼做限制的？
A：我們的業務Pod資源，都作了limit和request限制。如果出現有卡住的情況，現行的方案是基於專案作拆分。Prism4k本身對多環境和多叢集都是支援的。
Q：多環境下，集中化的配置管理方案，你們選用的是哪個，或是自研的？ 
A：我們現在正在研發的Prism4k，前提就是要支援多環境多叢集的部署，本身的功能裡，yaml檔案的配置管理，都是其內建功能。
Q：網路方案用的什麼？在選型的時候有沒有對比？
A：目前主要應用的還是Flannel方案，今年春節以來，還測試過Flannel、Caclico、kube-router方案。因為我們的叢集有可能越機房，而涉及到BGP協議時，節點無法加入，所以一直選用了Flannel。
贊(0)
標籤：

相關推薦

熱門標籤

iOS (11238)微軟 (4955)Linux (4274)安全 (4180)Python (4161)效能 (3165)運維 (2774)最佳化 (2419).NET (2262)Google (2136)機器學習 (1795)併發 (1613)分散式 (1559)叢集 (1240)SQL (1174)Mysql (1060)區塊鏈 (1017)Docker (977)微服務 (922)面試 (919)Apache (743)NLP (725)Redis (719)Android (668)Git (640)架構師 (632)Nginx (630)Facebook (599)JVM (595)爬蟲 (476)

熱門文章

分享創造快樂