---

Kilo 使用教程

本文將詳細(xì)介紹如何在云原生環(huán)境中使用Kilo進(jìn)行WireGuard的應(yīng)用，尤其是針對Kubernetes集群的組網(wǎng)。 對于WireGuard新手，建議按照特定順序閱讀相關(guān)教程，以便更好地理解。 云原生領(lǐng)域中，Kilo主要用于CNI，可以與Flannel、Wormhole結(jié)合提供加密，或者單獨(dú)作為組網(wǎng)工具。 對于組網(wǎng)需求，推薦使用Kilo，尤其是當(dāng)需要在AWS、Azure、GCP和阿里云的云主機(jī)之間構(gòu)建一個(gè)無縫的k3s集群，且允許跨設(shè)備訪問Pod和Service IP時(shí)。 實(shí)現(xiàn)這一目標(biāo)分為兩步：首先，通過Kilo調(diào)整k3s集群節(jié)點(diǎn)間的容器網(wǎng)絡(luò)，取消默認(rèn)CNI；重啟服務(wù)器后，可以選擇Kilo作為CNI。 Kilo支持三種網(wǎng)絡(luò)拓?fù)洌哼壿嫹纸M互聯(lián)、全互聯(lián)和混合模式，具體操作需要根據(jù)節(jié)點(diǎn)的特定情況進(jìn)行調(diào)整。 以全互聯(lián)模式為例，部署Kilo需要拷貝kubeconfig、修改API地址、添加節(jié)點(diǎn)注解并克隆Kilo官方倉庫進(jìn)行配置。 部署成功后，節(jié)點(diǎn)將新增網(wǎng)絡(luò)接口，用于實(shí)現(xiàn)跨云容器通信。 接下來，需要創(chuàng)建新的網(wǎng)絡(luò)接口wg0，以本地網(wǎng)絡(luò)訪問云上的Pod和Service IP。 通過wg-gen-web管理WireGuard配置，并根據(jù)每個(gè)節(jié)點(diǎn)的需要調(diào)整，以實(shí)現(xiàn)跨設(shè)備訪問。 最后，通過本地運(yùn)行WireGuard，你將能夠輕松地在云主機(jī)的Kubernetes集群中自由穿梭。 本文已涵蓋Kilo的部署和基本網(wǎng)絡(luò)配置，對于進(jìn)一步優(yōu)化如通過CoreDNS訪問服務(wù)名稱，讀者可自行探索。 最后，歡迎訪問獲取Kubernetes離線安裝包和sealos的最新特性，以及加入釘釘群獲取更多實(shí)時(shí)信息。

云原生是什么？（入門科普）

云原生，這一概念近年來在科技圈內(nèi)頗為流行，但它對于非專業(yè)人士來說，往往顯得有些晦澀難懂。 本文旨在以較為通俗的語言，提供一個(gè)云原生的入門級科普，幫助你理解這一術(shù)語的基本含義及其核心理念。 云原生，直譯自“Cloud Native”，指的是設(shè)計(jì)與構(gòu)建旨在云環(huán)境中運(yùn)行的應(yīng)用與服務(wù)，這一概念的核心在于利用云計(jì)算資源的彈性和靈活性，以實(shí)現(xiàn)應(yīng)用的高效部署、管理和擴(kuò)展。 云計(jì)算，作為云原生的基礎(chǔ)，提供了一種基于互聯(lián)網(wǎng)的計(jì)算資源服務(wù)模式。 通過云計(jì)算，用戶可以租用各種基礎(chǔ)設(shè)施，如服務(wù)器、存儲和網(wǎng)絡(luò)資源等，實(shí)現(xiàn)高效資源利用和成本節(jié)約。 云計(jì)算服務(wù)商，如AWS、Azure、阿里云、谷歌云、IBM云、騰訊云、華為云等，通過統(tǒng)一管理大量基礎(chǔ)設(shè)施，實(shí)現(xiàn)資源的動態(tài)分配，支持按需使用，備份與恢復(fù)簡便，以及快速部署與集成。 云原生技術(shù)集合了容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API等關(guān)鍵概念，旨在構(gòu)建容錯性好、易于管理且便于觀察的松耦合系統(tǒng)，通過可靠的自動化手段，實(shí)現(xiàn)應(yīng)用的頻繁和可預(yù)測的重大變更。 微服務(wù)是云原生架構(gòu)中的核心概念，它將應(yīng)用拆分為一系列松散耦合的組件，每個(gè)組件負(fù)責(zé)特定功能，通過容器技術(shù)實(shí)現(xiàn)獨(dú)立部署和擴(kuò)展，從而提高了系統(tǒng)的靈活性和可維護(hù)性。 容器技術(shù)，如Docker，為微服務(wù)提供了統(tǒng)一的運(yùn)行環(huán)境，使得應(yīng)用能夠在不同環(huán)境中輕松部署。 Kubernetes（K8s）作為容器編排平臺的代表，簡化了容器化的微服務(wù)管理，支持大規(guī)模部署和自動伸縮。 服務(wù)網(wǎng)格，通過解決微服務(wù)間的網(wǎng)絡(luò)相關(guān)問題，如通信、安全和監(jiān)控，進(jìn)一步優(yōu)化了微服務(wù)架構(gòu)的協(xié)作效率。 不可變基礎(chǔ)設(shè)施強(qiáng)調(diào)應(yīng)用運(yùn)行環(huán)境的穩(wěn)定性和一致性，避免了手動配置和維護(hù)的復(fù)雜性，促進(jìn)了一鍵部署的實(shí)現(xiàn)。 聲明式API的使用，簡化了代碼編寫和管理，使得應(yīng)用狀態(tài)的調(diào)整更加直觀和高效。 自動化交付方法，如持續(xù)集成/持續(xù)部署（CI/CD）或DevOps，與云原生技術(shù)緊密結(jié)合，提高了應(yīng)用開發(fā)和部署的效率。 云原生技術(shù)并非適用于所有場景，它在需要快速迭代、靈活擴(kuò)展的應(yīng)用場景中表現(xiàn)出色，但在對數(shù)據(jù)安全、隱私和可持續(xù)服務(wù)有嚴(yán)格要求的場景中，需要進(jìn)行謹(jǐn)慎評估。 通過本文的介紹，希望你能夠?qū)υ圃母拍钣辛艘欢ǖ睦斫猓⒄J(rèn)識到其在現(xiàn)代應(yīng)用開發(fā)和部署中的重要性和潛力。 如果你對云原生技術(shù)有更多疑問或感興趣的話題，歡迎進(jìn)一步探討。

Nocalhost - 讓云原生時(shí)代的開發(fā)更高效

