云原生的那些坑
如今，幾乎所有圈里人，無論傳統(tǒng)IT老司機，還是互聯(lián)網(wǎng)弄潮兒，甲方也好，乙方也好，都知道 云原生 是個好東西。
所以，現(xiàn)在但凡上云，大家都要整“ 云原生的 ”，“夾生的”不要
不得不說，這波洗腦，可真徹底呀~
賣云的、用云的，談起云原生好處，全是溢美之詞，什么無與倫比的彈性、擴展性、可移植性、自動化能力、快速迭代能力…
這時候，理性的人就會站出來反思一下，從來就不存在那種“ 全是優(yōu)點、沒有缺點 ”的東西，不要整天光吹云原生的好，也要講講云原生的孬↓
風光無限的「云原生」，真有缺點嗎？
不光有，而且，還不少！
第一宗“罪”，云原生應用比單體程序更復雜。
云原生強調解耦，但解耦并不意味著簡單。傳統(tǒng)的單體程序，雖然看起來是個黑盒，有各種各樣的不好。但它通常基于單一代碼庫實現(xiàn)，也沒有多個模塊之間的通信和管理開銷，不需要什么額外的微服務治理。
所以，“設計圖”和“成品房”之間的體驗，差距不會太大，不容易爛尾。
而云原生應用則才采用微服務架構，單個微服務模塊是簡單了，但是要把多個模塊糅合起來，對API過度依賴。
不同模塊的抽象和設計就是一道坎，考驗架構師能力，而模塊間的通信開銷又考驗微服務治理能力……
總之吧，從“藍圖”到“成品”，任重道遠，搞不好還漏風漏雨。
第二宗“罪”，更多的工具依賴和學習成本。
從開發(fā)階段貫穿到運維階段，云原生引入了 更復雜的技術棧，很多還是全新的，不只是編程語言，還有從 K8S管理到各種CI/CD工具…，學習路徑極其陡峭。
沒有老師傅帶著，或者沒有真正的大規(guī)模DevOps實戰(zhàn)環(huán)境，靠以前學編程、學語言的方式，很難搞定。
第三宗“罪”，廠商鎖定風險。
云原生看起來是“解耦”和“開放”，API化是他們積極倡導的，但是畢竟到了PaaS這一層，每個云大廠的“黏性”還是極強的，尤其是像 Serverless 這樣的重度云原生架構，還沒有形成真正的標準化。
so，想要達到“ 一次編寫、到處執(zhí)行 ”的理想狀態(tài)，還有很長的路要走。
因此，云原生架構，可能形成云大廠對客戶的一波新鎖定。
但是你懂的，這點困難是難不倒IT人的，大家都一致看好云原生！
互聯(lián)網(wǎng)行業(yè)自不必說，云原生就是基因，而傳統(tǒng)IT也開始排除萬難，把業(yè)務一點點往云原生架構搬。
可是，當大家歷盡千辛萬苦，踩坑爬坡，云原生業(yè)務終于交付生產了，卻發(fā)現(xiàn) 過了這一山，還有那一坎
業(yè)務投產后，還有個巨大的坑沒有填： 這就是針對云原生業(yè)務的數(shù)據(jù)保護、容災備份。
為什么「備份」會成為云原生的一個巨坑？
首先，沒人敢忽視數(shù)據(jù)保護的重要性，稍微上點規(guī)模的企業(yè)級業(yè)務，都少不了備份基礎設施。
可是，能搞定傳統(tǒng)IT和虛擬化環(huán)境的備份軟件一大把，而你卻幾乎找不到一個靠譜的云原生數(shù)據(jù)保護平臺。
云原生業(yè)務和傳統(tǒng)IT架構差別太大，想做好備份和恢復，要面臨很多新挑戰(zhàn)。
第一，容器化與傳統(tǒng)VM/裸機的部署模式差異
在傳統(tǒng)IT架構下，無論裸機還是虛機，它們只是算力的顆粒度不同，但承載的大都是單體應用，以集中式架構為主。
備份目標很明確，易追蹤，好把控（磁盤、存儲卷、虛機鏡像、大型知名應用的備份接口等等）
云原生架構對應用的承載模式，就完全不一樣了，一個單體應用，被拆分成相對獨立的微服務模塊，然后，不同的微服務分別由不同的一組容器（Pods）來承載。
容器不僅改變了算力單元的顆粒度，還改變了應用的構建模式和運行模式，成了真正的分布式架構，這么一整，就讓傳統(tǒng)備份系統(tǒng)有點懵逼，理不清資源關系，找不到備份目標。
第二，要適配DevOps的高速滾動
云原生讓DevOps火了起來，傳統(tǒng)瀑布式開發(fā)逐漸被滾動式的敏捷開發(fā)所代替。這很順應當下大家對業(yè)務系統(tǒng)小步快跑、快速上線、頻繁迭代新功能的訴求。
在這樣一輪接一輪，小步快跑、頻繁變動的過程中，開發(fā)團隊需要有辦法來可靠的控制、遷移、和測試真實的應用數(shù)據(jù)，尤其針對那些“有狀態(tài)”容器（富含數(shù)據(jù)，比如數(shù)據(jù)庫或者消息總線）
傳統(tǒng)瀑布式開發(fā)，是一錘子買賣，不需要太多考慮，而敏捷開發(fā)必須要讓有狀態(tài)的CI/CD能夠攜帶數(shù)據(jù)正常流轉，這就要依賴同樣敏捷的數(shù)據(jù)備份和恢復技術，一般人搞不定。
第三，需要以應用為中心，保證數(shù)據(jù)一致性。
傳統(tǒng)備份場景，針對一些知名大型應用，比如Oracle、Exchange、SAP等等（其實VMware也算一種應用），也可以進行應用級備份，來保證數(shù)據(jù)的一致性。
但這一般都依賴于大型應用提供的備份接口，再借助于安裝備份代理，來完成應用級備份，比如Oracle備份，就要用到“O記”提供的RMAN工具和MML接口。
可云原生時代就大不一樣了，應用“又細又碎”，甚至要細到單個微服務級別，想要做到精準細致的應用級備份，幾乎不可能。
更要命的是，有些復雜的應用或服務，要么沒有專用持久存儲層，僅靠存儲級的備份搞不定，要么是有狀態(tài)的，無法保證一致性（ 數(shù)據(jù)文件和控制文件相一致 ），給未來的數(shù)據(jù)恢復帶來層層障礙。
第四，日益嚴峻的安全挑戰(zhàn)。
雖然云原生環(huán)境做數(shù)據(jù)保護很難，但圍繞K8S和容器的勒索攻擊可一點不消停，比如一種叫做“Siloscape”的勒索病毒，就專門感染K8S集群。
一旦被攻擊，又沒有靠譜的備份來恢復，除了付贖金，就只能“ 以頭搶地爾 ”了
怎么樣？沒想到吧，云原生業(yè)務風光的背后，竟然藏著這么多備份的坑兒
坑多就不干了嗎？不不不，必須要把坑填上！
所以，我今天要介紹一位卓越的“填坑”小能手，這位小能手，就是當代備份大咖 Veeam 旗下的 Kasten ↓
關于 Veeam ，就不用多費口舌了吧，那可是備份兵器譜上長期霸榜頭名的選手，總之吧，各種數(shù)據(jù)保護場景，選 Veeam 準沒錯！
而 Kasten 正是 Veeam 門下面向云原生場景的獨立品牌，不光出身名門，自己也特別能打，硬是在云原生領域闖出了一片天。
看看下面這個云原生數(shù)據(jù)保護的“專業(yè)擂臺賽”， Kasten 的所處位置，就是實力的象征。（ 這是由專業(yè)分析機構GigaOm出品的K8S數(shù)據(jù)保護雷達圖，越靠近中心代表越牛掰 ）
Kasten 的招牌產品，叫做 Kasten K10 ，是“ 專為Kubernetes設計的 ”云原生數(shù)據(jù)保護和管理平臺。
這么說吧，不管是你自己搭的小規(guī)模K8S集群，還是超大規(guī)模的K8S生產環(huán)境，或者是基于各類K8S發(fā)行版的云原生環(huán)境，K10都能幫大家填平備份的大坑，讓你沒有后顧之憂。
接下來，我們就給大家捋一捋，Kasten K10具體怎么填坑的？
在典型的云原生場景里，引入K10以后，架構是這樣的：K10就像集群里的一個平行Pod，與容器編排平臺（K8S或其他商業(yè)版本）和底層持久存儲都基于APIs來交流。
在上層，Kasten專門推出了一個開源數(shù)據(jù)管理框架 Kanister ，基于應用藍圖，進行有狀態(tài)的應用感知數(shù)據(jù)備份。
細看這張我畫了一天的圖，最下面是各類公有私有云平臺，然后是虛擬或物理的基礎設施（集群的工作N o de、 PM/VM 、容器持 久化存儲），再往 上是各類容器編排平臺（原生K8S或者各類商業(yè)發(fā)行版），最上面一層各種Pods，承載各類云原生應用（有狀態(tài)的、無狀態(tài)的、數(shù)據(jù)服務、移植應用）。
K10戳在這里，具體如何工作呢？這里面有三個關鍵點。
第一，應用發(fā)現(xiàn)。 K10通過K8S API來發(fā)現(xiàn)應用與應用部署的關聯(lián)關系，并發(fā)號施令，執(zhí)行數(shù)據(jù)管理生命周期操作。不管是原生K8S還是商業(yè)發(fā)行版各方諸侯，都能號得了脈、搭得上話。
第二，持久層可視。 有固定持久存儲卷的應用，好辦，探明關聯(lián)關系后，用卷備份來搞定；有些復雜應用，并沒有專用存儲層，那就基于API來追蹤。
說白了，以應用為核心，抽絲剝繭，找到對應的持久層備份源再下手。
第三，應用感知。 對于一些有狀態(tài)的應用，比如使用了數(shù)據(jù)庫，備份時必須要跟蹤狀態(tài)，從邏輯層進行備份，確保一致性，這是個大難題。而K10用Kanister這個神器，就可以輕松搞定。
簡單說呢，就是通過“應用藍圖”來獲知備份該應用所需要的模板資源，用哪種原生方法來獲取數(shù)據(jù)集（比如mysql用mysqldump），然后遵從業(yè)務邏輯，調用原生方法，來獲得應用一致的數(shù)據(jù)副本。
搞定這三個關鍵點，云原生備份的大坑就算填得七七八八了：?發(fā)現(xiàn)云原生應用以及對應的資源關系；?搞定不同類型的持久化存儲層?保證有狀態(tài)應用的數(shù)據(jù)一致性。
總之，Kasten K10的核心要義，就是以應用為中心， 應用捕獲→應用還原→應用遷移和容災 ，一條龍服務
做備份的那么多，為啥 Kasten K10 能成為云原生數(shù)據(jù)管理的扛把子？我來簡單總結下——
首先 ，K10本身就是云原生的，也把自己徹底融入到云原生的海洋里，實現(xiàn)了對Cloud Native生態(tài)的端到端適配（存儲架構、容器編排、分發(fā)平臺、數(shù)據(jù)服務）
第二 ，K10是以云原生應用為中心的數(shù)據(jù)管理平臺，把應用作為操作單元，支持基于應用感知的數(shù)據(jù)捕獲，保持數(shù)據(jù)一致性，這在云原生架構下，非常重要。
第三 ，K10是純軟件，不整啥備份一體機，簡單易用，自動化、可視化優(yōu)秀，運維操作起來毫無壓力，而對研發(fā)同學們也很友好，保留開放接口，研發(fā)可以擴展功能，支持更加復雜的特殊應用。
同時，在大規(guī)模DevOps場景下，讓有狀態(tài)的應用在CI/CD流程中快速流轉，是個老難題，而K10對有狀態(tài)應用的數(shù)據(jù)一致性能力，通過持續(xù)的“捕獲??恢復”，就能實現(xiàn)快速迭代。
第四 ， Veeam “備份世家”歷來重視數(shù)據(jù)安全，如今這個光榮傳統(tǒng)，也傳承到了Kasten的身上，K10的自動化應用捕獲與還原，本身就是防勒索的月光寶盒。
而且，還通過強大的驗證機制，保證被感染的數(shù)據(jù)不會誤備份，同時， “不可變存儲”則提供了更深層次的防護，確保已備份的數(shù)據(jù)不會被勒索病毒改寫。
事情講到這兒，結論已經(jīng)很明顯了， Veeam “世家”具備全場景的數(shù)據(jù)保護和管理能力。
不管是傳統(tǒng)架構還是云原生架構，云下的、云上的、多云的，不管穩(wěn)態(tài)業(yè)務還是敏態(tài)業(yè)務，物理的、虛擬的、應用級的、有狀態(tài)的、無狀態(tài)的，不管是備份、恢復、容災、遷移，還是數(shù)據(jù)管理、DevOps……，認準 Veeam 的金字招標，準沒錯！
總結
- 上一篇： ios 关于MBProgressHUD简
- 下一篇： 不可能得到的最短骰子序列