現在一切都變成了“Gitops”，所有的工作負載都變成了“無狀態”，我還需要 Kubernetes 備份工具嗎？我想向您展示，這是一個初學者經常會犯的嚴重誤解......

譯自Kubernetes is not stateless, you need a backup tool，作者是 Michael Courcy 。

一種奇怪的假設

我們經常聽到使用 Kubernetes 的客戶和潛在客戶提出這樣一個奇怪的假設:

有了 Kubernetes，現在一切都變成 Gitops 和無狀態了！

因此：

既然一切都變成了“Gitops”，所有的工作負載都變成了“無狀態”，我還需要 Kubernetes 備份工具嗎？

我想向您展示，這是一個初學者經常會犯的嚴重誤解。他們希望現在災難恢復管理只是重啟一個工具鏈那么簡單，他們不需要投資任何備份工具。

這里對無服務器和無狀態之間存在混淆，從開發人員的角度來看，kubernetes 是無服務器的，但絕對不是無狀態的......

但是在深入探討這個問題之前，我們先明確這些不同的詞：Gitops、無狀態和工具鏈。

Gitops 和 無狀態

Gitops 是一種 Devops 實踐，使用 GIT 和 CI/CD 工具來應用基礎設施自動化。您通過在 GIT 中提交新的代碼更改來聲明您的基礎設施，然后 CI/CD 工具會自動部署/應用您的更改。

無狀態意味著應用程序沒有持久值，如果您從零重新部署應用程序，它會像以前一樣繼續工作。無狀態應用程序不會在任何存儲介質上維護數據。

工具鏈是從 GIT 獲取代碼并對此代碼執行不同操作以構建基礎設施的一組工具。如果工具鏈產生的結果不依賴于先前執行的狀態，則該工具鏈被稱為冪等的。一個好的工具鏈應該是冪等的。

容器強化了無狀態的感覺

容器化強化了這種無狀態的想法，因為容器“包含”運行應用程序所需的所有依賴項。鏡像定義了此依賴項列表，容器是此鏡像的短暫實例。如果您失去運行容器的機器，這并不是什么大事，只需要在另一臺機器上從鏡像重新部署一個新的容器實例即可。容器運行時將從鏡像定義重建所有文件，這樣您就可以長期運行了。

但是，如果容器使用卷，這就不是真的。例如，數據庫容器將使用卷來寫入其數據。在這種情況下，容器是有狀態的。如果您失去卷，您的數據庫將為空重新啟動。

容器是無狀態的，除非它們是有狀態的。聽起來很愚蠢？我同意......

您可能會驚訝地發現，2023年 Datadog 的最新報告(事實6)顯示：

數據庫和 Web 服務器是容器的主要工作負載類別。

是的，您沒有看錯，容器的主要工作負載類別是有狀態的！

隨著 Kubernetes，“無狀態”的感覺達到了另一個閾值，現在您甚至不需要記住在哪臺機器上部署了哪些容器，因為 Kubernetes 會為您處理這個問題，并動態處理您的期望狀態。Kubernetes 讓您強烈感覺到您可以完全抽象出基礎設施，只有代碼才重要。

您仍然必須在 Kubernetes 中定義“期望狀態”，如負載均衡器來公開您的應用程序，副本數，內存和 CPU，機密，配置文件等。但所有這些都定義在您應用于 Kubernetes 的 YAML 文件中，并且您在 GIT 中維護它們。

但是等等！我們仍然必須構建和保護 Kubernetes 集群；這是一個復雜的任務，對嗎？

不再如此！現在云可以在一分鐘內構建 Kubernetes 集群。只需在 AWS 或 Azure 控制臺中點擊一下，執行一個簡單的 “glcoud containers create...” 命令，或者只需要在 GIT 中定義一個新的集群定義，并連接到云 API 的 CI/CD 工具，就可以了。

現在一切都“無狀態”的感覺正在急劇增長！

當我們談論在 Kubernetes 上進行備份時，我們遇到了真誠地感到困惑的潛在客戶......

現在是時候再次接觸現實，并談論現實情況了。

現實中不存在無狀態的應用

如果把應用程序作為一個整體來看，您會很快意識到現實中不存在無狀態應用程序。試想一個在線商店，它不維護訂單，不維護客戶的地址。想象一個銀行應用程序，它不管理交易。這樣說聽起來可能很荒謬且明顯，但重要的是要重新連接到現實。

如果一個應用程序真的無狀態，那么很有可能它將是無用的。

那么我們為什么要談論無狀態呢？因為應用程序的一部分是無狀態的。例如，一個無狀態的 Node.js 前端正在向一個有狀態的 PostgreSQL 數據庫發出請求。從功能的角度來看，整個應用程序是相當有狀態的。您將應用程序分成兩部分，一部分無狀態，另一部分有狀態，這并不意味著您不再需要管理數據。