在轉(zhuǎn)向 Kubernetes 部署后，我們團(tuán)隊(duì)在開發(fā)過程中遇到了挑戰(zhàn)，尋求在云原生環(huán)境中無縫聯(lián)調(diào)本地和開發(fā)環(huán)境的解決方案。 以往的開發(fā)流程有兩套模式，這導(dǎo)致了本地編碼效率低下：2分鐘編碼后，需要5分鐘在環(huán)境中驗(yàn)證，嚴(yán)重影響了工作效率。 為了解決這一問題，我們尋求一種簡單易學(xué)、基于配置、團(tuán)隊(duì)統(tǒng)一的解決方案。 經(jīng)過研究，Telepresence和Bridge to Kubernetes這兩款工具進(jìn)入了我們的視野。 Telepresence通過在Pod中部署網(wǎng)絡(luò)代理，讓本地進(jìn)程與Kubernetes環(huán)境無縫對接，而Bridge to Kubernetes則專注于在開發(fā)計(jì)算機(jī)和集群間雙向通信，但其IDE插件支持有限。 最終，我們選擇Nocalhost，一款基于IDE的云原生開發(fā)工具。 Nocalhost不僅具備Telepresence和Bridge to Kubernetes的功能，還提供了更全面的開發(fā)環(huán)境管理，如與VSCode、IntelliJ IDEA深度集成，一鍵部署和遠(yuǎn)程調(diào)試。 它通過單個(gè)CLI和IDE插件，利用KubeConfig與集群通信，實(shí)時(shí)同步代碼并在編碼時(shí)自動同步到K8s容器，顯著提升開發(fā)效率。 與其他工具相比，Nocalhost在特性、支持IDE插件和用戶體驗(yàn)上表現(xiàn)出色，特別是在大型團(tuán)隊(duì)和復(fù)雜環(huán)境中構(gòu)建云原生應(yīng)用方面。 它在Kubernetes集群中開發(fā)的應(yīng)用場景廣泛，且無需團(tuán)隊(duì)成員成為Kubernetes專家，簡化了協(xié)作流程。 安裝Nocalhost的過程簡單，無論使用JetBrains系列還是VSCode，都能便捷集成。 只需要在項(xiàng)目根目錄創(chuàng)建文件夾并配置，定義本地與遠(yuǎn)程環(huán)境的同步規(guī)則。 對于Python和Golang項(xiàng)目，Nocalhost提供了熱加載功能，實(shí)時(shí)更新代碼并自動重新執(zhí)行命令。 總之，Nocalhost以其全面的功能、易用性和高度集成的優(yōu)勢，成為我們團(tuán)隊(duì)在云原生時(shí)代提升開發(fā)效率的理想選擇。 通過Nocalhost，開發(fā)和聯(lián)調(diào)變得更加高效，極大降低了本地環(huán)境搭建和配置的時(shí)間，優(yōu)化了團(tuán)隊(duì)協(xié)作流程。

云原生體系下Serverless彈性探索與實(shí)踐

簡介：SAE通過對彈性組件和應(yīng)用全生命周期的不斷優(yōu)化以達(dá)到秒級彈性，并在彈性能力，場景豐富度，穩(wěn)定性上具備核心競爭力，是傳統(tǒng)應(yīng)用0改造上Serverless的最佳選擇。

Serverless時(shí)代的來臨

Serverless顧名思義，是一種“無服務(wù)器”架構(gòu)，因?yàn)槠帘瘟朔?wù)器的各種運(yùn)維復(fù)雜度，讓開發(fā)人員可以將更多精力用于業(yè)務(wù)邏輯設(shè)計(jì)與實(shí)現(xiàn)。 在Serverless架構(gòu)下，開發(fā)者只需要關(guān)注于上層應(yīng)用邏輯的開發(fā)，而諸如資源申請，環(huán)境搭建，負(fù)載均衡，擴(kuò)縮容等等服務(wù)器相關(guān)的復(fù)雜操作都由平臺來進(jìn)行維護(hù)。 在云原生架構(gòu)白皮書中，對Serverless的特性有以下概括：

全托管的計(jì)算服務(wù)，客戶只需要編寫代碼構(gòu)建應(yīng)用，無需關(guān)注同質(zhì)化的、負(fù)擔(dān)繁重的基于服務(wù)器等基礎(chǔ)設(shè)施的開發(fā)、運(yùn)維、安全、高可用等工作；

通用性，能夠支撐云上所有重要類型的應(yīng)用；

自動的彈性伸縮，讓用戶無需為資源使用提前進(jìn)行容量規(guī)劃；

按量計(jì)費(fèi)，讓企業(yè)使用成本得有效降低，無需為閑置資源付費(fèi)。

回顧整個(gè)Serverless的發(fā)展歷程，我們可以看到從2012年首次提出Serverless概念為起點(diǎn)，再到AWS推出Lambda云產(chǎn)品的這段時(shí)間內(nèi)，人們對Serverless的關(guān)注度出現(xiàn)了爆發(fā)式的增長，對無服務(wù)器的期待和暢想逐漸引爆整個(gè)行業(yè)，但Serverless的推廣和生產(chǎn)落地的過程卻不容樂觀，Serverless理念與實(shí)操生產(chǎn)的過程中存在Gap，挑戰(zhàn)著人們固有的使用體驗(yàn)和習(xí)慣。

阿里云堅(jiān)信Serverless將作為云原生之后確定性的發(fā)展方向，相繼推出了FC,SAE等多款云產(chǎn)品來覆蓋不同領(lǐng)域，不同類型的應(yīng)用負(fù)載來使用Serverless技術(shù)，并且不斷在推進(jìn)整個(gè)Serverless理念的普及與發(fā)展。

就當(dāng)前Serverless整個(gè)市場格局而言，阿里云已經(jīng)做到了Serverless產(chǎn)品能力中國第一，全球領(lǐng)先，在去年Forrester評測魔力象限中可以明顯的看到阿里云在Serverless領(lǐng)域已經(jīng)與AWS不相上下，于此同時(shí)，阿里云Serverless用戶占比中國第一，在2020年中國云原生用戶調(diào)研報(bào)告中整個(gè)阿里云Serverless用戶占比已經(jīng)達(dá)到了66%，而在Serverless技術(shù)采用情況的調(diào)研中表明，已經(jīng)有越來越多的開發(fā)者和企業(yè)用戶將Serverless技術(shù)應(yīng)用于核心業(yè)務(wù)或者將要應(yīng)用于核心業(yè)務(wù)之中。

Serverless彈性探索

彈性能力作為云的核心能力之一，所關(guān)注的問題是容量規(guī)劃與實(shí)際集群負(fù)載間的矛盾，通過兩幅圖的對比可以看到，如果采用預(yù)先規(guī)劃的方式進(jìn)行資源安排，會由于資源準(zhǔn)備量和資源需求量的不匹配導(dǎo)致資源浪費(fèi)或者資源不足的情況，進(jìn)而導(dǎo)致成本上的過多開銷甚至業(yè)務(wù)受損，而我們期望極致彈性能力，是準(zhǔn)備的資源和實(shí)際需求的資源幾乎匹配，這樣使得應(yīng)用整體的資源利用率較高，成本也隨業(yè)務(wù)的增減和相應(yīng)的增減，同時(shí)不會出現(xiàn)因容量問題影響應(yīng)用可用性的情況，這就是彈性的價(jià)值。

彈性其實(shí)現(xiàn)上分為可伸縮性和故障容忍性,可伸縮性意味著底層資源可以參照指標(biāo)的變化有一定的自適應(yīng)能力，而故障容忍性則是通過彈性自愈確保服務(wù)中的應(yīng)用或?qū)嵗幱诮】档臓顟B(tài)。 上述能力帶來的價(jià)值收益在于降成本的同時(shí)提升應(yīng)用可用性，一方面，資源使用量貼合應(yīng)用實(shí)際消耗量，另一方面，提升峰值的應(yīng)用可用性，進(jìn)而靈活適應(yīng)市場的不斷發(fā)展與變化。

下面將對當(dāng)前較為普遍的三種彈性伸縮模式進(jìn)行闡述和分析。

首先是IaaS彈性伸縮，其代表產(chǎn)品是各云廠商云服務(wù)器彈性伸縮，如阿里云ess,可以通過配置云監(jiān)控的告警規(guī)則來觸發(fā)相應(yīng)的ECS增減操作，同時(shí)支持動態(tài)增減Slb后端服務(wù)器和Rds白名單來保證可用性，通過健康檢查功能實(shí)現(xiàn)彈性自愈能力。 ESS定義了伸縮組的概念，即彈性伸縮的基本單位，為相同應(yīng)用場景的ECS實(shí)例的集合及關(guān)聯(lián)Slb,Rds,同時(shí)支持多種伸縮規(guī)則，如簡單規(guī)則，進(jìn)步規(guī)則，目標(biāo)追蹤規(guī)則，預(yù)測規(guī)則等，用戶的使用流程為創(chuàng)建伸縮組和伸縮配置，創(chuàng)建伸縮規(guī)則，監(jiān)控查看彈性執(zhí)行情況。

