如今，在云計算領域，越來越多的IT組織正在構建混合云和多云環境以支撐其業務運行。從容器的角度來看，我們知道，容器應用程序從一開始就內置了非常可觀的可移動性、靈活性和效率。但是對于容器數據來說，它的移動性又如何?如何構建一個數據框架來優化公有云，并為容器應用程序及其數據提供真正的移動性?

[[283725]]

容器和塊存儲

容器流行的原因很大一部分來自于Docker公司，該公司向我們介紹了容器運行時、應用程序庫和多節點(服務器)配置的框架。很快，Docker就被Kubernetes——谷歌的開源容器平臺所納入。

這兩個平臺都使用基于塊的存儲來為容器數據提供持久性。最初，假定容器是無狀態的，就需要使用應用程序復制和冗余來維護對持久數據的訪問。但這被證明是不切實際的，而且大家都認為我們需要某種形式的持久性存儲，即使是對于短期存在的容器也是如此。

塊存儲速度快，為應用程序提供低延遲。在容器部署中，塊存儲設備使用本地文件系統進行格式化并映射到容器中。根據使用要求，塊存儲設備可以在容器的生命周期內繼續使用，或者僅在容器運行時使用。

如果容器中的應用程序任務是可重新啟動的，那么塊存儲只需為容器數據提供可伸縮的快速存儲。通過可重新啟動，意味著應用程序組件可以用新格式化的空塊設備進行實例化。

然而，當我們走出這些簡單的界限時，存儲必須提供更多能力。例如，如果一個容器由于硬件或軟件故障而需要重新啟動，那么在現有塊存儲設備上重用數據可能是可行的，而不是從另一個源重新創建數據。如果應用程序的一部分必須移動到另一個物理位置，那么容器數據可能也必須移動。

構建一個數據平面框架

為了實現數據和應用程序遷移，我們需要為數據平面構建一個框架。基于此，數據將比任何單獨的容器壽命更長，并且需要跨多個數據中心和位置移動，這意味著可能還需要在公有云和本地位置之間移動。一個很好的例子是，需要將數據復制到公有云中，從而為測試/開發環境提供原料。

對象存儲是構建數據框架的多種方法之一。它本質上是可移動的，可以通過使用http(s)協議的廣域網進行訪問。對象存儲提供了跨距離復制的能力，并且可以輕松地跨平臺工作。對象存儲的主要挑戰是如何實現良好的安全性，并將數據映射到應用程序層次結構，例如，使用bucket和文件夾映射到應用程序名稱。

將塊和文件存儲添加到容器框架更加復雜。與文件存儲相比，塊存儲具有更低的延遲和更大的吞吐量，但現在情況已經不同了。使用諸如NVMe這樣的新型媒介，初創公司正在構建高性能、可伸縮的文件系統，這些系統既可以在場所中工作，也可以在公有云中工作。

本地塊存儲(如AWS的彈性計算云)的另一個挑戰是，這些設備只能連接到本地容器或虛擬實例。沒有直接的方法將公有云中的塊存儲復制到不同的提供商或本地位置中。

數據抽象

如果數據可移植性是必要的，那么比較好的選擇是構建一個獨立的數據平面，它不依賴于公有云提供商的本地存儲。目前也存在提供擴展塊和文件存儲的產品，這些產品可以跨越單個或多個地理位置。這包括合并公有云和私有云。

一些擴展產品可以在多個位置上顯示單個數據視圖，而其他產品使用快照來復制數據。這意味著需要復制數據并設置相應的進程，以確?？梢愿櫤凸芾磔^新的副本。當使數據在大范圍內可用時，將會有延遲問題。

API扮演的角色，以及更多的挑戰

生態系統開發人員已經開始添加用于存儲的API。Kubernetes有容器存儲接口(CSI)，它公開了一組用于創建和將卷附加到容器的功能。CSI確保存儲被成功映射到可以跨多個物理服務器部署的Pod中的容器。

Docker使用卷插件來實現與CSI相同的功能。然后，用戶可以從存儲硬件和軟件部署卷驅動程序，以確保將數據正確地從存儲映射到容器。

另外，涉及到與容器數據相關的存儲、多個容器部署以及平臺間無縫數據遷移時，我們仍然面臨這許多挑戰。例如，AWS Fargate只支持彈性云計算中的外部卷。