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

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

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

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

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

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

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

Portworx的產(chǎn)品管理和云高級總監(jiān)Cody Hosterman告訴 The New Stack，在不同云環(huán)境之間移動數(shù)據(jù)需要仔細考慮，以確保成功實施?！半m然數(shù)據(jù)傳輸?shù)倪^程——‘提升和轉移’遷移——看起來很簡單，但在新云環(huán)境中取得成功會帶來挑戰(zhàn)。”Hosterman 說。

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

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

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

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

最終，將數(shù)據(jù)傳輸?shù)侥抢锖苋菀住Ｊ蛊涑晒Σ⒎且资?。挑?zhàn)在于在不影響管理和功能的情況下使遷移具有成本效益。如果沒有周密的計劃和執(zhí)行，組織就有可能出現(xiàn)性能不佳和資源損失，這強調了在整個過程中進行戰(zhàn)略決策的必要性?！?/p>

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

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

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

勒索軟件很可怕

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

“勒索軟件惡棍仍然存在于 Kubernetes 世界中。我們對任何這些攻擊都無能為力，無論如何，我都希望能夠利用混合多云環(huán)境”，Bator 說?！拔倚枰軌蛞蕾囘@些數(shù)據(jù)，因為這是我抵御勒索軟件惡棍的最后一道防線。”

開始

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

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