Kubernetes彈性伸縮，這里主要關(guān)注于水平彈性hpa，其代表產(chǎn)品為K8s以及其所對應(yīng)的托管云產(chǎn)品，如阿里云容器服務(wù)，K8s做為面向應(yīng)用運(yùn)維的基礎(chǔ)設(shè)施和PlatformforPlatform,提供的內(nèi)置能力主要是圍繞著容器級別的管理和編排來展開的,而彈性能力聚焦于對底層Pod的動態(tài)水平伸縮，K8shpa通過輪詢Pod的監(jiān)控?cái)?shù)據(jù)并將它與目標(biāo)期望值比較進(jìn)行，通過算法實(shí)時(shí)計(jì)算來產(chǎn)生期望的副本數(shù)，進(jìn)而對Workload的副本數(shù)進(jìn)行增減操作，用戶在實(shí)際使用上需要創(chuàng)建并配置對應(yīng)的指標(biāo)源和彈性規(guī)則以及對應(yīng)的Workload，可以通過事件來查看彈性的執(zhí)行情況。

最后介紹一下應(yīng)用畫像彈性伸縮，其主要用于互聯(lián)網(wǎng)公司內(nèi)部，如阿里ASI容量平臺。 容量平臺提供容量預(yù)測服務(wù)和容量變更決策服務(wù)，指導(dǎo)底層容量變更組件如AHPA/VPA實(shí)現(xiàn)容量彈性伸縮，并根據(jù)彈性結(jié)果修正容量畫像。 以畫像驅(qū)動為主+指標(biāo)驅(qū)動為輔實(shí)現(xiàn)彈性伸縮能力，通過提前伸縮+實(shí)時(shí)修正來降低彈性伸縮風(fēng)險(xiǎn)。 整個(gè)彈性伸縮會借助odps和機(jī)器學(xué)習(xí)能力對實(shí)例監(jiān)控等數(shù)據(jù)進(jìn)行處理并產(chǎn)生應(yīng)用畫像，如基準(zhǔn)畫像，彈性畫像，大促畫像等，并借助容量平臺來完成畫像注入，變更管控和故障熔斷等操作。 用戶使用流程為應(yīng)用接入，基于歷史數(shù)據(jù)/經(jīng)驗(yàn)生成對應(yīng)的容量畫像，實(shí)時(shí)監(jiān)控指標(biāo)修正畫像，并監(jiān)控查看彈性執(zhí)行情況。

從對比可以看出各產(chǎn)品彈性伸縮功能模式上從抽象來講基本相同，均由觸發(fā)源，彈性決策和觸發(fā)動作組成，觸發(fā)源一般依賴外部監(jiān)控系統(tǒng)，對節(jié)點(diǎn)指標(biāo)，應(yīng)用指標(biāo)進(jìn)行采集處理，彈性決策一般基于周期性輪詢并算法決策，有部分基于歷史數(shù)據(jù)分析預(yù)測以及用戶定義的定時(shí)策略，而觸發(fā)動作為對實(shí)例進(jìn)行水平擴(kuò)縮，并提供變更記錄與對外通知。 各個(gè)產(chǎn)品在此基礎(chǔ)上做場景豐富度，效率，穩(wěn)定性的競爭力，并通過可觀測能力提升彈性系統(tǒng)的透明度，便于問題排查和指導(dǎo)彈性優(yōu)化，同時(shí)提升用戶使用體驗(yàn)與粘性。

各產(chǎn)品彈性伸縮模型也存在這一定的差異，對于IaaS彈性伸縮，其作為老牌彈性伸縮能力，沉淀時(shí)間長，功能強(qiáng)大且豐富，云廠商間能力趨于同質(zhì)化。 彈性效率相較容器受限，且強(qiáng)綁定各自底層Iaas資源。 Kubernetes作為開源產(chǎn)品，通過社區(qū)力量不斷優(yōu)化迭代彈性能力和最佳實(shí)踐，更符合絕大部分開發(fā)運(yùn)維人員訴求。 對彈性行為和api進(jìn)行高度抽象，但其可擴(kuò)展性不強(qiáng)，無法支持自定義需求。 而應(yīng)用畫像彈性伸縮具有集團(tuán)內(nèi)部特色，根據(jù)集團(tuán)應(yīng)用現(xiàn)狀和彈性訴求進(jìn)行設(shè)計(jì)，且更聚焦于資源池預(yù)算成本優(yōu)化，縮容風(fēng)險(xiǎn)，復(fù)雜度等痛點(diǎn)。 不易拷貝擴(kuò)展，特別對于外部中小客戶不適用。

從終態(tài)目標(biāo)上，可以看出公有云與互聯(lián)網(wǎng)企業(yè)方向的不同：

互聯(lián)網(wǎng)企業(yè)往往由于其內(nèi)部應(yīng)用具有顯著流量特征，應(yīng)用啟動依賴多，速度慢，且對整體資源池容量水位，庫存財(cái)務(wù)管理，離在線混部有組織上的諸多訴求，因而更多的是以容量畫像提前彈性擴(kuò)容為主，基于Metrics計(jì)算的容量數(shù)據(jù)作為實(shí)時(shí)修正，其目標(biāo)是容量畫像足夠精準(zhǔn)以至于資源利用率達(dá)到預(yù)期目標(biāo)。

公有云廠商服務(wù)于外部客戶，提供更為通用，普適的能力，并通過可拓展性滿足不同用戶的差異化需求。 尤其在Serverless場景，更強(qiáng)調(diào)應(yīng)用應(yīng)對突發(fā)流量的能力，其目標(biāo)在于無需容量規(guī)劃，通過指標(biāo)監(jiān)控配合極致彈性能力實(shí)現(xiàn)應(yīng)用資源的近乎按需使用且整個(gè)過程服務(wù)可用。

Serverless彈性落地

Serverless作為云計(jì)算的最佳實(shí)踐、云原生發(fā)展的方向和未來演進(jìn)趨勢，其核心價(jià)值在于快速交付、智能彈性、更低成本。

在時(shí)代背景下，SAE應(yīng)運(yùn)而生，SAE是一款面向應(yīng)用的ServerlessPaaS平臺，支持SpringCloud、Dubbo等主流開發(fā)框架，用戶可以零代碼改造直接將應(yīng)用部署到SAE，并且按需使用，按量計(jì)費(fèi)，可以充分發(fā)揮Serverless的優(yōu)勢為客戶節(jié)省閑置資源成本，同時(shí)體驗(yàn)上采用全托管，免運(yùn)維的方式，用戶只需聚焦于核心業(yè)務(wù)開發(fā)，而應(yīng)用生命周期管理，微服務(wù)管理，日志，監(jiān)控等功能交由SAE完成。

彈性的競爭力主要在于場景豐富度，效率，穩(wěn)定性的競爭力，先講一下SAE在彈性效率上的優(yōu)化。