是的，但是我的數據庫在 Kubernetes 集群之外，我的模式仍然有效，對嗎？

如果您的數據庫在 Kubernetes 集群之外，您將面臨一些真正的挑戰，這將嚴重影響您的 GitOps 方法。讓我們詳細看看它們。

您希望數據庫像其他組件一樣成為 Kubernetes 的公民。

共定位的挑戰

如果數據庫在 Kubernetes 集群之外，您將面臨共定位挑戰，這將打破您的“無狀態”方法。的確，您不能把數據庫放得離工作負載太遠，否則您將面臨嚴重的性能問題。

因此，出于很好的原因，您的數據庫和 Kubernetes 集群在同一個網絡上。現在，您遇到了災難，破壞了您的基礎設施。重建 Kubernetes 集群在其他地方很容易(記住它是完全無狀態和 GitOps 的)，但是您的數據庫怎么辦？您必須實例化新的數據庫機器并重新應用您的轉儲。這并不很干凈，也不很“GitOps”。

那么怎么樣？您的 GitOps 實踐在您的數據庫啟動時就停止了嗎？DevOps 意味著開發和運維共享他們的憂慮，您難道不違反這條規則嗎？

遷移的挑戰

這并不是由于災難，而是您想要遷移到另一個提供商以節省資金，Kubernetes 部分很簡單，但數據庫部分風險很大，因為您仍然以舊方式管理這部分。您要權衡您通過遷移節省的資金與您承擔的數據庫風險。這種體系結構真的減少了您的選擇自由。

可測試性挑戰

您的開發人員和 QA 團隊需要使用實際數據測試應用程序，您需要將數據庫的副本復制到另一臺機器或一組機器上，并確保測試實例的配置不指向生產數據庫。現在，您想增加開發和 QA 團隊的數量，就需要增加機器和配置更改的數量。如果數據庫在 Kubernetes 中與應用程序在同一命名空間中管理，您甚至不會考慮這個問題。備份工具將在一分鐘內將您的應用程序恢復到其他位置。

數據庫/應用程序版本不匹配的挑戰

您還必須映射您的鏡像版本與您的數據庫方案版本。這不是很容易管理的，在我的開發人員職業生涯中，我已經看到許多數據庫方案與應用程序版本之間的不匹配。意外的模式更改和數據轉換會損壞您的數據，并可能會產生極大的后果。

微服務的挑戰

您的開發團隊非常敏捷，希望發展為微服務架構。此架構需要構建幾個數據庫，通常用于不同目的(例如，Elasticsearch、Redis、MongoDB 和 PostgreSQL 提供不同的功能)，但如果以舊方式管理數據庫，則很難接受這種多樣性。它將我們之前列出的所有挑戰乘以數據庫和數據庫類型的數量。很有可能，隨著應用程序的發展，您將拒絕此更改，并通過使數據庫成為實際單體來加強應用程序的單體性質。

如果您不將數據庫移至 Kubernetes，隨著應用程序的發展，您將使應用程序更加單一化。

成本挑戰

在 Kubernetes 上部署應用程序可以大大減少應用程序的成本。但這對數據庫部分并不適用。Kubernetes 優化您的計算資源，為什么數據庫會是一個例外？

我們在現場觀察到的情況

出于所有這些原因，數據庫將逐漸進入您的 Kubernetes 集群。這就是我們在現場觀察到的情況。

第一步是為測試和開發而進行的，以允許在 Kubernetes 中部署數據庫，這更便宜、更容易管理。

然后，團隊注意到它的工作效果非常好，并且不再看到在 Kubernetes 之外維護數據庫的意義。他們希望使用具有不同功能的其他數據庫，等待 DBA 團隊與他們同步通常太長，他們會直接在自己的應用程序命名空間中創建新數據庫。

您很快就會發現自己維護一種“精神分裂”模式，數據庫的一部分在 Kubernetes 之外，另一部分在內部。

您最終會將大多數數據庫移到 Kubernetes 內部，這是不可避免的。

現在您需要一個強大的 Kubernetes 備份工具......

一切都是 GitOps ...... 不真實(大多數時候)

理論上，所有內容都是代碼，在所有級別上，您都以“As Code”的精神進行自動化，換句話說，您試圖 100% 聲明式。

例如:

• 您使用 Terraform 代碼來創建網絡、云服務、Kubernetes 集群等
• 您使用 Argo CD 來部署主要的 Kubernetes 工具，如 cert-manager、Istio 等
• 您使用 Tekton 來構建、測試和推送應用程序鏡像
• 您使用 Helm Chart 部署應用程序及其特定配置

所有這些都是偉大的，當然我們只能批準這些實踐的執行。但現實情況并不像看起來那么光明......

