基于 Kubernetes 的發(fā)布系統(tǒng)設(shè)計

作者：伍沖斌 2020-04-09 15:23:19

云計算 本文主要介紹了基于 Kubernetes 的發(fā)布系統(tǒng)。首先闡述了設(shè)計基于 Kubernetes 的發(fā)布系統(tǒng)的背景和必要性。然后對發(fā)布系統(tǒng)所具備的基本功能進行了介紹

讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：域名與空間、虛擬空間、營銷軟件、網(wǎng)站建設(shè)、五通橋網(wǎng)站維護、網(wǎng)站推廣。

背景介紹

在我們之前將服務(wù)遷移部署到 Kubernetes 集群的工作中，主要是通過描述 .gitlab-ci.yml 文件來實現(xiàn) CI/CD 的流程。通過這個流程，我們可以完成代碼更新之后的單元測試、lint、編譯、鏡像打包以及發(fā)布等工作。

但是，當服務(wù)部署到 Kubernetes 集群之后，每個服務(wù)都需要在 GitLab 倉庫維護一份 deployment 模板來進行服務(wù)新版本的發(fā)布上線，每次的 deploy 過程是將一些發(fā)布參數(shù)結(jié)合 deployment 模板生成發(fā)布所需的deployment.yml 文件，然后通過 kubectl 命令發(fā)布到 Kubernetes 集群中。但是該種方案存在以下缺點：

• 每個服務(wù)各自維護一份 deployment 模板，具有一定的管理復雜度
• 缺少統(tǒng)一的發(fā)布歷史記錄管理，不利于問題排查和回溯
• 缺少有效的權(quán)限控制，存在一定風險

為了解決以上問題，我們將 CI/CD 的流程發(fā)布工作抽取出來，設(shè)計了一套基于 Kubernetes 的發(fā)布系統(tǒng)來完成服務(wù)發(fā)布發(fā)布工作。

發(fā)布系統(tǒng)基本功能

我們設(shè)計的發(fā)布系統(tǒng)具有以下基本功能：

• 以服務(wù)為粒度完成發(fā)布功能
• 發(fā)布記錄展示
• 每條發(fā)布記錄可以查詢發(fā)布的詳細過程
• 針對每條發(fā)布記錄可以進行快速回滾操作
• 發(fā)布結(jié)果通知，支持郵件和釘釘進行通知
• 部分服務(wù)支持灰度發(fā)布

發(fā)布流程總覽

發(fā)布系統(tǒng)在進行發(fā)布操作之前，需要完成前置的 CI 流程，具體操作為：

1. 在 GitLab 中有代碼更新時，我們可以設(shè)置一定的 CI 規(guī)則觸發(fā)流水線
2. Gitlab-ci 會進行代碼的拉取，并完成單元測試、lint、代碼編譯和鏡像構(gòu)建等操作
3. 完成鏡像構(gòu)建后，將帶有版本信息的 Docker 鏡像上傳到 Docker Harbor 中
4. 在發(fā)布系統(tǒng)進行 Docker 鏡像版本信息的錄入

在上述工作準備就緒之后，發(fā)布系統(tǒng)可以基于每個服務(wù)選擇對應(yīng)的版本，生成每一次發(fā)布需要的 deployment 文件，然后調(diào)用 Kubernetes API server 實現(xiàn)服務(wù)的滾動升級。

發(fā)布過程詳解

基本發(fā)布操作

在發(fā)布系統(tǒng)中，每一次發(fā)布操作都視為一個發(fā)布任務(wù)，所以需要對某個服務(wù)進行升級就需要對這個服務(wù)新建一次發(fā)布任務(wù)，具體需要進行如下操作：

• 選擇需要發(fā)布的環(huán)境(測試環(huán)境或正式環(huán)境)
• 根據(jù)服務(wù)名獲取鏡像列表，并進行版本選取
• 確認發(fā)布參數(shù)，并填寫發(fā)布描述
• 提交信息，開始版本的發(fā)布任務(wù)

 

在完成發(fā)布任務(wù)新建之后，每次的發(fā)布任務(wù)的信息就可以展示出來，除以上填入的信息之外，還包括發(fā)布任務(wù)的開始時間，發(fā)布時長，操作用戶，發(fā)布描述，發(fā)布狀態(tài)等信息，這樣完成每次發(fā)布操作的記錄，用助于故障的排除和問題回溯。

此外，每個發(fā)布任務(wù)還支持回滾操作，可以在新版本發(fā)布存在問題時，進行版本的快速回滾。對于最近一次的發(fā)布任務(wù)，可以進行重發(fā)操作，該功能主要有以下兩個實用場景：

由于外部因素導致發(fā)布失敗，在外部因素問題解決后需要重新發(fā)布

代碼的配置信息更新后，需要讓 Kubernetes 中的 Pod 更新此配置信息回滾和重發(fā)操作本質(zhì)上還是新建發(fā)布任務(wù)，是基于每次的發(fā)布任務(wù)的信息自動地進行了發(fā)布參數(shù)選擇，更加地快速便捷。