通過對SAE應(yīng)用的整個(gè)生命周期進(jìn)行數(shù)據(jù)統(tǒng)計(jì)和可視化分析，其包含調(diào)度，initcontainer創(chuàng)建，拉取用戶鏡像，創(chuàng)建用戶容器，啟動用戶容器&應(yīng)用這幾個(gè)階段，示意圖中對其耗時(shí)的占比進(jìn)行了簡化。 我們可以看到整個(gè)應(yīng)用生命周期耗時(shí)集中于調(diào)度，拉取用戶鏡像，應(yīng)用冷啟動這幾個(gè)階段。 針對于調(diào)度階段，其耗時(shí)主要在于SAE當(dāng)前會執(zhí)行打通用戶VPC操作，由于該步驟強(qiáng)耦合于調(diào)度，本身耗時(shí)較長，且存在創(chuàng)建長尾超時(shí)，失敗重試等情況，導(dǎo)致調(diào)度鏈路整體耗時(shí)較長。

由此產(chǎn)生的疑問是可否優(yōu)化調(diào)度速度？可否跳過調(diào)度階段?而對于拉取用戶鏡像，其包含拉取鏡像與解壓鏡像的時(shí)長，特別是在大容量鏡像部署的情況下尤為突出。 優(yōu)化的思路在于拉取鏡像是否可以優(yōu)化使用緩存，解壓鏡像是否可以優(yōu)化。 而對于應(yīng)用冷啟動，SAE存在大量單體和微服務(wù)的JAVA應(yīng)用，JAVA類型應(yīng)用往往啟動依賴多，加載配置慢，初始化過程長，導(dǎo)致冷啟動速往往達(dá)到分鐘級。 優(yōu)化的方向在于可否避免冷啟動流程并使用戶盡量無感，應(yīng)用無改造。

首先SAE采用了原地升級能力，SAE起初使用了K8s原生的Deployment滾動升級策略進(jìn)行發(fā)布流程，會先創(chuàng)建新版本Pod，再銷毀舊版本Pod進(jìn)行升級，而所謂原地升級，即只更新Pod中某一個(gè)或多個(gè)容器版本、而不影響整個(gè)Pod對象、其余容器的升級。 其原理是通過K8spatch能力，實(shí)現(xiàn)原地升級Container，通過K8sreadinessGates能力，實(shí)現(xiàn)升級過程中流量無損。

原地升級給SAE帶來了諸多價(jià)值，其中最重要的是避免重調(diào)度，避免Sidecar容器（ARMS,SLS,AHAS）重建,使得整個(gè)部署耗時(shí)從消耗整個(gè)Pod生命周期到只需要拉取和創(chuàng)建業(yè)務(wù)容器，于此同時(shí)因?yàn)闊o需調(diào)度，可以預(yù)先在Node上緩存新鏡像，提高彈性效率。 SAE采用阿里開源Openkruise項(xiàng)目提供的Cloneset作為新的應(yīng)用負(fù)載，借助其提供的原地升級能力，使得整個(gè)彈性效率提升42%。

同時(shí)SAE采用了鏡像預(yù)熱能力，其包含兩種預(yù)熱形式：調(diào)度前預(yù)熱，SAE會對通用的基礎(chǔ)鏡像進(jìn)行全節(jié)點(diǎn)緩存，以避免其頻繁的從遠(yuǎn)端進(jìn)行拉取。 與此同時(shí)對于分批的場景支持調(diào)度中預(yù)熱，借助Cloneset原地升級能力，在升級的過程中可以感知到實(shí)例的節(jié)點(diǎn)分布情況，這樣就可以在第一批部署新版本鏡像的同時(shí)，對后面批次的實(shí)例所在節(jié)點(diǎn)進(jìn)行鏡像預(yù)拉取，進(jìn)而實(shí)現(xiàn)調(diào)度與拉取用戶鏡像并行。 通過這項(xiàng)技術(shù)，SAE彈性效率提升了30%。

剛才講述的優(yōu)化點(diǎn)在于拉取鏡像部分，而對于解壓鏡像，傳統(tǒng)容器運(yùn)行需要將全量鏡像數(shù)據(jù)下載后再解包，然而容器啟動可能僅使用其中部分的內(nèi)容，導(dǎo)致容器啟動耗時(shí)長。 SAE通過鏡像加速技術(shù)，將原有標(biāo)準(zhǔn)鏡像格式自動轉(zhuǎn)化為支持隨機(jī)讀取的加速鏡像，可以實(shí)現(xiàn)鏡像數(shù)據(jù)免全量下載和在線解壓，大幅提升應(yīng)用分發(fā)效率，同時(shí)利用Acree提供的P2P分發(fā)能力也可以有效減少鏡像分發(fā)的時(shí)間。

對于Java應(yīng)用冷啟動較慢的痛點(diǎn)，SAE聯(lián)合Dragonwell11提供了增強(qiáng)的AppCDS啟動加速策略，AppCDS即ApplicationClassDataSharing，通過這項(xiàng)技術(shù)可以獲取應(yīng)用啟動時(shí)的Classlist并Dump其中的共享的類文件，當(dāng)應(yīng)用再次啟動時(shí)可以使用共享文件來啟動應(yīng)用，進(jìn)而有效減少冷啟動耗時(shí)。 映射到SAE的部署場景，應(yīng)用啟動后會生成對應(yīng)的緩存文件在共享的nas中，而在進(jìn)行下一次發(fā)布的過程中就可以使用緩存文件進(jìn)行啟動。 整體冷啟動效率提升45%。

除了對整個(gè)應(yīng)用生命周期的效率進(jìn)行優(yōu)化外，SAE也對彈性伸縮進(jìn)行了優(yōu)化，整個(gè)彈性伸縮流程包括彈性指標(biāo)獲取，指標(biāo)決策以及執(zhí)行彈性擴(kuò)縮操作三部分。 對于彈性指標(biāo)獲取，基礎(chǔ)監(jiān)控指標(biāo)數(shù)據(jù)已經(jīng)達(dá)到了秒級獲取，而對于七層的應(yīng)用監(jiān)控指標(biāo)，SAE正在規(guī)劃采用流量透明攔截的方案保證指標(biāo)獲取的實(shí)時(shí)性。 而彈性決策階段，彈性組件啟用了多隊(duì)列并發(fā)進(jìn)行Reconcile，并實(shí)時(shí)監(jiān)控隊(duì)列堆積，延時(shí)情況。

SAE彈性伸縮包括強(qiáng)大的指標(biāo)矩陣，豐富的策略配置，完善的通知告警機(jī)制及全方位可觀測能力,支持多種數(shù)據(jù)源：原生的MetricsServer，MetricsAdapter，Prometheus，云產(chǎn)品SLS,CMS,SLB以及外部的網(wǎng)關(guān)路由等，支持多種指標(biāo)類型：CPU、MEM、QPS、RT、TCP連接數(shù)，出入字節(jié)數(shù)，磁盤使用率，Java線程數(shù)，GC數(shù)還有自定義指標(biāo)。 對指標(biāo)的抓取和預(yù)處理后，可以自定義配置彈性策略來適配應(yīng)用的具體場景：快擴(kuò)快縮，快擴(kuò)慢縮，只擴(kuò)不縮，只縮不擴(kuò)，DRYRUN，自適應(yīng)擴(kuò)縮等。

同時(shí)可以進(jìn)行更為精細(xì)化的彈性參數(shù)配置,如實(shí)例上下限，指標(biāo)區(qū)間，步長比例范圍，冷卻、預(yù)熱時(shí)間，指標(biāo)采集周期和聚和邏輯，CORN表達(dá)式，后續(xù)也會支持事件驅(qū)動的能力。 彈性觸發(fā)后會進(jìn)行對應(yīng)的擴(kuò)縮容操作，并通過切流保證流量無損，并且可以借助完善的通知告警能力（釘釘，webhook,電話，郵件，短信）來實(shí)時(shí)觸達(dá)告知用戶。 彈性伸縮提供了全方位的可觀測能力，對彈性的決策時(shí)間，決策上下文進(jìn)行清晰化展現(xiàn)，并且做到實(shí)例狀態(tài)可回溯，實(shí)例SLA可監(jiān)控。

