備份Kubernetes和Docker方法

使用者不必備份容器中的所有內容，但在發生災難時備份執行和管理容器的配置是很重要的。使用者的容器基礎設施需要某種型別的備份。Kubernetes和Docker在災難之後不會自己構建。使用者無需備份每個容器的執行狀態，但是需要備份用於執行和管理容器的配置。

使用者的容器基礎設施需要某種型別的備份。Kubernetes和Docker在災難之後不會自己構建。使用者無需備份每個容器的執行狀態，但是需要備份用於執行和管理容器的配置。

以下是使用者需要備份的內容。

• Dockerfile用於構建鐿像以及這些檔案的所有版本
• 從Dockerfile建立並用於執行每個容器的映象
• Kubernetes etcd和其他有關叢集狀態的K8s資料庫
• Deployments用於描述每個部署的YAML檔案
容器建立或更改的持久資料
• 持久卷
• 資料庫
Dockerfiles

Docker容器從映象執行，其映象從Dockerfiles構建。正確的Docker配置將首先使用某種儲存庫(例如GitHub)作為所有Dockerfile的版本控制系統。不要使用從臨時Dockerfile構建的臨時映象建立臨時容器。所有Dockerfile都應儲存在儲存庫中，如果當前版本存在問題，該儲存庫將允許使用者提取這個Dockerfile的歷史版本。

使用者還應該具有儲存與每個K8s部署關聯的YAML檔案的某種儲存庫，這些是可以從版本控制系統中受益的文字檔案。

然後需要備份這些儲存庫。GitHub是比較受歡迎的儲存庫之一，它提供了許多備份儲存庫的方法。有多種 使用提供的API來下載儲存庫的當前備份。使用者還可以使用第三方商業工具來備份GitHub或使用者正在使用的任何儲存庫。

如果沒有遵循上述建議，而是根據不再具有Dockerfile的映象執行容器，則可以使用Docker 映象歷史 或dfimage之類的工具從當前映象建立Dockerfile。將這些Dockerfile放入儲存庫中，然後開始備份。但是不要陷入這種情況，應該始終儲存和備份用於建立環境的Dockerfile和YAML檔案。

Docker映象

用於執行容器的當前映象也應儲存在儲存庫中(當然，如果使用者正在Kubernetes中執行Docker映象，那麼已經在這樣做了)。使用者可以使用私有儲存庫(例如Docker登錄檔)或公共儲存庫(例如Dockerhub)。雲端計算提供商還可以為使用者提供私人儲存庫來儲存映象。然後應備份該回購的內容。諸如“Dockerhub備份”之類的簡單搜尋就可以產生令人驚訝的眾多選擇。

如果使用者沒有用於執行容器的當前映象，則可以使用docker commit 建立一個。然後，使用Docker映象歷史記錄或工具dfimage從該映象建立Dockerfile。

Kubernetes etcd

Kubernetes etcd資料庫非常重要，應使用etcdctl snapshot save db命令進行備份。這將在當前目錄中建立檔案snapshot.db。然後應將該檔案備份到外部儲存。

如果使用的是商業備份軟體，則可以在建立snapshot.db的目錄備份之前輕鬆觸發etcdctl snapshot save命令。這是將備份整合到商業備份環境中的一種方法。

持久卷

容器可以透過多種方式訪問永續性儲存，而永續性儲存可用於儲存或建立資料。傳統的Docker卷位於Docker配置的子目錄中。繫結掛載只是Docker主機上安裝在容器內(使用bind mount命令)的任何目錄。出於多種原因，Docker社群首先選擇傳統卷，但出於備份目的，傳統卷和繫結安裝實質上是相同的。使用者還可以將網路檔案系統(NFS)目錄或物件從物件儲存系統作為卷裝入容器中。

用於備份持久卷的方法將基於用於容器的上述選項。但是，它們都會有相同的問題：如果資料正在更改，則需要處理該問題才能獲得一致的備份。

一種方法是關閉使用該特定卷的任何容器。這種做法雖然有些過時，但這是容器世界所面臨的挑戰之一，因為在容器中放置備份代理的典型方法並不是一種很好的選擇。一旦關閉，便可以備份該卷。如果它是傳統的Docker卷，則可以透過將其掛載到另一個在備份時不會更改其資料的容器中進行備份，然後在繫結安裝的卷中建立該卷的tar映象，然後使用備份系統使用的任何方法進行備份。

但是，這在Kubernetes中確實很難做到。這是有狀態資訊最好儲存在資料庫而不是檔案系統中的原因之一。而在設計K8s基礎設施時，需要考慮此問題。

另外，如果使用者使用繫結安裝目錄、NFS安裝檔案系統或物件儲存系統作為永續性儲存系統，則可以使用優秀的方法來備份該儲存系統。這可能是快照，然後是複製，或者只是在該系統上執行商業備份軟體。與相同卷的典型檔案級備份相比，這些方法可能提供更加一致的備份。

資料庫

下一個備份挑戰是容器使用資料庫儲存其資料。這些資料庫需要以保證其完整性的方式進行備份。根據資料庫的不同，上述方法可能會起作用：關閉訪問資料庫的容器，然後備份儲存其檔案的目錄。但是，這種方法所需的停機時間可能不合適。

另一種方法是直接連線到資料庫引擎本身，並要求它執行到檔案的備份，然後可以對其進行備份。如果資料庫在容器內執行，則首先需要使用繫結安裝來附加一個可以備份的卷，因此其備份可以存在於容器外部。然後執行資料庫使用的命令(例如mysqldump)建立備份。然後確保使用備份系統建立的檔案。

如果使用者不知道哪些容器正在使用什麼樣的儲存或什麼樣的資料庫怎麼辦?一種解決方案可能是使用docker ps命令列出正在執行的容器，然後使用docker inspect命令顯示每個容器的配置。有一個名為“掛載”的部分，它將告訴使用者將哪些卷掛載在何處。任何繫結安裝也將在使用者提交給Kubernetes的YAML檔案中指定。

商業備份解決方案

有各種各樣的商業備份解決方案可以保護上述部分或全部資料。以下是一個非常簡短的摘要：

• Commvault的虛擬伺服器代理可以充當備份容器及其映象的代理。
• Cohenity為K8s名稱空間提供資料保護。
• Heptio(現為VMware公司)提供為K8s設計的Velero備份。
• Contino、Datacore和Portworx提供專為K8和容器設計的儲存，並且還支援備份該資訊。

鑑於K8和Docker的配置方式多種多樣，很難涵蓋所有內容。但是希望提供一些思考的機會，或者可以幫助使用者備份一些應該但尚未備份的東西。

原文地址：