歡迎光臨
每天分享高質量文章

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

最近兩三年,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)

分享創造快樂