SAE彈性能力在場景豐富度上也有著相應(yīng)的競爭力，這里重點(diǎn)介紹一下SAE當(dāng)前支持的四種場景：

定時(shí)彈性：在已知應(yīng)用流量負(fù)載周期的情況下進(jìn)行配置，應(yīng)用實(shí)例數(shù)可以按照時(shí)間，星期，日期周期進(jìn)行規(guī)律化擴(kuò)縮，如在早8點(diǎn)到晚8點(diǎn)的時(shí)間段保持10個(gè)實(shí)例數(shù)應(yīng)對白天流量，而在其余時(shí)間由于流量較低則維持在2個(gè)實(shí)例數(shù)甚至縮0。 適用于資源使用率有周期性規(guī)律的應(yīng)用場景，多用于證券、醫(yī)療、政府和教育等行業(yè)。

指標(biāo)彈性：可以配置期望的監(jiān)控指標(biāo)規(guī)則，SAE會時(shí)應(yīng)用的指標(biāo)穩(wěn)定在所配置的指標(biāo)規(guī)則內(nèi)，并且默認(rèn)采用快擴(kuò)慢縮的模式來保證穩(wěn)定性。 如將應(yīng)用的cpu指標(biāo)目標(biāo)值設(shè)置為60%，QPS設(shè)置為1000，實(shí)例數(shù)范圍為2-50。 這種適用于突發(fā)流量和典型周期性流量的應(yīng)用場景，多用于互聯(lián)網(wǎng)、游戲和社交平臺等行業(yè)。

混合彈性：將定時(shí)彈性與指標(biāo)彈性相結(jié)合，可以配置不同時(shí)間，星期，日期下的指標(biāo)規(guī)則，進(jìn)而更加靈活的應(yīng)對復(fù)雜場景的需求。 如早8點(diǎn)到晚8點(diǎn)的時(shí)間段CPU指標(biāo)目標(biāo)值設(shè)置為60%，實(shí)例數(shù)范圍為10-50，而其余時(shí)間則將實(shí)例數(shù)范圍降為2-5，適用于兼?zhèn)滟Y源使用率有周期性規(guī)律和有突發(fā)流量、典型周期性流量的應(yīng)用場景，多用于互聯(lián)網(wǎng)、教育和餐飲等行業(yè)。

自適應(yīng)彈性：SAE針對流量突增場景進(jìn)行了優(yōu)化，借助流量激增窗口，計(jì)算當(dāng)前指標(biāo)在這個(gè)時(shí)刻上是否出現(xiàn)了流量激增問題，并會根據(jù)流量激增的強(qiáng)烈程度在計(jì)算擴(kuò)容所需的實(shí)例時(shí)會增加一部分的冗余，并且在激增模式下，不允許縮容。

穩(wěn)定性是SAE彈性能力建設(shè)的過程中非常重要的一環(huán)，保證用戶應(yīng)用在彈性過程中按照預(yù)期行為進(jìn)行擴(kuò)縮，并保證整個(gè)過程的可用性是關(guān)注的重點(diǎn)。 SAE彈性伸縮整體遵循快擴(kuò)慢縮的原則，通過多級平滑防抖保證執(zhí)行穩(wěn)定性，同時(shí)對于指標(biāo)激增場景，借助自適應(yīng)能力提前擴(kuò)容。 SAE當(dāng)前支持四級彈性平滑配置保證穩(wěn)定性：

一級平滑：對指標(biāo)獲取周期，單次指標(biāo)獲取的時(shí)間窗口，指標(biāo)計(jì)算聚和邏輯進(jìn)行配置

二級平滑：對指標(biāo)數(shù)值容忍度，區(qū)間彈性進(jìn)行配置

三級平滑：對單位時(shí)間擴(kuò)縮步長，百分比，上下限進(jìn)行配置

四級平滑：對擴(kuò)縮冷卻窗口，實(shí)例預(yù)熱時(shí)間進(jìn)行配置

Serverless彈性最佳實(shí)踐

SAE彈性伸縮可以有效解決瞬時(shí)流量波峰到來時(shí)應(yīng)用自動擴(kuò)容，波峰結(jié)束后自動縮容。 高可靠性、免運(yùn)維、低成本的保障應(yīng)用平穩(wěn)運(yùn)行，在使用的過程中建議遵循以下最佳實(shí)踐進(jìn)行彈性配置。

配置健康檢查和生命周期管理

建議對應(yīng)用健康檢查進(jìn)行配置，以保證彈性擴(kuò)縮過程中的應(yīng)用整體可用性，確保您的應(yīng)用僅在啟動、運(yùn)行并且準(zhǔn)備好接受流量時(shí)才接收流量同時(shí)建議配置生命周期管理Prestop，以確保縮容時(shí)按照預(yù)期優(yōu)雅下線您的應(yīng)用。

采用指數(shù)重試機(jī)制

為避免因彈性不及時(shí)，應(yīng)用啟動不及時(shí)或者應(yīng)用沒有優(yōu)雅上下線導(dǎo)致的服務(wù)調(diào)用異常，建議調(diào)用方采用指數(shù)重試機(jī)制進(jìn)行服務(wù)調(diào)用。

應(yīng)用啟動速度優(yōu)化

為提升彈性效率，建議您優(yōu)化應(yīng)用的創(chuàng)建速度，可以從以下方面考慮優(yōu)化：

軟件包優(yōu)化：優(yōu)化應(yīng)用啟動時(shí)間，減少因類加載、緩存等外部依賴導(dǎo)致的應(yīng)用啟動過長

鏡像優(yōu)化：精簡鏡像大小，減少創(chuàng)建實(shí)例時(shí)鏡像拉取耗時(shí)，可借助開源工具Dive，分析鏡像層信息，有針對性的精簡變更

Java應(yīng)用啟動優(yōu)化：借助SAE聯(lián)合Dragonwell11，為Java11用戶提供了應(yīng)用啟動加速功能

彈性伸縮指標(biāo)配置

彈性伸縮指標(biāo)配置，SAE支持基礎(chǔ)監(jiān)控，應(yīng)用監(jiān)控多指標(biāo)組合配置，您可以根據(jù)當(dāng)前應(yīng)用的屬性（CPU敏感/內(nèi)存敏感/io敏感）進(jìn)行靈活選擇。

可以通過對基礎(chǔ)監(jiān)控和應(yīng)用監(jiān)控對應(yīng)指標(biāo)歷史數(shù)據(jù)（如過去6h,12h,1天,7天峰值，P99,P95數(shù)值）進(jìn)行查看并預(yù)估指標(biāo)目標(biāo)值，可借助PTS等壓測工具進(jìn)行壓測，了解應(yīng)用可以應(yīng)對的并發(fā)請求數(shù)量、需要的CPU和內(nèi)存數(shù)量，以及高負(fù)載狀態(tài)下的應(yīng)用響應(yīng)方式，以評估應(yīng)用容量峰值大小。

指標(biāo)目標(biāo)值需要權(quán)衡可用性與成本進(jìn)行策略選擇，如

可用性優(yōu)化策略配置指標(biāo)值為40%

可用性成本平衡策略配置指標(biāo)值為50%

成本優(yōu)化策略配置指標(biāo)值為70%

同時(shí)彈性配置應(yīng)考慮梳理上下游，中間件，db等相關(guān)依賴，配置對應(yīng)的彈性規(guī)則或者限流降級手段，確保擴(kuò)容時(shí)全鏈路可以保證可用性。

在配置彈性規(guī)則后，通過不斷監(jiān)視和調(diào)整彈性規(guī)則以使容量更加接近應(yīng)用實(shí)際負(fù)載。

