作者 | 中弈
寫在開頭
身為一名技術人員，總是喜歡把自己的作品打造成理想狀態呈現給別人，我非常榮幸能把集群鏡像這樣一個卓越的想法變成現實, 也非常開心用戶使用我們的作品時對我們的高度認可，
Sealos 雖然已經超過 5k 星，數千家客戶在生產環境中使用，不乏很多一線互聯網公司和大廠，曾經 sealos 也令我很激動，我把一件復雜的事情做到的極簡，這是核心競爭力，即便如此我還是不會夸它，因為在 sealer 面前它黯然失色，
Sealer為什么會誕生
1、云的背景與趨勢
從應用的視角看，云的發展歷程就是一個不斷屏蔽底層細節讓應用更關注業務邏輯本身的一個程序，
Openstack 讓開發者不用再關心物理機復雜的管理問題，但是并未在應用本身管理在有任何改善，對于應用開發者依然需要和作業系統打交道，
Docker 的出現掀起了一場云架構的革命，穿透了傳統的 IaaS、PaaS，讓分層變模糊，此時已經幫助應用實作一些打包隔離作業，一定程度讓應用變得更容易管理，
Kubernetes 的出現讓云從分層架構走向“云內核”架構，云作業系統逐漸顯現，對下實作計算網路存盤這些資源的抽象，對上實作應用的編排管理，此時應用的配置管理，服務發現，資源配置變得更為簡單，發布分布式應用變得像發布單機應用一樣流暢，
Serverless FaaS 的出現就讓應用更聚焦于業務邏輯本身了，只是目前還沒能出現像 Kubernetes 一樣的實際標準性的東西，還處在百家爭鳴的階段，
有意思的地方的區塊鏈領域的智能合約，以太坊的 EVM 第一代合約天生就是 serverless，運行在以太坊這個世界計算機上，而以 Polkadot solana near ICP 這樣為代表的二代合約支持了 WASM 打破了 EVM 的場景局限，讓合約走向更通用的場景，所以非常期待云和鏈技術最終能在一個地方統一，實作真正意義上的“世界計算機”，所有應用都在這臺“超級電腦上”運行，
2、交付領域的痛點與剛需
我們希望讓 Kubernetes更簡單，順應技術大趨勢讓基于 Kubernetes 的交付變得更干凈利索，
目前專有云交付面臨的三大困局，Docker、Kubernetes、Helm 這些技術雖然解決掉了一部分痛點，但是并不徹底：
? Docke r僅解決了單個應用的鏡像化問題，對于軟體整體來說是包含非常多分布式組件的，這塊 docker 不管；
? Kubernetes 很好的解決了分布式應用管理和資源的抽象問題，應用之間復雜的應用如何編排，但是龐雜的編排配置如何管理？
? Helm 只是把編排檔案打包和引數的抽離，但是并不會把所有依賴都管理起來，
所以即便你使用了上述技術，一旦到了真實場景，一樣會焦頭爛額，
對于很多用戶而言安裝 Kubernetes 本身可能比裝業務還復雜，那么多容器鏡像如何管理，到了客戶環境需要的依賴沒人怎么辦，一個一個組件安裝人工誤操作導致出問題概率大大提升，
所以非常需要一個集群整體打包成鏡像的技術，在集群維度保障一致性，
3、優秀的設計理念
只有在偉大的想法誕生時你會為之激動，充滿熱情，想盡一切辦法讓它變成現實，
在設計 sealer 時想盡一切辦法讓它變得簡潔干凈但是還需要滿足各種能力，就像要把很多復雜的技術融入到一個手機里一樣，做減法才是考驗一個人設計能力的地方，
Sealer 的理念也把大道至簡和高度抽象闡述到了極致，確實以優雅的方式解決了很痛點的問題，符合行業大趨勢且能創造巨大的生態價值，
Sealer 的價值
1、幫助企業實作規模化交付
對于專有云交付類的公司而言，sealer 最終能幫你實作的就是實作規模化交付，擴大營收，降低成本，提高利潤，采用 sealer 技術的公司可以在規模化競爭中取勝，降低單次產品交付價格，創造核心價格優勢，
以現有的交付類專案現狀來看幾乎都是幾十萬上百萬起步，這幾乎就把客戶群體限制在頭部客戶了，但是對于中小企業需求是真實存在的，由于交付成本高導致出現這種有需求無市場的情況，如果價格能降低到數千或者幾萬，那新的市場就會完全被打開，
對于甲方來說也是一樣，采購一套軟體到落地都是數月的時間，和銷售溝通、poc、交付等等，整個鏈路非常長，因為乙方的交付成本變低，相應甲方的采購成本也會降低，
在 sealer 出現之前想一年線下交付一萬套復雜軟體對于絕大多數企業而言幾乎不可能完成，像小時級別的交付更是異想天開，但是 sealer 可以實作自助化，交付規模不再受技術水平限制，還能實作快速一鍵交付，
2、打破協作壁壘
Docker 出現之前就已經有非常多的容器技術了，為什么都沒有出現席卷之勢和顛覆效應？
很大一部分原因是標準的出現讓生態之間的協作成為可能，Docker 鏡像的出現讓軟體的生產者與交付者之間完美協同，我需要的任何東西都可以在倉庫中找到，而我不再需要去關心里面的實作細節，使用者真的像一個老板一樣只要結果，需要任何軟體都無腦 docker run...
然而很多人嘗試建立標準，絕大多數都失敗了，但 docker 卻成功了，為什么？因為一個標準快速普及在我看來通常需要滿足一些基本原則：
第一：切中痛點
第二：簡單極致
第三：不失強大
滿足以上三點成為公認的標準的可能性會大大提升，
Docker 鏡像標準把行程所有依賴打包，保障其一致性，這是交付中非常痛的地方，
同時滿足 2 和 3 是非常困難的，Dockerfile 簡簡單單幾條指令，你會發現雖然簡單但是幾乎可以打包任何東西，這就非常容易被廣泛接受，如果一個標準動輒大幾百頁檔案，用戶看一眼就嚇跑了更別說遵循了……
Sealer 的設計同樣遵循以上三點，
痛點方面，sealer 取 docker 設計思想之精髓，能 docker 所不能，因為現代的軟體幾乎都是分布式應用，docker 并不關心分布式應用如何做成鏡像，sealer 就專門以 K8s 為集群作業系統，把 docker 的思想衍生到集群維度，實作分布式軟體的構建、打包、交付、運行等等，
簡單極致，sealer 把奧卡姆剃刀運用到極致，指令刪減到比 dockerfile 指令還少，也遵循 docker 的指令設計以更容易讓用戶接受，如果三分鐘還沒看懂 sealer 的 Kubefile 那就是 sealer 設計的失敗，
sealer 簡單但并非簡陋，你會發現簡單幾條指令幾乎可以幫助用戶構建任何復雜的自定義 Kubernetes 集群和自定義分布式應用鏡像，然后一鍵運行，
所以 sealer 必將建立成功的集群鏡像交付標準，有了標準之后大家就可以相互更好的協作了，
在 sealer 出現之前，復雜應用設計的開發人員與交付人員之間總會有數不清的恩怨，前線交付人員不理解數十個業務之間的關系是怎樣的，研發人員不知道前線的交付環境有多復雜，一旦出問題，就拉十幾個人的在線會議……最后老板發現三個和尚沒水喝，
有了 sealer 之后，研發人員制作好集群鏡像，交付人員閉著眼睛 sealer run...如果失敗那就是研發人員鏡像沒制作好，鍋甩回去就行，有了標準分工明確，另外對于交付人員的要求也會變的極低，實習生培訓半天上崗，
3、靈活的定制性、自由組合、復用性、一致性與兼容性
我們會制作很多基礎鏡像供你直接“拿來主義”：
各種 Kubernetes 版本，各種架構 ARM、AMD…
包含各種 CNI、CSI 實作的鏡像，calico、flannel、openlocal、openebs…
各種生態軟體鏡像，高可用的mysql、redis、prometheus...
這些鏡像并非是 docker 鏡像，而是集群鏡像，pull 下來就直接可以運行出一個集群！
更變態的能力是我們支持這些鏡像的自由組合，比如你需要 calico+redis+mysql 的組合，那只需要 sealer merge 命令就可以把三個鏡像合并在一起供你的業務使用，集群鏡像就像玩泥巴一樣，把幾坨泥巴捏在一起還是一坨泥巴，高度的抽象能力令人嘆為觀止……
更更變態的能力是即便這些都不能滿足你，你也只需要像寫一個 Dockerfile 一樣簡單的去自定義你自己的集群里面包含什么，比如你想把自己軟體的前后端服務也打到集群鏡像中，而且你可以 FROM 已有的基礎鏡像來復用別人提供的能力，
而且 sealer 低層技術保障了這些鏡像具備非常好的兼容性，可以在任何平臺絲滑的運行起來，
如何把想法變成現實
sealer 僅發展半年多時間，就在社區吸引了四十多名開發者，三十多家試用客戶，在兩家生產環境中落地，
起扯訓了半年多的時間去做設計，寫設計檔案，這中間推翻了 N 個版本的設計，不斷精簡優化，每個指令設計都精雕細琢，嚴格遵循如無必要勿增物體，
設計完成之后還幾乎是光桿司令，此時在一個月內迅速集結隊伍，大部分是兄弟組成員，生態公司的開發者，如和諧云溝通時，非常認可我們的想法并決定投入人力，最終一個七人的虛擬組織誕生，密集的開發三個月之后誕生了首個版本并完成開源，
開源之后發展就更迅速了，快速聚集開源社區力量，吸引了很多外部開發者讓專案快速收斂穩定，很快吸引了一批用戶嘗試，可見需求之強烈以及用戶對于 sealer 理念的認可，
1、極簡的用戶使用介面設計
遵循大道至簡的設計理念，我們吸取 docker 的設計思想，讓集群鏡像的制作和運行也變得非常簡單，
構建集群鏡像的 Kubefile，類似 Dockerfile 但是更簡單，比如制作一個包含 calico 的集群鏡像：
FROM kubernetes:v1.19.8-alpine
COPY etc .
RUN wget https://docs.projectcalico.org/manifests/tigera-operator.yaml
CMD kubectl apply -f etc/tigera-operator.yaml
CMD kubectl apply -f etc/custom-resources.yaml
如何啟動集群的 Clusterfile，類似 Docker-compose：
apiVersion: sealer.cloud/v2
kind: Cluster
metadata:
name: default-kubernetes-cluster
spec:
image: kubernetes:v1.19.8
ssh:
passwd: xxx
hosts:
- ips: [192.168.0.2,192.168.0.3,192.168.0.4]
roles: [master]
- ips: [192.168.0.3]
roles: [node]
只需要配置集群鏡像名稱和服務器 IP 地址 ssh 資訊即可拉起一個集群，這里面的每一行都透射出精雕細琢，ip 為什么使用串列，roles 如何靈活的分組等，當然還有一些其他的欄位沒有展示出來，原則上不給不需要關注其它功能的用戶增加負擔，需要用什么樣的能力才去關心什么樣的引數，
2、優秀的插件機制
我們一些總會遇到一些非常奇葩的需求，極不通用，但是又是客戶剛需，你支持的話又會讓你的架構變亂，讓整個產品變得“不優雅”，影響到別的用戶使用體驗，
這個時候就必須通過強大的設計能力把這些功能剝離開，讓不需要用它的人完全感知不到它的存在，
所以 sealer 設計出了強大的插件機制，讓你愛干啥干啥但別影響別人，，
比如有些人非要想用 sealer 修改主機名，這其實壓根也不屬于 sealer 關心的范疇，那么就可以開發一個插件去做這個事，用戶配置了這個插件就激活了這個功能：
還有用戶說我想開發一個專用插件，但是不想把代碼貢獻給 sealer 社區，因為極不通用的能力，貢獻也沒有意義，這樣的場景我們支持 golang plugin 機制，載入.so 檔案實作插件的動態加載，
3、極致的性能極致追求
雖然我們在集群構建的程序中已經速度非常之快了，幾分鐘六節點幾乎是性能的極限了，然而用戶體驗是否絲滑，這一塊的影響非常之大，所以并沒停止性能方面的追求，
比如 terraform 對接公有云需要 2-3min 起基礎設施，我們覺得這太不可接受，自己重新寫了 driver 把這個時間縮短到了 30s 以下，這已經幾乎是極限了，再要提升就受限于服務端啟動虛擬機速度了，我們做了退避等待與更合理的并發機制達到這種性能，
比如集群鏡像如 docker 一樣會分層拉取鏡像，提高層復用提升性能，檔案拷貝的程序占用非常大的時間，我們做了一些按需拷貝的功能，未來準備對接 nydus 的一些能力實作懶加載和 P2P 分發集群鏡像，進一步提升性能，
比如 Build 集群鏡像程序中需要快取容器鏡像，傳統的做法是 pull 再 push 顯然多做了一些無用功，我們就采用代理直接 cache 下來，pull 的程序直接快取，但是 build 的時候需要起 registry 還是不夠極致，未來我們會直接集成核心代碼，在不啟動 registry 的情況下即可快取，
以上種種，說明我們為了用戶的極致體驗，可謂是煞費苦心……
寫在最后
簡單又強大的產品總是能抓住用戶的心，sealer 不僅需要解決核心的痛點問題，還需要讓用戶獲得極佳的使用體驗，
功能上 sealer 已經完成了“集群維度的 Docker”這一設定，未來在生態發展上會增加更多的投入，創造更多更優質的官方鏡像，建立更多的合作伙伴，真正把軟體的提供者與使用者連接起來，高效的協作，
作者介紹
中弈：阿里云技術專家，sealos 作者，sealer 專案發起人，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/449726.html
標籤：其他