發(fā)布 deployment 文件生成

deployment 模板中的參數(shù)分為以下兩類：

基礎(chǔ)參數(shù)

發(fā)布的基礎(chǔ)參數(shù)包括 Pod 副本數(shù)、健康檢查路徑、組織信息等，可以根據(jù)實際情況進行調(diào)整，但是調(diào)整頻率很低。這些參數(shù)通過發(fā)布配置進行管理，每一個服務(wù)都維護了一份發(fā)布配置，存儲在數(shù)據(jù)庫中，我們可以通過在頁面編輯發(fā)布配置進行基礎(chǔ)參數(shù)的修改。此外，發(fā)布配置里維護了該服務(wù)所采用的發(fā)布模板信息。

對于基礎(chǔ)參數(shù)的調(diào)整，相比于新建發(fā)布任務(wù)具有更高的權(quán)限

發(fā)布參數(shù)

包括服務(wù)名、版本號、發(fā)布環(huán)境、發(fā)布方式等。每次發(fā)布根據(jù)需求進行填寫。這些參數(shù)在新建發(fā)布任務(wù)的時候均會確定。

發(fā)布系統(tǒng)每次發(fā)布時結(jié)合基礎(chǔ)模板和以上參數(shù)值生成一份本次發(fā)布任務(wù)所需要的 deployment 文件，然后通過 kubectl apply 調(diào)用 Kubernetes 的 API server 進行對應(yīng)服務(wù)的滾動升級。

deployment 模板管理

在我們的實踐中，服務(wù)是具有共性的，針對一類服務(wù)抽象出 deployment 發(fā)布模板，然后多個服務(wù)可以共用一個發(fā)布模板，大大減小了管理成本。目前發(fā)布采用的 deployment 模板存儲在 GitLab 中，模板的管理與使用方式如下：

1. 模板新增通過提交 Merge Request 完成
2. GitLab 中的模板文件有新增時，GitLab Pipeline 會被觸發(fā)向發(fā)布系統(tǒng)中同步 deployment 模板信息
3. 模板在發(fā)布系統(tǒng)中有記錄，模板 ID 作為唯一標識
4. 每個服務(wù)在發(fā)布配置中對應(yīng)一個發(fā)布模板 ID
5. 新建發(fā)布任務(wù)時，發(fā)布系統(tǒng)會根據(jù)發(fā)布配置中的模板 ID 獲取存對應(yīng)模板文件的 url，并將內(nèi)容下載下來

Kubernetes 發(fā)布過程跟蹤與結(jié)果記錄

由于 Kubernetes 在進行版本更新時，是通過定義聲明式 deployment 文件并進行異步調(diào)用的方式實現(xiàn)的。在調(diào)用 kubectl apply 之后并無法確定對應(yīng)的 Pod 是否可以正確地完成滾動更新。所以我們采用命令 kubectl rollout status deployment $deployment_name 來進行發(fā)布過程的跟蹤，此處變量 deployment_name 與我們的服務(wù)為一一對應(yīng)的關(guān)系。

發(fā)布過程跟蹤的信息可以在每條發(fā)布任務(wù)的詳情中進行查看，此處記錄了 Pod 滾動更新的詳細過程。

發(fā)布的 Pod 成功更新時，kubectl rollout status deployment $deployment_name 會成功退出，發(fā)布系統(tǒng)會判定發(fā)布任務(wù)成功。如果，新版本的 Pod 由于某些原因在滾動更新的過程中一直被阻塞住，在超過發(fā)布系統(tǒng)中所設(shè)置的超時時間后即判定發(fā)布任務(wù)失敗。

對于發(fā)布失敗的任務(wù)，目前支持簡單的 Pod 日志查看，主要原理是對發(fā)布過程中 status 不為 Running 和 Terminating 的 Pod 進行日志查詢，這樣就可以對發(fā)布任務(wù)失敗進行問題定位。效果如下：

總結(jié)

本文主要介紹了基于 Kubernetes 的發(fā)布系統(tǒng)。首先闡述了設(shè)計基于 Kubernetes 的發(fā)布系統(tǒng)的背景和必要性。然后對發(fā)布系統(tǒng)所具備的基本功能進行了介紹。第三部分是本文的主體部分，對發(fā)布系統(tǒng)的原理進行了詳細說明，從新建發(fā)布任務(wù)入手，然后對發(fā)布 deployment 文件生成、發(fā)布模板管理、發(fā)布結(jié)果跟蹤與記錄以及灰度發(fā)布的實現(xiàn)進行了細節(jié)展開。

作者：伍沖斌，VPGAME 運維開發(fā)工程師，VPGAME 是集賽事運營、媒體資訊、大數(shù)據(jù)分析、玩家社群、游戲周邊等為一體的綜合電競服務(wù)平臺。

本文名稱：基于Kubernetes的發(fā)布系統(tǒng)設(shè)計
轉(zhuǎn)載源于：http://m.5511xx.com/article/cdjddgo.html