如何在Kubernetes部署期間正確處理DB模式

本文介紹瞭如何在Kubernetes部署期間正確處理資料庫模式，及其體系結構的功能特點。如果，您已經決定遷移到Kubernetes，但是不確定如何安全地推出微服務副本，同時還要協調對底層資料庫架構的更改，那就請參考本文內容。

大綱：
1.Kubernetes的功能

2.最受歡迎的資料遷移庫

3.簡單、易用的工程實踐

正文：

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視覺化設定：可以在推出新版本的微服務時，確保新副本正在處理流量：

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

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31542119/viewspace-2213350/，如需轉載，請註明出處，否則將追究法律責任。