內(nèi)存指標(biāo)配置

關(guān)于內(nèi)存指標(biāo)，考慮部分應(yīng)用類型采用動態(tài)內(nèi)存管理進(jìn)行內(nèi)存分配（如Javajvm內(nèi)存管理，GlibcMalloc和Free操作），應(yīng)用閑置內(nèi)存并沒有及時(shí)釋放給操作系統(tǒng)，實(shí)例消耗的物理內(nèi)存并不會及時(shí)減少且新增實(shí)例并不能減少平均內(nèi)存消耗，進(jìn)而無法觸發(fā)縮容，針對于該類應(yīng)用不建議采用內(nèi)存指標(biāo)。

Java應(yīng)用運(yùn)行時(shí)優(yōu)化：釋放物理內(nèi)存，增強(qiáng)內(nèi)存指標(biāo)與業(yè)務(wù)關(guān)聯(lián)性

借助Dragonwell運(yùn)行時(shí)環(huán)境，通過增加JVM參數(shù)開啟ElasticHeap能力，支持Java堆內(nèi)存的動態(tài)彈性伸縮，節(jié)約Java進(jìn)程實(shí)際使用的物理內(nèi)存占用。

最小實(shí)例數(shù)配置

配置彈性伸縮最小實(shí)例數(shù)建議大于等于2，且配置多可用區(qū)VSwitch，防止因底層節(jié)點(diǎn)異常導(dǎo)致實(shí)例驅(qū)逐或可用區(qū)無可用實(shí)例時(shí)應(yīng)用停止工作，保證應(yīng)用整體高可用。

最大實(shí)例數(shù)配置

配置彈性伸縮最大實(shí)例數(shù)時(shí)，應(yīng)考慮可用區(qū)IP數(shù)是否充足，防止無法新增實(shí)例。 可以在控制臺VSwitch處查看當(dāng)前應(yīng)用可用IP，若可用IP較少考慮替換或新增VSwitch。

彈性到達(dá)最大值

可以通過應(yīng)用概覽查看當(dāng)前開啟彈性伸縮配置的應(yīng)用，并及時(shí)發(fā)現(xiàn)當(dāng)前實(shí)例數(shù)已經(jīng)到達(dá)峰值的應(yīng)用，進(jìn)行重新評估其彈性伸縮最大值配置是否合理。若期望最大實(shí)例數(shù)超過產(chǎn)品限制（當(dāng)前限制單應(yīng)用50實(shí)例數(shù)，可提工單反饋提高上限）

可用區(qū)再均衡

彈性伸縮觸發(fā)縮容后可能會導(dǎo)致可用區(qū)分配不均，可以在實(shí)例列表中查看實(shí)例所屬可用區(qū)，若可用區(qū)不均衡可以通過重啟應(yīng)用操作實(shí)現(xiàn)再均衡。

自動恢復(fù)彈性配置

當(dāng)進(jìn)行應(yīng)用部署等變更單操作時(shí)，SAE會停止當(dāng)前應(yīng)用的彈性伸縮配置避免兩種操作沖突，若期望變更單完成后恢復(fù)彈性配置，可以在部署時(shí)勾選系統(tǒng)自動恢復(fù)。

彈性歷史記錄

SAE彈性生效行為當(dāng)前可通過事件進(jìn)行查看擴(kuò)縮時(shí)間，擴(kuò)縮動作，以及實(shí)時(shí)，歷史決策記錄和決策上下文可視化功能，以便衡量彈性伸縮策略的有效性，并在必要時(shí)進(jìn)行調(diào)整。

彈性事件通知

結(jié)合釘釘，Webhook,短信電話等多種通知渠道，便于及時(shí)了解彈性觸發(fā)狀況。

最后分享一個(gè)采用SAE彈性伸縮功能的客戶案例，在2020新冠疫情期間，某在線教育客戶業(yè)務(wù)流量暴漲7-8倍，硬件成本和業(yè)務(wù)穩(wěn)定性面臨巨大風(fēng)險(xiǎn)。 如果此時(shí)采用傳統(tǒng)的ECS架構(gòu)，客戶就需要在非常短的時(shí)間內(nèi)做基礎(chǔ)設(shè)施的架構(gòu)升級，這對用戶的成本及精力都是非常大的挑戰(zhàn)。 但如果采用SAE，用戶0改造成本即可享受Serverless帶來的技術(shù)紅利，結(jié)合SAE的多場景彈性策略配置，彈性自適應(yīng)和實(shí)時(shí)可觀測能力，保障了用戶應(yīng)用在高峰期的業(yè)務(wù)SLA，并且通過極致彈性效率，節(jié)省硬件成本達(dá)到35%。

綜上，彈性發(fā)展方向上，尤其是在Serverless場景，更強(qiáng)調(diào)應(yīng)對突發(fā)流量的能力，其目標(biāo)在于無需容量規(guī)劃，通過指標(biāo)監(jiān)控配合極致彈性能力實(shí)現(xiàn)應(yīng)用資源的近乎按需使用且整個(gè)過程服務(wù)可用。 SAE通過對彈性組件和應(yīng)用全生命周期的不斷優(yōu)化以達(dá)到秒級彈性，并在彈性能力，場景豐富度，穩(wěn)定性上具備核心競爭力，是傳統(tǒng)應(yīng)用0改造上Serverless的最佳選擇。

分布式文件存儲服務(wù)器之Minio對象存儲技術(shù)參考指南

Minio對象存儲技術(shù)

MinIO是一種高性能對象存儲解決方案，原生支持Kubernetes部署。 MinIO提供與AmazonWebServicesS3兼容的API并支持所有核心S3功能。 MinIO是在GNUAffero通用公共許可證v3.0下發(fā)布的。

也許提起對象存儲技術(shù)，我們都經(jīng)歷過Fastdfs長時(shí)間的拉鋸戰(zhàn)，即使現(xiàn)在大部分都在使用云服務(wù)廠商提供的OSS對象存儲服務(wù)，但是其所花費(fèi)的經(jīng)濟(jì)成本也是遞增的，而且數(shù)據(jù)都存儲在別人的服務(wù)器上，從一定程度上來說，對于文件資源的把控粒度是極其不可控制，公網(wǎng)數(shù)據(jù)是何其的沒有隱私可言。 雖然，對于開發(fā)層面上來說，只需要整合對應(yīng)的SDK，對其使用已經(jīng)是開箱即用。 但是，對于選擇自研對象存儲技術(shù)來說，Minio何嘗不失為一大利器。 其搭建過程與整合方面，幾乎已經(jīng)沒有什么瓶頸可言。 不論是從傳統(tǒng)服務(wù)器的安裝，還是基于Docker以及Kubernetes的部署，簡直簡單得不要不要的。

基本概述

,MinIO’ssoftware-definedsuiterunsseamlesslyinthepubliccloud,,MinIOcandeliverarangeofusecasesfromAI/ML,analytics,backup/restoreandmodernwebandmobileapps.

MinIO在最大數(shù)量的環(huán)境中支持最廣泛的用例。 自云原生以來，MinIO的軟件定義套件在公共云、私有云和邊緣無縫運(yùn)行——使其成為混合云的領(lǐng)導(dǎo)者。 憑借行業(yè)領(lǐng)先的性能和可擴(kuò)展性，MinIO可以提供一系列用例，包括AI/ML、分析、備份/恢復(fù)以及現(xiàn)代Web和移動應(yīng)用程序。

HybridCloud：混合云

Borncloudnative：云原生

MinIOispioneeringhighperformanceobjectstorage：高性能對象存儲的先驅(qū)

