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

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

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

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

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

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

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

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

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

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

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

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

最終，將數(shù)據(jù)傳輸?shù)侥抢锖苋菀?。使其成功并非易事。挑?zhàn)在于在不影響管理和功能的情況下使遷移具有成本效益。如果沒有周密的計劃和執(zhí)行，組織就有可能出現(xiàn)性能不佳和資源損失，這強(qiáng)調(diào)了在整個過程中進(jìn)行戰(zhàn)略決策的必要性。”

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

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

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

勒索軟件很可怕

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

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

開始

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

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