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

創(chuàng)新互聯(lián)是一家專注于網(wǎng)站制作、成都做網(wǎng)站與策劃設(shè)計,延壽網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)做網(wǎng)站,專注于網(wǎng)站建設(shè)十余年,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:延壽等地區(qū)。延壽做網(wǎng)站價格咨詢:18980820575

正文：

Architecture（架構(gòu)）

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

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

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

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

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

實施：自頂向下

Services（服務(wù)）

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

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

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

Pods

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

Deployments（部署）

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

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

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

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

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

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

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

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

•   簡單：在運(yùn)行時不會引入新的移動基礎(chǔ)架構(gòu)；

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

目前效果

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

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

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

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

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

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

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

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

實施：細(xì)節(jié)決定成??！

Rolling Out（推出）

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

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

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

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

當(dāng)Kubernetes認(rèn)為它已經(jīng)“準(zhǔn)備好（ready）”時，它會在其服務(wù)器的

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

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

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

Liveness（活躍度）

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

Rolling back（回滾）

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

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

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

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

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

少說話，多行動！

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

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

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

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

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