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

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

正文：

Architecture（架構(gòu)）

讓我們思考一下以下“two-tier”場(chǎng)景。

•   一個(gè)具有多個(gè)無(wú)狀態(tài)微服務(wù)副本的“應(yīng)用程序?qū)印?/p>

•   一個(gè)具有一個(gè)數(shù)據(jù)庫(kù)的“數(shù)據(jù)庫(kù)層”（在實(shí)際生產(chǎn)中，為了冗余可能還有多個(gè)副本）

•   有一個(gè)用于創(chuàng)建和讀取用戶(hù)的API

• “數(shù)據(jù)庫(kù)層”負(fù)責(zé)數(shù)據(jù)持久化

實(shí)施：自頂向下

Services（服務(wù)）

上圖所示的應(yīng)用層和數(shù)據(jù)庫(kù)層通過(guò)底層服務(wù)實(shí)現(xiàn)，Services本質(zhì)提供：

•   DNS名稱(chēng)，以便可以輕松將請(qǐng)求發(fā)送到“tier”

•   將請(qǐng)求透明路由到底層Pods

Pods

微服務(wù)和數(shù)據(jù)庫(kù)的運(yùn)行都是在一個(gè)封閉的容器內(nèi)，以達(dá)到資源隔離。這些容器本身封裝在Pods中，Pods是Kubernetes中最小的可部署單元。

Deployments（部署）

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

Database Migrations（數(shù)據(jù)庫(kù)遷移）

但當(dāng)您更改微服務(wù)代碼時(shí)，您還需要更改數(shù)據(jù)模式使其適配。一個(gè)簡(jiǎn)單的方法就是通過(guò)數(shù)據(jù)庫(kù)遷移。步驟如下：

1.       將您的架構(gòu)版本化；

2.       將每個(gè)更改寫(xiě)入專(zhuān)用腳本（也被稱(chēng)為“migration”）模式中，該腳本可以通過(guò)版本號(hào)識(shí)別；

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

4.       在啟動(dòng)時(shí)，檢查您的架構(gòu)版本，如果它已經(jīng)過(guò)期，應(yīng)用必要的遷移，以便與模式匹配。

這種方法的優(yōu)點(diǎn)：

•   簡(jiǎn)單：在運(yùn)行時(shí)不會(huì)引入新的移動(dòng)基礎(chǔ)架構(gòu)；

•   易于部署：在開(kāi)發(fā)、測(cè)試和生產(chǎn)階段，您都將擁有正確的版本模式。

目前效果

Kubernetes讓我們很容易的就實(shí)現(xiàn)了上述設(shè)置，它為我們完成了很多復(fù)雜工作，將整個(gè)工序簡(jiǎn)化了很多。

實(shí)際上，上面描述的整個(gè)“應(yīng)用程序?qū)印被旧隙际窃谝韵聝蓚€(gè)YAML清單中配置的：

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

•  在部署新版本期間會(huì)發(fā)生什么？會(huì)出現(xiàn)宕機(jī)嗎？容量如何變化？

•  如果犯了一個(gè)錯(cuò)誤，新版本在部署時(shí)崩潰怎么辦？

•  如果微服務(wù)在運(yùn)行一段時(shí)間后崩潰，會(huì)發(fā)生什么？

•  如果需要回滾應(yīng)該怎樣做？

現(xiàn)在就讓我們解答一下這些問(wèn)題：

實(shí)施：細(xì)節(jié)決定成?。?/strong>

Rolling Out（推出）

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

讓我們通過(guò)將maxUnavailable更改為0來(lái)解決此問(wèn)題。首先，Kubernetes將部署一個(gè)新的Pod，并且只有在部署成功時(shí)才能刪除舊的Pod。但缺點(diǎn)是，集群中需要備用的容量來(lái)臨時(shí)運(yùn)行這個(gè)額外的副本，所以如果您容量已滿(mǎn)，則可能需要添加額外的節(jié)點(diǎn)。

但優(yōu)點(diǎn)是，理論上零停機(jī)不會(huì)對(duì)終端用戶(hù)產(chǎn)生影響。

Readiness（準(zhǔn)備就緒）

當(dāng)Kubernetes認(rèn)為它已經(jīng)“準(zhǔn)備好（ready）”時(shí)，它會(huì)在其服務(wù)器的負(fù)載均衡中添加一個(gè)Pod。默認(rèn)情況下，“ready”只意味著Pod的所有容器已經(jīng)啟動(dòng)，Kubernetes可以執(zhí)行它們。但是，如果要建立數(shù)據(jù)庫(kù)的連接，并在啟動(dòng)時(shí)運(yùn)行模式遷移，可能會(huì)需要一段時(shí)間，很顯然我們需要更好的定義"ready"。

從業(yè)務(wù)的角度看，我們的微服務(wù)已經(jīng)準(zhǔn)備就緒，可以開(kāi)始響應(yīng)終端用戶(hù)的請(qǐng)求。因此，我們可以通過(guò)配置 HTTP readinessProbe將確切的信息告訴Kubernetes 。此外，我們需要在啟動(dòng)HTTP服務(wù)器之前創(chuàng)建數(shù)據(jù)庫(kù)連接并運(yùn)行遷移。

一般來(lái)說(shuō)，在每個(gè)Pod推出后稍等片刻也不是什么壞事。

現(xiàn)在，如果我們?cè)趩?dòng)時(shí)崩潰了，或者無(wú)法連接到數(shù)據(jù)庫(kù)，新部署失敗的Pod將不會(huì)被添加到“應(yīng)用程序?qū)印钡呢?fù)載均衡中，而rollout將在那里停止。這意味著，即使在這個(gè)階段出現(xiàn)問(wèn)題也不會(huì)影響到最終用戶(hù)。

Liveness（活躍度）

Kubernetes還會(huì)定期檢查Pod是否還“活著”，默認(rèn)情況下也是如此。在我們的示例中，如果數(shù)據(jù)庫(kù)客戶(hù)端以某種方式進(jìn)入損壞狀態(tài)，我們也許希望Kubernetes從負(fù)載均衡器中刪除受影響的pod，然后啟動(dòng)一個(gè)新的。這可以通過(guò)添加檢查（理想情況下，會(huì)代表系統(tǒng)的健康狀況）、將其揭示給Kubernetes或者配置一個(gè)livenessProbe來(lái)實(shí)現(xiàn)。

Rolling back（回滾）

但是如果操作失敗，你也許想要回滾到最新的工作版本。良好的工程實(shí)踐可以幫助實(shí)現(xiàn)這一點(diǎn)。在我們的場(chǎng)景中，最主要的是我們微服務(wù)數(shù)據(jù)庫(kù)模式的向后兼容性。

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

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

這中間可能會(huì)出現(xiàn)很多問(wèn)題，所以需要你仔細(xì)測(cè)試一下。

對(duì)于大型系統(tǒng)，您可能需要研究“blue-green deployments（藍(lán)綠部署）”，但這實(shí)現(xiàn)起來(lái)會(huì)很困難。

少說(shuō)話(huà)，多行動(dòng)！

想要實(shí)現(xiàn)這些設(shè)置，可以參考以下建議。

我們建議使用Weave Cloud，因?yàn)樗梢允骨昂鬂L變得簡(jiǎn)單易行，并且還可以在您更改系統(tǒng)時(shí)提供完整的系統(tǒng)可觀性。

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

并且您可以任意查詢(xún)收集到的指標(biāo)，并清楚的看到新版本（藍(lán)色垂直線(xiàn)）的影響。

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