怎么在Kubernetes部署期間正確處理DB模式

這篇文章主要介紹怎么在Kubernetes部署期間正確處理DB模式，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

正文：

Architecture（架構）

讓我們思考一下以下“two-tier”場景。

•   一個具有多個無狀態微服務副本的“應用程序層”

•   一個具有一個數據庫的“數據庫層”（在實際生產中，為了冗余可能還有多個副本）

•   有一個用于創建和讀取用戶的API

• “數據庫層”負責數據持久化

實施：自頂向下

Services（服務）

上圖所示的應用層和數據庫層通過底層服務實現，Services本質提供：

•   DNS名稱，以便可以輕松將請求發送到“tier”

•   將請求透明路由到底層Pods

Pods

微服務和數據庫的運行都是在一個封閉的容器內，以達到資源隔離。這些容器本身封裝在Pods中，Pods是Kubernetes中最小的可部署單元。

Deployments（部署）

配置Pod副本的數量以及其生命周期的管理是由部署完成的，這是我們解決問題需要注意的一點。

Database Migrations（數據庫遷移）

但當您更改微服務代碼時，您還需要更改數據模式使其適配。一個簡單的方法就是通過數據庫遷移。步驟如下：

1.       將您的架構版本化；

2.       將每個更改寫入專用腳本（也被稱為“migration”）模式中，該腳本可以通過版本號識別；

3.       將所有的腳本與代碼打包；

4.       在啟動時，檢查您的架構版本，如果它已經過期，應用必要的遷移，以便與模式匹配。

這種方法的優點：

•   簡單：在運行時不會引入新的移動基礎架構；

•   易于部署：在開發、測試和生產階段，您都將擁有正確的版本模式。

目前效果

Kubernetes讓我們很容易的就實現了上述設置，它為我們完成了很多復雜工作，將整個工序簡化了很多。

實際上，上面描述的整個“應用程序層”基本上都是在以下兩個YAML清單中配置的：

但是，上面的內容并不能提供所有您需要的特性，您也許想問如下一些問題：

•  在部署新版本期間會發生什么？會出現宕機嗎？容量如何變化？

•  如果犯了一個錯誤，新版本在部署時崩潰怎么辦？

•  如果微服務在運行一段時間后崩潰，會發生什么？

•  如果需要回滾應該怎樣做？

現在就讓我們解答一下這些問題：

實施：細節決定成敗！

Rolling Out（推出）

默認情況下，Kubernetes使用“rolling update”策略部署Pod，一次刪除1個舊Pod（maxUnavailable: 1）并添加1個新Pod（maxSurge: 1），這意味著有3個副本，在滾動新版本時，您將暫時失去33%的能力去服務終端用戶。

讓我們通過將maxUnavailable更改為0來解決此問題。首先，Kubernetes將部署一個新的Pod，并且只有在部署成功時才能刪除舊的Pod。但缺點是，集群中需要備用的容量來臨時運行這個額外的副本，所以如果您容量已滿，則可能需要添加額外的節點。

但優點是，理論上零停機不會對終端用戶產生影響。

Readiness（準備就緒）

當Kubernetes認為它已經“準備好（ready）”時，它會在其服務器的負載均衡中添加一個Pod。默認情況下，“ready”只意味著Pod的所有容器已經啟動，Kubernetes可以執行它們。但是，如果要建立數據庫的連接，并在啟動時運行模式遷移，可能會需要一段時間，很顯然我們需要更好的定義"ready"。

從業務的角度看，我們的微服務已經準備就緒，可以開始響應終端用戶的請求。因此，我們可以通過配置 HTTP readinessProbe將確切的信息告訴Kubernetes 。此外，我們需要在啟動HTTP服務器之前創建數據庫連接并運行遷移。

一般來說，在每個Pod推出后稍等片刻也不是什么壞事。

現在，如果我們在啟動時崩潰了，或者無法連接到數據庫，新部署失敗的Pod將不會被添加到“應用程序層”的負載均衡中，而rollout將在那里停止。這意味著，即使在這個階段出現問題也不會影響到最終用戶。

Liveness（活躍度）

Kubernetes還會定期檢查Pod是否還“活著”，默認情況下也是如此。在我們的示例中，如果數據庫客戶端以某種方式進入損壞狀態，我們也許希望Kubernetes從負載均衡器中刪除受影響的pod，然后啟動一個新的。這可以通過添加檢查（理想情況下，會代表系統的健康狀況）、將其揭示給Kubernetes或者配置一個livenessProbe來實現。

Rolling back（回滾）

但是如果操作失敗，你也許想要回滾到最新的工作版本。良好的工程實踐可以幫助實現這一點。在我們的場景中，最主要的是我們微服務數據庫模式的向后兼容性。

例如，添加列并明確選擇列，我們將可以在最新模式下運行先前版本的微服務，并且允許從v1.1.0平穩回滾到v1.0.0，而無需更改任何模式。

重命名列將不能向后兼容。在這種情況下，您也許想使用“down migrations”恢復到以前的架構版本。但需要注意的是，前后滾動將打破“零停機時間”。實際上，終端用戶會遇到各種暫時性錯誤，這取決于他們部署的階段和遇到的副本。如果您不能接受這樣的錯誤，你可能需要先推出一個能夠同時支持新舊兩種模式的微服務版本（通過擁有兩個客戶端，選擇正確的一個或者同時嘗試兩個），然后推出具有遷移性的另一個版本，以便進行模式更改。

這中間可能會出現很多問題，所以需要你仔細測試一下。

對于大型系統，您可能需要研究“blue-green deployments（藍綠部署）”，但這實現起來會很困難。

少說話，多行動！

想要實現這些設置，可以參考以下建議。

我們建議使用Weave Cloud，因為它可以使前后滾變得簡單易行，并且還可以在您更改系統時提供完整的系統可觀性。

例如，您可以使用Weave Cloud可視化設置：可以在推出新版本的微服務時，確保新副本正在處理流量：

并且您可以任意查詢收集到的指標，并清楚的看到新版本（藍色垂直線）的影響。

以上是“怎么在Kubernetes部署期間正確處理DB模式”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！