Builtontheprinciplesofwebscale：建立在網(wǎng)絡(luò)規(guī)模的原則上

The#.開源對象存儲，并且最適合企業(yè)

ThedefactostandardforAmazonS3compatibility：AmazonS3兼容性的事實(shí)標(biāo)準(zhǔn)

Simplypowerful：簡單強(qiáng)大[極簡主義]

基本特點(diǎn)

MinIO的企業(yè)級特性代表了對象存儲空間的標(biāo)準(zhǔn)。 從AWSS3API到S3Select以及我們對內(nèi)聯(lián)擦除編碼和安全性的實(shí)施，我們的代碼廣受贊譽(yù)，并經(jīng)常被一些技術(shù)和商業(yè)領(lǐng)域的大腕復(fù)制。

ErasureCoding：糾錯碼

MinIO使用以匯編代碼編寫的每個(gè)對象內(nèi)聯(lián)擦除編碼來保護(hù)數(shù)據(jù)，以提供盡可能高的性能。 MinIO使用Reed-Solomon代碼將對象條帶化為具有用戶可配置冗余級別的數(shù)據(jù)和奇偶校驗(yàn)塊。 MinIO的ErasureCoding在對象級別執(zhí)行修復(fù)，可以獨(dú)立修復(fù)多個(gè)對象。

在N/2的最大奇偶校驗(yàn)下，MinIO的實(shí)現(xiàn)可以確保在部署中僅使用((N/2)+1)個(gè)操作驅(qū)動器進(jìn)行不間斷的讀寫操作。 例如，在12個(gè)驅(qū)動器的設(shè)置中，MinIO將對象分片到6個(gè)數(shù)據(jù)和6個(gè)奇偶校驗(yàn)驅(qū)動器，并且可以可靠地寫入新對象或重建現(xiàn)有對象，而部署中僅剩下7個(gè)驅(qū)動器。

BitrotProtection：Bitrot保護(hù)

靜默數(shù)據(jù)損壞或bitrot是磁盤驅(qū)動器面臨的嚴(yán)重問題，導(dǎo)致數(shù)據(jù)在用戶不知情的情況下?lián)p壞。 原因是多方面的（驅(qū)動器老化、電流峰值、磁盤固件中的錯誤、幻像寫入、讀取/寫入方向錯誤、驅(qū)動程序錯誤、意外覆蓋），但結(jié)果是一樣的-數(shù)據(jù)受損。

MinIO對HighwayHash算法的優(yōu)化實(shí)現(xiàn)確保它永遠(yuǎn)不會讀取損壞的數(shù)據(jù)-它即時(shí)捕獲和修復(fù)損壞的對象。 通過在READ上計(jì)算散列并在從應(yīng)用程序、網(wǎng)絡(luò)到內(nèi)存/驅(qū)動器的WRITE上對其進(jìn)行驗(yàn)證來確保端到端的完整性。 該實(shí)現(xiàn)專為速度而設(shè)計(jì)，可以在IntelCPU的單核上實(shí)現(xiàn)超過10GB/秒的散列速度。

Encryption：加密處理

在飛行中加密數(shù)據(jù)是一回事；保護(hù)靜態(tài)數(shù)據(jù)是另一回事。 MinIO支持多種復(fù)雜的服務(wù)器端加密方案來保護(hù)數(shù)據(jù)——無論數(shù)據(jù)在哪里。 MinIO的方法以可忽略的性能開銷確保機(jī)密性、完整性和真實(shí)性。 使用AES-256-GCM、ChaCha20-Poly1305和AES-CBC支持服務(wù)器端和客戶端加密。

加密對象使用AEAD服務(wù)器端加密進(jìn)行防篡改。 此外，MinIO與所有常用的密鑰管理解決方案（例如HashiCorpVault）兼容并經(jīng)過測試。 MinIO使用密鑰管理系統(tǒng)(KMS)來支持SSE-S3。

如果客戶端請求SSE-S3或啟用自動加密，則MinIO服務(wù)器使用唯一的對象密鑰加密每個(gè)對象，該對象密鑰受KMS管理的主密鑰保護(hù)。 鑒于極低的開銷，可以為每個(gè)應(yīng)用程序和實(shí)例打開自動加密。

IdentityManagement：身份管理

MinIO支持身份管理中最先進(jìn)的標(biāo)準(zhǔn)，與OpenID連接兼容提供商以及關(guān)鍵的外部IDP供應(yīng)商集成。 這意味著訪問是集中的，密碼是臨時(shí)的和輪換的，而不是存儲在配置文件和數(shù)據(jù)庫中。 此外，訪問策略是細(xì)粒度和高度可配置的，這意味著支持多租戶和多實(shí)例部署變得簡單。

ContinuousReplication：連續(xù)復(fù)制

傳統(tǒng)復(fù)制方法的挑戰(zhàn)在于，它們無法有效擴(kuò)展超過數(shù)百TB。 話雖如此，每個(gè)人都需要一個(gè)復(fù)制策略來支持災(zāi)難恢復(fù)，并且該策略需要跨越地域、數(shù)據(jù)中心和云。

MinIO的持續(xù)復(fù)制專為大規(guī)模、跨數(shù)據(jù)中心部署而設(shè)計(jì)。 通過利用Lambda計(jì)算通知和對象元數(shù)據(jù)，它可以高效快速地計(jì)算增量。 Lambda通知確保更改立即傳播，而不是傳統(tǒng)的批處理模式。

連續(xù)復(fù)制意味著如果發(fā)生故障，即使面對高度動態(tài)的數(shù)據(jù)集，數(shù)據(jù)丟失也將保持在最低限度。 最后，與MinIO所做的一樣，持續(xù)復(fù)制是多供應(yīng)商的，這意味著您的備份位置可以是從NAS到公共云的任何位置。

GlobalFederation：全球聯(lián)合會

現(xiàn)代企業(yè)到處都有數(shù)據(jù)。 MinIO允許將這些不同的實(shí)例組合起來形成一個(gè)統(tǒng)一的全局命名空間。 具體來說，可以將任意數(shù)量的MinIO服務(wù)器組合成一個(gè)分布式模式集，多個(gè)分布式模式集可以組合成一個(gè)MinIO服務(wù)器聯(lián)合。 每個(gè)MinIOServerFederation都提供統(tǒng)一的管理和命名空間。

MinIO聯(lián)合服務(wù)器支持無限數(shù)量的分布式模式集。 這種方法的影響是對象存儲可以為大型、地理分布的企業(yè)大規(guī)模擴(kuò)展，同時(shí)保留從單個(gè)控制臺容納各種應(yīng)用程序（Splunk、Teradata、Spark、Hive、Presto、TensorFlow、H20）的能力。

Multi-CloudGateway：多云網(wǎng)關(guān)

所有企業(yè)都在采用多云戰(zhàn)略。 這也包括私有云。 因此，您的裸機(jī)虛擬化容器和公共云服務(wù)（包括Google、Microsoft和阿里巴巴等非S3提供商）必須看起來相同。 雖然現(xiàn)代應(yīng)用程序具有高度可移植性，但支持這些應(yīng)用程序的數(shù)據(jù)卻不是。

讓這些數(shù)據(jù)無論位于何處都可用，是MinIO解決的主要挑戰(zhàn)。 MinIO在裸機(jī)、網(wǎng)絡(luò)附加存儲和每個(gè)公共云上運(yùn)行。 更重要的是，MinIO通過AmazonS3API確保您從應(yīng)用程序和管理的角度來看這些數(shù)據(jù)的視圖看起來完全相同。