• 構建所有這些鏈式工具需要很大的努力；您不一定有全部人力資源
• 有時一小時內的熱修復絕對是必需的，而鏈式工具無法處理這種情況
• 您的工具鏈旨在重新部署太多組件，而您不能允許重新部署，您只想重新部署特定組件，因此您會手動執行
• 現在，您被要求部署同一基礎架構的多個實例，但某些參數化沒有考慮到這一點，重新開發整個工具鏈與手動更改相比，這會使您選擇后者
• 應用程序不再發展，只需要開發人員偶爾修復一些錯誤；您不會重新投資工具鏈。開發人員將手動應用更改，這有時會持續多年。
• 許多工具鏈(由不同團隊維護)針對單個應用程序，隨著不同工具鏈的代碼演變，重建應用程序在給定時間點的確切狀態并不容易。

這個列表并不詳盡，每次我認真研究任何項目時，在不同級別我都能看到并非所有內容都是“作為代碼”。總有一塊(有時是大塊)異常會打破這一理論過程。

最后，真理的源頭是 Kubernetes，您需要一個能夠正確捕獲它的工具。

GitOps 可能會中斷，這比您想象的要頻繁

所有這些工具鏈(Terraform、ArgoCD、Tekton ......)甚至云提供商提供的工具鏈(Azure DevOps、GitHub Action、CodeFresh、AWS ......)都只是在機器上執行的程序，它們也可能由于許多原因而中斷。它們也可能僅由于人為錯誤或不再工作的依賴項而中斷。

例如，我記得有一個工具鏈用于掃描 Docker 鏡像中的漏洞，這個工具必須傳遞所有鏡像才能允許部署過程繼續。不幸的是，此工具暫時中斷，并且由于另一個原因(您知道災難總是聚集在一起...)集群中斷，必須恢復應用程序。當時沒有人知道如何在不進行安全掃描的情況下重建工具鏈。應用程序已經部署這一事實如果您要再次部署，您必須通過此步驟。

無法恢復應用程序，團隊不得不等待有人找出如何在沒有安全掃描的情況下重建工具鏈。最后沒有滿足 SLA 要求。

團隊決定投資備份工具，該工具可以獨立于工具鏈重新安裝應用程序。

此外，黑客也非常了解 GIT 存儲庫和工具鏈的重要性，他們可能決定破壞或銷毀它們。如果發生這種情況，您必須在能夠重用之前修復它們。這可能會嚴重影響您的恢復時間目標。如果您完全丟失了 GIT 存儲庫，您將不得不在午夜叫醒您的一名開發人員，并詢問他們是否碰巧仍在筆記本電腦上擁有主分支。如果您認為這種情況從未發生過，請三思......

GitOps 工具鏈用于開發和部署，它不是備份工具。

例如，Kasten 具有不可變備份，可保證即使是不法管理員也無法銷毀您的備份。GIT 和工具鏈沒有設計用于此目的。請記住，大多數攻擊都是內部攻擊。

Operator 改變了游戲規則

Operator 是 Kubernetes 上專門用于數據庫的 Controller。幾乎所有主要數據庫供應商現在都提供他們的 Operator 版本。Operator 封裝了數據庫專家的知識，并使 Kubernetes 上的數據庫管理變得非常簡單和受支持。

Operator 將幫助您擴展或擴展。您只需更改自定義資源中的一個字段(例如副本數)，Operator 將執行所有復雜的操作以滿足所需狀態，而不會中斷服務。

有了 Operator，就沒有理由不將數據庫移到 Kubernetes 中(如果您信任供應商)。但有一點需要注意，就是 Operator 在 Kubernetes 中創建了大量更改(Secrets、Certificates、PVC ...)，現在比以往任何時候都更需要一個備份工具，該工具可以與 Operator API 協同工作。Kasten 基于 Kanister 的擴展機制可以非常容易地在 Operator API 和備份操作之間進行協調。

Kasten 不否定 GitOps 實踐，相反！

歸結這個話題的目的不是否定 GitOps 實踐帶來的價值。在 Kasten，我們每兩周部署一次，運行大量自動化部署和自動化測試。如果我們不采用 DevOps(包括 GitOps)實踐，所有這些都不可能實現。

我還在這個 Tekton 演示中展示了如何在部署新版本之前包含 Kasten 備份操作來捕獲應用程序的快照。還有一個 Azure DevOps 示例做了同樣的事情，但是使用 Azure DevOps 任務。所以 Kasten 與 GitOps 實踐配合得非常好。

但如果您認為現在您是 GitOps 所以在 Kubernetes 上不需要備份工具，那將是一個錯誤:

主要結論

• 您仍然需要捕獲最終的真實來源，即 Kubernetes，沒有別的。
• 您的數據庫最終會進入 Kubernetes，因為它使應用程序和數據管理變得更容易操作并降低成本。因此，您將與應用程序堆棧的其余部分一起對其進行備份。
• 如果一切同時崩潰，您需要一個計劃B，以快速在其他地方重建，而不依賴于開發資源。