建站
咨詢
售后
建站咨詢
新聞中心
現(xiàn)在一切都變成了“Gitops”，所有的工作負(fù)載都變成了“無(wú)狀態(tài)”，我還需要 Kubernetes 備份工具嗎？我想向您展示，這是一個(gè)初學(xué)者經(jīng)常會(huì)犯的嚴(yán)重誤解......
譯自Kubernetes is not stateless, you need a backup tool，作者是 Michael Courcy 。
一種奇怪的假設(shè)
我們經(jīng)常聽(tīng)到使用 Kubernetes 的客戶和潛在客戶提出這樣一個(gè)奇怪的假設(shè):
有了 Kubernetes，現(xiàn)在一切都變成 Gitops 和無(wú)狀態(tài)了！
因此：
既然一切都變成了“Gitops”，所有的工作負(fù)載都變成了“無(wú)狀態(tài)”，我還需要 Kubernetes 備份工具嗎？
我想向您展示，這是一個(gè)初學(xué)者經(jīng)常會(huì)犯的嚴(yán)重誤解。他們希望現(xiàn)在災(zāi)難恢復(fù)管理只是重啟一個(gè)工具鏈那么簡(jiǎn)單，他們不需要投資任何備份工具。
這里對(duì)無(wú)服務(wù)器和無(wú)狀態(tài)之間存在混淆，從開(kāi)發(fā)人員的角度來(lái)看，kubernetes 是無(wú)服務(wù)器的，但絕對(duì)不是無(wú)狀態(tài)的......
但是在深入探討這個(gè)問(wèn)題之前，我們先明確這些不同的詞：Gitops、無(wú)狀態(tài)和工具鏈。
Gitops 和 無(wú)狀態(tài)
Gitops 是一種 Devops 實(shí)踐，使用 GIT 和 CI/CD 工具來(lái)應(yīng)用基礎(chǔ)設(shè)施自動(dòng)化。您通過(guò)在 GIT 中提交新的代碼更改來(lái)聲明您的基礎(chǔ)設(shè)施，然后 CI/CD 工具會(huì)自動(dòng)部署/應(yīng)用您的更改。
無(wú)狀態(tài)意味著應(yīng)用程序沒(méi)有持久值，如果您從零重新部署應(yīng)用程序，它會(huì)像以前一樣繼續(xù)工作。無(wú)狀態(tài)應(yīng)用程序不會(huì)在任何存儲(chǔ)介質(zhì)上維護(hù)數(shù)據(jù)。
工具鏈?zhǔn)菑?GIT 獲取代碼并對(duì)此代碼執(zhí)行不同操作以構(gòu)建基礎(chǔ)設(shè)施的一組工具。如果工具鏈產(chǎn)生的結(jié)果不依賴于先前執(zhí)行的狀態(tài)，則該工具鏈被稱為冪等的。一個(gè)好的工具鏈應(yīng)該是冪等的。
容器強(qiáng)化了無(wú)狀態(tài)的感覺(jué)
容器化強(qiáng)化了這種無(wú)狀態(tài)的想法，因?yàn)槿萜鳌鞍边\(yùn)行應(yīng)用程序所需的所有依賴項(xiàng)。鏡像定義了此依賴項(xiàng)列表，容器是此鏡像的短暫實(shí)例。如果您失去運(yùn)行容器的機(jī)器，這并不是什么大事，只需要在另一臺(tái)機(jī)器上從鏡像重新部署一個(gè)新的容器實(shí)例即可。容器運(yùn)行時(shí)將從鏡像定義重建所有文件，這樣您就可以長(zhǎng)期運(yùn)行了。
但是，如果容器使用卷，這就不是真的。例如，數(shù)據(jù)庫(kù)容器將使用卷來(lái)寫入其數(shù)據(jù)。在這種情況下，容器是有狀態(tài)的。如果您失去卷，您的數(shù)據(jù)庫(kù)將為空重新啟動(dòng)。
容器是無(wú)狀態(tài)的，除非它們是有狀態(tài)的。聽(tīng)起來(lái)很愚蠢？我同意......
您可能會(huì)驚訝地發(fā)現(xiàn)，2023年 Datadog 的最新報(bào)告(事實(shí)6)顯示：
數(shù)據(jù)庫(kù)和 Web 服務(wù)器是容器的主要工作負(fù)載類別。
是的，您沒(méi)有看錯(cuò)，容器的主要工作負(fù)載類別是有狀態(tài)的！
隨著 Kubernetes，“無(wú)狀態(tài)”的感覺(jué)達(dá)到了另一個(gè)閾值，現(xiàn)在您甚至不需要記住在哪臺(tái)機(jī)器上部署了哪些容器，因?yàn)?Kubernetes 會(huì)為您處理這個(gè)問(wèn)題，并動(dòng)態(tài)處理您的期望狀態(tài)。Kubernetes 讓您強(qiáng)烈感覺(jué)到您可以完全抽象出基礎(chǔ)設(shè)施，只有代碼才重要。
您仍然必須在 Kubernetes 中定義“期望狀態(tài)”，如負(fù)載均衡器來(lái)公開(kāi)您的應(yīng)用程序，副本數(shù)，內(nèi)存和 CPU，機(jī)密，配置文件等。但所有這些都定義在您應(yīng)用于 Kubernetes 的 YAML 文件中，并且您在 GIT 中維護(hù)它們。
但是等等！我們?nèi)匀槐仨殬?gòu)建和保護(hù) Kubernetes 集群；這是一個(gè)復(fù)雜的任務(wù)，對(duì)嗎？
不再如此！現(xiàn)在云可以在一分鐘內(nèi)構(gòu)建 Kubernetes 集群。只需在 AWS 或 Azure 控制臺(tái)中點(diǎn)擊一下，執(zhí)行一個(gè)簡(jiǎn)單的 “glcoud containers create...” 命令，或者只需要在 GIT 中定義一個(gè)新的集群定義，并連接到云 API 的 CI/CD 工具，就可以了。
現(xiàn)在一切都“無(wú)狀態(tài)”的感覺(jué)正在急劇增長(zhǎng)！
當(dāng)我們談?wù)撛?Kubernetes 上進(jìn)行備份時(shí)，我們遇到了真誠(chéng)地感到困惑的潛在客戶......
現(xiàn)在是時(shí)候再次接觸現(xiàn)實(shí)，并談?wù)摤F(xiàn)實(shí)情況了。
現(xiàn)實(shí)中不存在無(wú)狀態(tài)的應(yīng)用
如果把應(yīng)用程序作為一個(gè)整體來(lái)看，您會(huì)很快意識(shí)到現(xiàn)實(shí)中不存在無(wú)狀態(tài)應(yīng)用程序。試想一個(gè)在線商店，它不維護(hù)訂單，不維護(hù)客戶的地址。想象一個(gè)銀行應(yīng)用程序，它不管理交易。這樣說(shuō)聽(tīng)起來(lái)可能很荒謬且明顯，但重要的是要重新連接到現(xiàn)實(shí)。
如果一個(gè)應(yīng)用程序真的無(wú)狀態(tài)，那么很有可能它將是無(wú)用的。
那么我們?yōu)槭裁匆務(wù)摕o(wú)狀態(tài)呢？因?yàn)閼?yīng)用程序的一部分是無(wú)狀態(tài)的。例如，一個(gè)無(wú)狀態(tài)的 Node.js 前端正在向一個(gè)有狀態(tài)的 PostgreSQL 數(shù)據(jù)庫(kù)發(fā)出請(qǐng)求。從功能的角度來(lái)看，整個(gè)應(yīng)用程序是相當(dāng)有狀態(tài)的。您將應(yīng)用程序分成兩部分，一部分無(wú)狀態(tài)，另一部分有狀態(tài)，這并不意味著您不再需要管理數(shù)據(jù)。
是的，但是我的數(shù)據(jù)庫(kù)在 Kubernetes 集群之外，我的模式仍然有效，對(duì)嗎？
如果您的數(shù)據(jù)庫(kù)在 Kubernetes 集群之外，您將面臨一些真正的挑戰(zhàn)，這將嚴(yán)重影響您的 GitOps 方法。讓我們?cè)敿?xì)看看它們。
您希望數(shù)據(jù)庫(kù)像其他組件一樣成為 Kubernetes 的公民。
共定位的挑戰(zhàn)
如果數(shù)據(jù)庫(kù)在 Kubernetes 集群之外，您將面臨共定位挑戰(zhàn)，這將打破您的“無(wú)狀態(tài)”方法。的確，您不能把數(shù)據(jù)庫(kù)放得離工作負(fù)載太遠(yuǎn)，否則您將面臨嚴(yán)重的性能問(wèn)題。
因此，出于很好的原因，您的數(shù)據(jù)庫(kù)和 Kubernetes 集群在同一個(gè)網(wǎng)絡(luò)上。現(xiàn)在，您遇到了災(zāi)難，破壞了您的基礎(chǔ)設(shè)施。重建 Kubernetes 集群在其他地方很容易(記住它是完全無(wú)狀態(tài)和 GitOps 的)，但是您的數(shù)據(jù)庫(kù)怎么辦？您必須實(shí)例化新的數(shù)據(jù)庫(kù)機(jī)器并重新應(yīng)用您的轉(zhuǎn)儲(chǔ)。這并不很干凈，也不很“GitOps”。
那么怎么樣？您的 GitOps 實(shí)踐在您的數(shù)據(jù)庫(kù)啟動(dòng)時(shí)就停止了嗎？DevOps 意味著開(kāi)發(fā)和運(yùn)維共享他們的憂慮，您難道不違反這條規(guī)則嗎？
遷移的挑戰(zhàn)
這并不是由于災(zāi)難，而是您想要遷移到另一個(gè)提供商以節(jié)省資金，Kubernetes 部分很簡(jiǎn)單，但數(shù)據(jù)庫(kù)部分風(fēng)險(xiǎn)很大，因?yàn)槟匀灰耘f方式管理這部分。您要權(quán)衡您通過(guò)遷移節(jié)省的資金與您承擔(dān)的數(shù)據(jù)庫(kù)風(fēng)險(xiǎn)。這種體系結(jié)構(gòu)真的減少了您的選擇自由。
可測(cè)試性挑戰(zhàn)
您的開(kāi)發(fā)人員和 QA 團(tuán)隊(duì)需要使用實(shí)際數(shù)據(jù)測(cè)試應(yīng)用程序，您需要將數(shù)據(jù)庫(kù)的副本復(fù)制到另一臺(tái)機(jī)器或一組機(jī)器上，并確保測(cè)試實(shí)例的配置不指向生產(chǎn)數(shù)據(jù)庫(kù)?，F(xiàn)在，您想增加開(kāi)發(fā)和 QA 團(tuán)隊(duì)的數(shù)量，就需要增加機(jī)器和配置更改的數(shù)量。如果數(shù)據(jù)庫(kù)在 Kubernetes 中與應(yīng)用程序在同一命名空間中管理，您甚至不會(huì)考慮這個(gè)問(wèn)題。備份工具將在一分鐘內(nèi)將您的應(yīng)用程序恢復(fù)到其他位置。
數(shù)據(jù)庫(kù)/應(yīng)用程序版本不匹配的挑戰(zhàn)
您還必須映射您的鏡像版本與您的數(shù)據(jù)庫(kù)方案版本。這不是很容易管理的，在我的開(kāi)發(fā)人員職業(yè)生涯中，我已經(jīng)看到許多數(shù)據(jù)庫(kù)方案與應(yīng)用程序版本之間的不匹配。意外的模式更改和數(shù)據(jù)轉(zhuǎn)換會(huì)損壞您的數(shù)據(jù)，并可能會(huì)產(chǎn)生極大的后果。
微服務(wù)的挑戰(zhàn)
您的開(kāi)發(fā)團(tuán)隊(duì)非常敏捷，希望發(fā)展為微服務(wù)架構(gòu)。此架構(gòu)需要構(gòu)建幾個(gè)數(shù)據(jù)庫(kù)，通常用于不同目的(例如，Elasticsearch、Redis、MongoDB 和 PostgreSQL 提供不同的功能)，但如果以舊方式管理數(shù)據(jù)庫(kù)，則很難接受這種多樣性。它將我們之前列出的所有挑戰(zhàn)乘以數(shù)據(jù)庫(kù)和數(shù)據(jù)庫(kù)類型的數(shù)量。很有可能，隨著應(yīng)用程序的發(fā)展，您將拒絕此更改，并通過(guò)使數(shù)據(jù)庫(kù)成為實(shí)際單體來(lái)加強(qiáng)應(yīng)用程序的單體性質(zhì)。
如果您不將數(shù)據(jù)庫(kù)移至 Kubernetes，隨著應(yīng)用程序的發(fā)展，您將使應(yīng)用程序更加單一化。
成本挑戰(zhàn)
在 Kubernetes 上部署應(yīng)用程序可以大大減少應(yīng)用程序的成本。但這對(duì)數(shù)據(jù)庫(kù)部分并不適用。Kubernetes 優(yōu)化您的計(jì)算資源，為什么數(shù)據(jù)庫(kù)會(huì)是一個(gè)例外？
我們?cè)诂F(xiàn)場(chǎng)觀察到的情況
出于所有這些原因，數(shù)據(jù)庫(kù)將逐漸進(jìn)入您的 Kubernetes 集群。這就是我們?cè)诂F(xiàn)場(chǎng)觀察到的情況。
第一步是為測(cè)試和開(kāi)發(fā)而進(jìn)行的，以允許在 Kubernetes 中部署數(shù)據(jù)庫(kù)，這更便宜、更容易管理。
然后，團(tuán)隊(duì)注意到它的工作效果非常好，并且不再看到在 Kubernetes 之外維護(hù)數(shù)據(jù)庫(kù)的意義。他們希望使用具有不同功能的其他數(shù)據(jù)庫(kù)，等待 DBA 團(tuán)隊(duì)與他們同步通常太長(zhǎng)，他們會(huì)直接在自己的應(yīng)用程序命名空間中創(chuàng)建新數(shù)據(jù)庫(kù)。
您很快就會(huì)發(fā)現(xiàn)自己維護(hù)一種“精神分裂”模式，數(shù)據(jù)庫(kù)的一部分在 Kubernetes 之外，另一部分在內(nèi)部。
您最終會(huì)將大多數(shù)數(shù)據(jù)庫(kù)移到 Kubernetes 內(nèi)部，這是不可避免的。
現(xiàn)在您需要一個(gè)強(qiáng)大的 Kubernetes 備份工具......
一切都是 GitOps ...... 不真實(shí)(大多數(shù)時(shí)候)
理論上，所有內(nèi)容都是代碼，在所有級(jí)別上，您都以“As Code”的精神進(jìn)行自動(dòng)化，換句話說(shuō)，您試圖 100% 聲明式。
例如:
- 您使用 Terraform 代碼來(lái)創(chuàng)建網(wǎng)絡(luò)、云服務(wù)、Kubernetes 集群等
- 您使用 Argo CD 來(lái)部署主要的 Kubernetes 工具，如 cert-manager、Istio 等
- 您使用 Tekton 來(lái)構(gòu)建、測(cè)試和推送應(yīng)用程序鏡像
- 您使用 Helm Chart 部署應(yīng)用程序及其特定配置
所有這些都是偉大的，當(dāng)然我們只能批準(zhǔn)這些實(shí)踐的執(zhí)行。但現(xiàn)實(shí)情況并不像看起來(lái)那么光明......
- 構(gòu)建所有這些鏈?zhǔn)焦ぞ咝枰艽蟮呐?；您不一定有全部人力資源
- 有時(shí)一小時(shí)內(nèi)的熱修復(fù)絕對(duì)是必需的，而鏈?zhǔn)焦ぞ邿o(wú)法處理這種情況
- 您的工具鏈旨在重新部署太多組件，而您不能允許重新部署，您只想重新部署特定組件，因此您會(huì)手動(dòng)執(zhí)行
- 現(xiàn)在，您被要求部署同一基礎(chǔ)架構(gòu)的多個(gè)實(shí)例，但某些參數(shù)化沒(méi)有考慮到這一點(diǎn)，重新開(kāi)發(fā)整個(gè)工具鏈與手動(dòng)更改相比，這會(huì)使您選擇后者
- 應(yīng)用程序不再發(fā)展，只需要開(kāi)發(fā)人員偶爾修復(fù)一些錯(cuò)誤；您不會(huì)重新投資工具鏈。開(kāi)發(fā)人員將手動(dòng)應(yīng)用更改，這有時(shí)會(huì)持續(xù)多年。
- 許多工具鏈(由不同團(tuán)隊(duì)維護(hù))針對(duì)單個(gè)應(yīng)用程序，隨著不同工具鏈的代碼演變，重建應(yīng)用程序在給定時(shí)間點(diǎn)的確切狀態(tài)并不容易。
這個(gè)列表并不詳盡，每次我認(rèn)真研究任何項(xiàng)目時(shí)，在不同級(jí)別我都能看到并非所有內(nèi)容都是“作為代碼”?？傆幸粔K(有時(shí)是大塊)異常會(huì)打破這一理論過(guò)程。
最后，真理的源頭是 Kubernetes，您需要一個(gè)能夠正確捕獲它的工具。
GitOps 可能會(huì)中斷，這比您想象的要頻繁
所有這些工具鏈(Terraform、ArgoCD、Tekton ......)甚至云提供商提供的工具鏈(Azure DevOps、GitHub Action、CodeFresh、AWS ......)都只是在機(jī)器上執(zhí)行的程序，它們也可能由于許多原因而中斷。它們也可能僅由于人為錯(cuò)誤或不再工作的依賴項(xiàng)而中斷。
例如，我記得有一個(gè)工具鏈用于掃描 Docker 鏡像中的漏洞，這個(gè)工具必須傳遞所有鏡像才能允許部署過(guò)程繼續(xù)。不幸的是，此工具暫時(shí)中斷，并且由于另一個(gè)原因(您知道災(zāi)難總是聚集在一起...)集群中斷，必須恢復(fù)應(yīng)用程序。當(dāng)時(shí)沒(méi)有人知道如何在不進(jìn)行安全掃描的情況下重建工具鏈。應(yīng)用程序已經(jīng)部署這一事實(shí)如果您要再次部署，您必須通過(guò)此步驟。
無(wú)法恢復(fù)應(yīng)用程序，團(tuán)隊(duì)不得不等待有人找出如何在沒(méi)有安全掃描的情況下重建工具鏈。最后沒(méi)有滿足 SLA 要求。
團(tuán)隊(duì)決定投資備份工具，該工具可以獨(dú)立于工具鏈重新安裝應(yīng)用程序。
此外，黑客也非常了解 GIT 存儲(chǔ)庫(kù)和工具鏈的重要性，他們可能決定破壞或銷毀它們。如果發(fā)生這種情況，您必須在能夠重用之前修復(fù)它們。這可能會(huì)嚴(yán)重影響您的恢復(fù)時(shí)間目標(biāo)。如果您完全丟失了 GIT 存儲(chǔ)庫(kù)，您將不得不在午夜叫醒您的一名開(kāi)發(fā)人員，并詢問(wèn)他們是否碰巧仍在筆記本電腦上擁有主分支。如果您認(rèn)為這種情況從未發(fā)生過(guò)，請(qǐng)三思......
GitOps 工具鏈用于開(kāi)發(fā)和部署，它不是備份工具。
例如，Kasten 具有不可變備份，可保證即使是不法管理員也無(wú)法銷毀您的備份。GIT 和工具鏈沒(méi)有設(shè)計(jì)用于此目的。請(qǐng)記住，大多數(shù)攻擊都是內(nèi)部攻擊。
Operator 改變了游戲規(guī)則
Operator 是 Kubernetes 上專門用于數(shù)據(jù)庫(kù)的 Controller。幾乎所有主要數(shù)據(jù)庫(kù)供應(yīng)商現(xiàn)在都提供他們的 Operator 版本。Operator 封裝了數(shù)據(jù)庫(kù)專家的知識(shí)，并使 Kubernetes 上的數(shù)據(jù)庫(kù)管理變得非常簡(jiǎn)單和受支持。
Operator 將幫助您擴(kuò)展或擴(kuò)展。您只需更改自定義資源中的一個(gè)字段(例如副本數(shù))，Operator 將執(zhí)行所有復(fù)雜的操作以滿足所需狀態(tài)，而不會(huì)中斷服務(wù)。
有了 Operator，就沒(méi)有理由不將數(shù)據(jù)庫(kù)移到 Kubernetes 中(如果您信任供應(yīng)商)。但有一點(diǎn)需要注意，就是 Operator 在 Kubernetes 中創(chuàng)建了大量更改(Secrets、Certificates、PVC ...)，現(xiàn)在比以往任何時(shí)候都更需要一個(gè)備份工具，該工具可以與 Operator API 協(xié)同工作。Kasten 基于 Kanister 的擴(kuò)展機(jī)制可以非常容易地在 Operator API 和備份操作之間進(jìn)行協(xié)調(diào)。
Kasten 不否定 GitOps 實(shí)踐，相反！
歸結(jié)這個(gè)話題的目的不是否定 GitOps 實(shí)踐帶來(lái)的價(jià)值。在 Kasten，我們每?jī)芍懿渴鹨淮危\(yùn)行大量自動(dòng)化部署和自動(dòng)化測(cè)試。如果我們不采用 DevOps(包括 GitOps)實(shí)踐，所有這些都不可能實(shí)現(xiàn)。
我還在這個(gè) Tekton 演示中展示了如何在部署新版本之前包含 Kasten 備份操作來(lái)捕獲應(yīng)用程序的快照。還有一個(gè) Azure DevOps 示例做了同樣的事情，但是使用 Azure DevOps 任務(wù)。所以 Kasten 與 GitOps 實(shí)踐配合得非常好。
但如果您認(rèn)為現(xiàn)在您是 GitOps 所以在 Kubernetes 上不需要備份工具，那將是一個(gè)錯(cuò)誤:
主要結(jié)論
- 您仍然需要捕獲最終的真實(shí)來(lái)源，即 Kubernetes，沒(méi)有別的。
- 您的數(shù)據(jù)庫(kù)最終會(huì)進(jìn)入 Kubernetes，因?yàn)樗箲?yīng)用程序和數(shù)據(jù)管理變得更容易操作并降低成本。因此，您將與應(yīng)用程序堆棧的其余部分一起對(duì)其進(jìn)行備份。
- 如果一切同時(shí)崩潰，您需要一個(gè)計(jì)劃B，以快速在其他地方重建，而不依賴于開(kāi)發(fā)資源。
網(wǎng)站題目：Kubernetes并非無(wú)狀態(tài)，您需要備份工具
轉(zhuǎn)載來(lái)于：http://www.5511xx.com/article/ccdjiph.html