MinIO可以走得更遠(yuǎn)，使您現(xiàn)有的存儲基礎(chǔ)設(shè)施與AmazonS3兼容。 影響是深遠(yuǎn)的。 現(xiàn)在，組織可以真正統(tǒng)一他們的數(shù)據(jù)基礎(chǔ)設(shè)施——從文件到塊，所有這些都顯示為可通過AmazonS3API訪問的對象，而無需遷移。

WORM：WORM對象鎖定

啟用WORM后，MinIO會禁用所有可能改變對象數(shù)據(jù)和元數(shù)據(jù)的API。 這意味著一旦寫入的數(shù)據(jù)就可以防篡改。 這對于許多不同的監(jiān)管要求具有實(shí)際應(yīng)用。

基本架構(gòu)

MinIO被設(shè)計(jì)為云原生，可以作為由外部編排服務(wù)（如Kubernetes）管理的輕量級容器運(yùn)行。 整個(gè)服務(wù)器是一個(gè)約40MB的靜態(tài)二進(jìn)制文件，并且在使用CPU和內(nèi)存資源方面非常高效-即使在高負(fù)載下也是如此。 結(jié)果是您可以在共享硬件上共同托管大量租戶。

MinIO在帶有本地連接驅(qū)動器(JBOD/JBOF)的商用服務(wù)器上運(yùn)行。 集群中的所有服務(wù)器的能力相同（完全對稱架構(gòu)）。 沒有名稱節(jié)點(diǎn)或元數(shù)據(jù)服務(wù)器。

MinIO將數(shù)據(jù)和元數(shù)據(jù)作為對象一起寫入，無需元數(shù)據(jù)數(shù)據(jù)庫。 此外，MinIO將所有功能（擦除代碼、bitrot檢查、加密）作為內(nèi)聯(lián)、嚴(yán)格一致的操作執(zhí)行。 結(jié)果是MinIO非常有彈性。

每個(gè)MinIO集群是一組分布式MinIO服務(wù)器，每個(gè)節(jié)點(diǎn)一個(gè)進(jìn)程。 MinIO作為單個(gè)進(jìn)程在用戶空間運(yùn)行，并使用輕量級協(xié)程來實(shí)現(xiàn)高并發(fā)。 驅(qū)動器被分組到擦除集（默認(rèn)情況下每組16個(gè)驅(qū)動器），并且使用確定性散列算法將對象放置在這些集上。

MinIO專為大規(guī)模、多數(shù)據(jù)中心的云存儲服務(wù)而設(shè)計(jì)。 每個(gè)租戶運(yùn)行自己的MinIO集群，與其他租戶完全隔離，使他們能夠保護(hù)他們免受升級、更新和安全事件的任何中斷。 每個(gè)租戶通過跨地域聯(lián)合集群來獨(dú)立擴(kuò)展。

MinIO服務(wù)器功能

MinIO的企業(yè)級特性代表了對象存儲空間的標(biāo)準(zhǔn)。 從AWSS3API到S3Select以及我們對內(nèi)聯(lián)擦除編碼和安全性的實(shí)施，我們的代碼廣受贊譽(yù)，并經(jīng)常被一些技術(shù)和商業(yè)領(lǐng)域的大腕復(fù)制。

MinIO對象保留

默認(rèn)情況下，對唯一對象名稱的每次新寫入操作都會導(dǎo)致覆蓋該對象。 您可以將MinIO配置為創(chuàng)建每個(gè)對象突變的版本，從而保留該對象的完整歷史記錄。 MinIO還支持一次寫入多次讀取(WORM)鎖定版本化對象，以確保在指定的持續(xù)時(shí)間內(nèi)或直到顯式解除鎖定為止的完全不變性。

版本控制和對象鎖定功能僅適用于分布式MinIO部署：

BucketVersioning：存儲桶版本控制

MinIO支持在單個(gè)存儲桶中保存對象的多個(gè)“版本”。 通常會覆蓋現(xiàn)有對象的寫入操作會導(dǎo)致創(chuàng)建新的版本化對象。 MinIO版本控制可防止意外覆蓋和刪除，同時(shí)支持“撤消”寫入操作。 存儲桶版本控制是配置對象鎖定和保留規(guī)則的先決條件。

對于版本化存儲桶，任何改變對象的寫入操作都會導(dǎo)致該對象的新版本具有唯一的版本ID。 MinIO標(biāo)記客戶端默認(rèn)檢索的對象的“最新”版本。 然后，客戶端可以明確選擇列出、檢索或刪除特定對象版本。

其中：

具有單一版本的對象：MinIO為每個(gè)對象添加一個(gè)唯一的版本ID作為寫入操作的一部分。

2.具有多個(gè)版本的對象：MinIO保留對象的所有版本，并將最新版本標(biāo)記為“最新”。

3.檢索最新的對象版本

4.檢索特定對象版本

WORM：對象鎖定

MinIO對象鎖定（“對象保留”）強(qiáng)制執(zhí)行一次寫入多次讀取(WORM)不變性以保護(hù)版本化對象不被刪除。 MinIO支持基于持續(xù)時(shí)間的對象保留和無限期合法保留保留。

MinIO對象鎖定提供關(guān)鍵數(shù)據(jù)保留合規(guī)性，并符合CohassetAssociates的SEC17a-4(f)、FINRA4511(C)和CFTC1.31(c)-(d)要求。

其中：

不帶鎖的桶：MinIO版本控制保留了對象突變的完整歷史。 但是，應(yīng)用程序可以明確刪除特定的對象版本。

帶鎖的桶：對存儲桶中的對象應(yīng)用默認(rèn)的30天WORM鎖定可確保所有對象版本的最短保留期和保護(hù)期。

3.鎖定桶中的刪除操作：刪除操作遵循版本化存儲桶中的正常行為，其中MinIODeleteMarker為對象創(chuàng)建一個(gè)。 但是，對象的非刪除標(biāo)記版本仍受保留規(guī)則約束，并且不會受到任何特定刪除或覆蓋嘗試的影響。

4.鎖定存儲桶中的版本化刪除操作：MinIO會阻止任何刪除在WORM鎖定下持有的特定對象版本的嘗試。 客戶端可以刪除版本的最早可能時(shí)間是鎖定到期時(shí)。

Minio部署和管理

MinIO是一個(gè)軟件定義的高性能分布式對象存儲服務(wù)器。 您可以在消費(fèi)級或企業(yè)級硬件以及各種操作系統(tǒng)和架構(gòu)上運(yùn)行MinIO。

MinIO支持兩種部署模式：獨(dú)立和分布式：

獨(dú)立部署：具有單個(gè)存儲卷或文件夾的單個(gè)MinIO服務(wù)器。 獨(dú)立部署最適合使用MinIO進(jìn)行對象存儲的應(yīng)用程序的評估和初始開發(fā)，或?yàn)閱蝹€(gè)存儲卷提供S3訪問層。 獨(dú)立部署不提供對全套MinIO高級S3特性和功能的訪問。

分布式部署：一臺或多臺MinIO服務(wù)器，所有服務(wù)器上至少有四個(gè)總存儲卷。 分布式部署最適合生產(chǎn)環(huán)境和工作負(fù)載，并支持MinIO的所有核心和高級S3特性和功能。 對于生產(chǎn)環(huán)境，MinIO建議使用4個(gè)節(jié)點(diǎn)和4個(gè)驅(qū)動器的基線拓?fù)洹?

---

---

相關(guān)標(biāo)簽： 集群的云原生最佳實(shí)踐、 上的實(shí)現(xiàn)指南、 Kubernetes、 kubernetes怎么讀、 在、 和、 Azure、 GCP、 AWS、

上一篇：sethcexeWindows輔助工具，揭開其鮮為人知的

下一篇：Kubernetes集群的安全性保護(hù)免受網(wǎng)絡(luò)威脅惡