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