一個大問題是如何保護我們的數據，特別是如何移動和訪問數據，而不僅僅是停留在一個云提供商上。

譯自Lack of Data Mobility Is a Root Cause of Cloud Native Ills，作者 B Cameron Gain。

巴黎 — 如今，很難找到不為云服務價格上漲而苦惱的人。同樣，許多人都在為如何嘗試其他云提供商而苦惱，他們通過試用不同的選項來了解它們在做出重大供應商轉換之前如何運作。其他人剛剛開始使用三大云提供商之一部署或轉向云原生，而且許多人甚至不知道從哪里或如何開始。

一個大問題是如何保護我們的數據，特別是如何移動和訪問數據，而不僅僅是停留在一個云提供商上，而這個云提供商又經常尋求漲價。我們如何根據需要按需擴展不同云提供商和本地服務？在云原生領域，這種情況也會發生，不是如果，而是很可能在發生勒索軟件攻擊時發生。然后會發生什么？我們真的準備好了嗎？而且，尤其是在今天，許多組織的云賬單越來越高，這需要更嚴格的成本管理。

簡單的虛擬化工具無法提供必要的控制來管理跨各種云環境的數據和應用程序，也無法找到節省成本的方法。簡單的存儲快照和其他快捷方式不足以防止數據丟失和攻擊。例如，移植虛擬機需要非常仔細的規劃和遠見。

Veeam Software的全球技術專家Michael Cade在KubeCon + CloudNativeCon Europe上告訴 The New Stack：“雖然可以輕松地將虛擬機從本地環境遷移到云環境，而無需精簡，但這并不意味著這是正確的，并且在數據安全和保護方面不應該有更多考慮。”“遷移到云并提升和轉移虛擬機是一回事，但這應該只是一個開始，否則組織會發現自己在云賬單上花費巨資或遇到其他問題。目標必須是重構和重新架構為基于云原生的適當工作負載。”

“在云中使用基于云的工作負載非常容易，而無需過多擔心成本和安全風險——你只需將它們提升并放入其中即可。”“但這不會奏效，因為你必須有一個計劃，了解你首先要做什么。”

Portworx的產品管理和云高級總監Cody Hosterman告訴 The New Stack，在不同云環境之間移動數據需要仔細考慮，以確保成功實施。“雖然數據傳輸的過程——‘提升和轉移’遷移——看起來很簡單，但在新云環境中取得成功會帶來挑戰。”Hosterman 說。

Hosterman 說，成功實現遷移涉及在管理成本和維護基本功能之間取得微妙的平衡。“避免潛在的陷阱需要對現有基礎設施、應用程序和依賴項進行徹底評估，以確保與目標云環境兼容。”Hosterman 說，“例如，在新環境中配置資源是復制本地基礎設施的關鍵步驟。”

Matt Bator說：“對于那些在‘今天的公共云供應商 XYZ’上運營其業務的組織來說，他們希望在未來某個時候擁有遷移到其他地方的自由，或者在對他們來說經濟上最合理的地方運營。”Veeam的Kubernetes原生解決方案負責人，在KubeCon + CloudNativeCon North America期間表示。

我們不妨說，備份對于在 Kubernetes 上維護安全、受保護且可訪問的狀態工作負載至關重要。同時，備份的效果取決于你恢復它們的能力，Bator 說。“這就是這里的關鍵，無論我們是就地恢復，還是出于災難恢復的目的恢復到其他集群，或者我將其用作 Kubernetes 中的克隆例程的一部分，例如開發測試或用戶驗收測試。”Bator 說。

加密，“基于角色的訪問控制、審計和不可變性是‘基本賭注’”，Bator 說。“這些功能確保備份數據保持可靠。我現在希望能夠在不同云之間移動這些工作負載”，Bator 說。“對于無狀態工作負載來說，這有點簡單，對吧？容器化在工作負載的移動性方面為我們做了很多事情，但一旦我必須解決這些工作負載中的數據重力問題，并且我想定期執行此操作，也許我想啟用混合云災難恢復。

最終，將數據傳輸到那里很容易。使其成功并非易事。挑戰在于在不影響管理和功能的情況下使遷移具有成本效益。如果沒有周密的計劃和執行，組織就有可能出現性能不佳和資源損失，這強調了在整個過程中進行戰略決策的必要性。”

“一個適當的數據移動解決方案應該能夠直接與 Kubernetes 發行版交互”，Bator 說。“我不能只對工作節點進行快照，并認為分布在多個工作節點上的應用程序可以‘神奇地’恢復。因此，我需要從所有應用程序元數據開始”，他說。“我需要能夠與我的底層存儲基礎設施集成，以便能夠編排我數據的卷快照。我需要能夠以一種方式打包所有這些，以便在需要時將其從集群中取出。”

確保應用程序一致性的機制也很關鍵。不僅是數據庫，而且跨不同云和本地環境的所有工作負載都必須可以通過單個 Kubernetes API 訪問，以管理和提取所有這些信息。在 Kasten 的情況下，命名空間與集群上其他應用程序一起運行，這要歸功于自定義資源 API。通過藍圖等功能，可以與不同堆棧的其他組件集成，包括代碼策略或集成到自動化工具中，例如GitOps管道。

“我希望從我的自動化數據保護中完全消除摩擦，并確保在我每次在持續交付或持續部署管道將新代碼推送到生產環境之前，對我的應用程序進行快照、對我的應用程序進行備份”，Bator 說。“因此，這些再次是成為 Kubernetes 原生的部分重大優勢，而不是我將這個很酷的附加組件添加到我的 20 年備份中，它碰巧還可以與 Kubernetes 通信。”

勒索軟件很可怕

哪種墮落邪惡的人故意策劃勒索軟件攻擊，導致醫院、學校和日托中心死亡和傷害——公共服務設施除外？此類攻擊在各種類型的組織中持續發生，頻率驚人。Kubernetes 當然也不例外，并且在攻擊發生時做好真正恢復的準備至關重要，而且是可以做到的。

“勒索軟件惡棍仍然存在于 Kubernetes 世界中。我們對任何這些攻擊都無能為力，無論如何，我都希望能夠利用混合多云環境”，Bator 說。“我需要能夠依賴這些數據，因為這是我抵御勒索軟件惡棍的最后一道防線。”

開始

如何開始，誰的工作是開始？好吧，這應該是開發人員、運營人員和 CTO 之間的團隊合作。正如我所描述的，每個人都需要擁有或成為這種數據移動保險的一部分。這不僅僅是數據存儲和應用程序，尤其是對于無狀態應用程序及其權重。一旦部署，無論是在單個云提供商網絡上還是在混合結構中跨不同的云原生環境中，確保數據移動、存儲解決方案和災難恢復（例如在勒索軟件攻擊或無意中刪除數據的情況下）都至關重要。無縫工作。這不是關于單獨的解決方案；它應該是一個單一的解決方案。

許多人仍然“有點困惑，不知道誰擁有 Kubernetes 的備份。是開發人員嗎？是平臺工程團隊還是 DevOps 團隊？是傳統備份管理員嗎？” Bator 說。“我會說，這可能更像是一個‘與’命題，而不是一個‘或’命題。這是一個‘眾人拾柴火焰高’的方法。”