集羣鏡像-集羣總體打包，分佈式應用build share run

做者 | fanux.中弈

什麼是集羣鏡像

顧名思義和操做系統.iso鏡像或者Docker鏡像相似，集羣鏡像是用必定的技術手段把整個集羣的全部文件以必定格式打成的一個資源包。

對比單機和集羣會發現一些有趣現象：

• 單機有計算存儲網絡這些驅動，集羣有CNI/CSI/CRI的實現像是集羣的驅動
• 操做系統單機有ubuntu centos這些，咱們能夠把kubernetes當作雲操做系統
• 單機上能夠運行docker容器 或者是虛擬機，至關於一個運行的實例，集羣也有運行着k8s的實例
• 單機上的虛擬機鏡像，docker鏡像，因此隨着雲計算技術的發展，在集羣這個緯度也會抽象出相似的鏡像技術。

​

以基於kubernetes的集羣鏡像爲例，裏面包含了除操做系統之外的全部文件：

• docker的依賴的二進制與systemd配置，dockerd的配置，以及一個私有的容器鏡像倉庫
• kubernetes核心組件二進制，容器鏡像，kubelet system配置等
• 應用須要用到的yaml配置或者helm chart，以及應用的容器鏡像
• 其它腳本，配置與二進制工具等應用運行須要的全部依賴

一樣集羣鏡像運行時確定不是起一個容器或者裝在一臺機器上，而是這個鏡像能夠直接安裝到多臺服務器上或者直接對接到公有云的基礎設施上。

sealer介紹

sealer是阿里巴巴開源的集羣鏡像的一個實現方式，項目地址： https://github.com/alibaba/se...
Docker解決了單個容器的鏡像化問題，而sealer經過把整個集羣打包，實現了分佈式軟件的Build Share Run!!!
​

試想咱們要去交付一個SaaS應用，它依賴了mysql es redis這些數據庫和中間件，全部東西都在kubernetes上進行編排，那若是沒有集羣鏡像那要作以下操做：

1. 找個工具去安裝k8s集羣
2. helm install mysql es redis... 若是是離線環境可能還須要導入容器鏡像
3. kubectl apply yoursaas

看似好像也沒那麼複雜，可是其實從整個項目交付的角度來講是面向過程極易出錯的
​

那如今若是如今提供另一個方式只要一條命令解決上面的問題你會不會用？
sealer run your-saas-application-with-mysql-redis-es:latest
能夠看到只須要run一個集羣鏡像整個集羣就被總體交付了，細節複雜的操做都被屏蔽掉了,並且任何應用均可以使用相同的方式運行。那這個集羣鏡像是怎麼來的呢：

咱們只須要定義一個相似Dockerfile的文件咱們稱之爲Kubefile, 而後執行一下build命令便可：
sealer build -t your-saas-application-with-mysql-redis-es:latest .
在單機和集羣兩個緯度進行一個對比就能夠一目瞭然：

docker能夠經過Dockerfile構建一個docker鏡像，使用compose就能夠運行容器。
sealer經過Kubefile構建一個CloudImage,使用Clusterfile啓動整個集羣。

快速體驗

製做和運行一個kubernetes dashboard的集羣鏡像來體驗一個完整的流程。
編寫Kubefile

# 基礎鏡像，已經被製做好了裏面包含全部的kubernetes啓動相關的依賴
FROM registry.cn-qingdao.aliyuncs.com/sealer-io/cloudrootfs:v1.16.9-alpha.7
# 下載官方的dashboard yaml編排文件，已經下載了可使用COPY指令
RUN wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml
# 指定運行方式，可使用kubectl helm kustomiz等
CMD kubectl apply -f recommended.yaml

build dashboard集羣鏡像
sealer build -t kubernetes-with-dashobard:latest .
​

運行集羣鏡像

# 下面命令會在服務器上安裝k8s集羣並apply dashboard, passwd指定服務器ssh密碼,也可使用密鑰
sealer run kubernetes-with-dashobard:latest \
    --master 192.168.0.2,192.168.0.3,192.168.0.4 \
  --node 192.168.0.5,192.168.0.6 \
  --passwd xxx
# 檢查pod
kubectl get pod -A |grep dashboard

​

把製做好的鏡像推送到鏡像倉庫，兼容docker registry

sealer tag kubernetes-with-dashobard:latest docker.io/fanux/dashobard:latest
sealer push docker.io/fanux/dashobard:latest

這樣就能夠把製做好的鏡像交付出去或者提供給別人複用。

使用場景

sealer具體能幫咱們作哪些事呢，下面列舉幾個主要場景：
​

| 安裝kubernetes與集羣生命週期管理(升級/備份/恢復/伸縮)
這是個最簡單的場景，無論你是須要在單機上安裝個開發測試環境仍是在生產環境中安裝一個高可用集羣，無論是裸機仍是對接公有云，或者各類體系結構操做系統，均可以使用sealer進行安裝，這裏只安裝kubernetes的話就選擇個基礎鏡像便可。
與其它的安裝工具對比，sealer優點在於：

1. 簡單到使人髮指 sealer run 一條命令結束
2. 速度快到使人窒息，3min裝完6節點，可能你在使用別的工具還沒下載完sealer就已經裝完了，然而咱們後續還有黑科技優化到2min甚至1min之內
3. 兼容性與穩定性 兼容各類操做系統，支持x86 arm等體系結構
4. 一致性設計，會讓集羣保持Clusterfile中的定義狀態，以升級爲例，只須要改一下Clusterfile中的版本號便可實現升級。

​

速度快是由於首先是golang實現，意味着咱們能夠不少很細緻的地方作併發的處理，這相比ansible就有更多的優點了，並且還能夠作更細緻的錯誤處理，而後在鏡像分發上拋棄了之前load的方式，後續在文件分發上也會作優化達到安裝性能上的極致。
​

兼容性上，docker kubelet這裏都採用了二進制+systemd安裝核心組件全容器化，這樣不用再去依賴yum apt這類感知操做系統的安裝工具。 ARM和x86採用不一樣的鏡像支持與sealer自己解耦開。 對公有云的適配也抽離單獨模塊進行實現，這裏咱們沒去對接terraform緣由仍是爲了性能，在咱們的場景下terraform啓動基礎設施將近3min，而咱們經過退避重試把基礎設施啓動優化到了30s之內，還有就是在集羣鏡像這個場景下是不須要這麼複雜的基礎設施管理能力的，咱們不想讓sealer變重也不想去依賴一個命令行工具。
​

一致性的設計理念是sealer中值得一提的，集羣鏡像與Clusterfile決定了集羣是什麼樣子的，相同的鏡像與Clusterfile就能run出個同樣的集羣出來。 變動要麼變動Clusterfile如增長節點，改變節點規格，要麼換鏡像，換鏡像的時候由於集羣鏡像也是分層結構，hash值不變的layer不會發生變動，而hash發生變化會幫助從新apply該層。
​

| 雲原生生態軟件的打包/安裝等如prometheus mysql集羣等
sealer run prometheus:latest 就能夠建立一個帶有prometheus的集羣，或者在一個已有的集羣中安裝prometheus。
那麼問題來了：和helm啥區別？

1. sealer 不關心編排，更注重打包，上面例子prometheus能夠用helm編排的，sealer會把chart和chart裏面須要的全部容器鏡像打包起來，這是在build的過程當中經過黑科技作到的，由於build過程會像docker build同樣起臨時的kubernetes集羣，而後咱們就知道了集羣依賴了哪些容器鏡像，最後把這些容器鏡像打包。
2. 和kubernetes一塊兒打包，拿了一個chart它未必能安裝成功，好比使用了廢棄的api版本，可是作成鏡像把kubnernetes也包在一塊兒了，只要build沒問題，run就沒問題，這點和docker把操做系統rootfs打包在一塊兒殊途同歸。
3. 集成性，集羣鏡像更關注整個分佈式應用集羣總體打包，如把prometheus ELK mysql集羣這些作成一個鏡像服務與業務。

因此sealer與helm是協做關係，分工明確。
後續就能夠在sealer的官方鏡像倉庫中找到這些通用的集羣鏡像而後直接使用。
​

| SaaS軟件總體打包/交付 專有云離線交付
從分佈式應用的視角看，一般從上往下，少則幾個多則上百的組件，現有總體交付方式大多都是面向過程的，中間須要不少認爲干預的事，sealer就能夠把這些東西通通打包在一塊兒進行一鍵交付。
​

可能你會問，我作個tar.gz再加個ansible腳本不也是能同樣一鍵化嘛，那是確定，就和docker鏡像出現以前你們也經過tar.gz交付同樣，你會發現標準和技術的出現解決和人與人之間的協做問題, 有了集羣鏡像你能夠直接複用別人的成果，也能製做好東西作別人使用。
​

專有云場景就很是適合使用sealer，不少客戶機房都是離線的，而集羣鏡像會把全部依賴打到鏡像中。 只要鏡像製做的好那全部局點均可以以相同的方式進行一鍵交付，得到極佳的一致性體驗。
​

| 在公有云上實踐上述場景
sealer自帶對接公有云屬性，不少狀況下對接公有云會有更好的使用體驗，好比安裝集羣時只須要指定服務器數量和規格而不用關心IP，伸縮直接修改Clusterfile中定義的數字便可。

技術原理簡介

| 寫時複製
集羣鏡像的存儲也是經過寫時複製的方式，這樣作有兩個好處，咱們能夠把一個集羣中不一樣的分佈式式軟件打在不一樣的層，以實現複用，還能夠實現直接把集羣鏡像push到docker鏡像倉庫中。
​

| 容器鏡像緩存
build的過程當中sealer是如何知道待構建的集羣鏡像裏有哪些容器鏡像，以及怎麼把容器鏡像存儲下來，這其中有一些難點問題:

1. 如何知道分佈式軟件中有哪些容器鏡像，由於咱們須要把這些鏡像緩存下來，無論是掃描用戶的yaml文件仍是用helm template以後掃描都是不完美的，首先不能肯定用戶的編排方式是什麼，其次有些軟件甚至不把鏡像地址寫在編排文件中，而是經過本身的程序去拉起。沒法保證build成功運行就必定沒問題。
2. 容器鏡像是須要被存儲到私有倉庫中打包在集羣鏡像裏，那容器鏡像倉庫地址勢必和編排文件中寫的不同，特別是怎麼保證用戶alwayPull的時候仍是可以在私有倉庫中下載到鏡像。

對待第一個問題，sealer解決方式是 sealer build的過程當中和Docker build同樣會起一個臨時的kubernetes集羣，並執行用戶在Kubefile中定義的apply指令。

這樣就能夠保證用戶依賴的全部鏡像都被打包進去，不管用戶使用什麼樣的編排方式。
第二個問題，咱們打包容器鏡像到私有鏡像倉庫中，怎樣使用這個私有鏡像也是個問題，由於假設私有鏡像倉庫名爲localhost:5000 那確定會和編排文件中寫的不同，咱們有兩種方式解決，第一種是hack和docker，作了一個只要私有鏡像倉庫中有就直接從私有鏡像中拉取，沒有才去公網拉取鏡像的能力。 

還有種方案是無侵入docker的proxy,把docker請求所有打給代理，讓代理去決定若是私有倉庫有就從私有倉庫拉取。同時咱們還加強了registry的能力讓registry能夠cache多個遠程倉庫的能力。
sealer的這種方案完美的解決了離線場景鏡像打包的問題。
​

| 負載均衡
sealer的集羣高可用使用了輕量級的負載均衡lvscare，首先相比其它負載均衡lvscare很是小几百行代碼，並且lvscare只作ipvs規則的守護，自己不作負載很是穩定，直接在node上監聽apiserver，若是跪了就移除對應的規則，從新起來以後會自動加回，至關因而一個專用的負載均衡器，在sealos項目中也用了兩年多，有普遍的實踐。

| 運行時
運行時就是支撐應用運行的環境，像base on kuberentes的運行時sealer就能夠透明的支持很是簡單，以istio爲例，用戶只須要：

FROM kubernetes:v1.18.3
RUN curl -L https://istio.io/downloadIstio | sh -

就能夠build出來一個istio的運行時供本身應用使用。
​

對於不是base on kuberentes的運行時，如k0s k3s，能夠擴展sealer.Runtime中的接口，這樣之後就能夠：

FROM k3s:v1.18.3
RUN curl -L https://istio.io/downloadIstio | sh -

更牛的擴展好比擴展ACK的runtime

FROM aliyum.com/ACK:v1.16.9
RUN curl -L https://istio.io/downloadIstio | sh -

這種鏡像會直接幫助用戶應用運行到ACK上。 以上有些能力在roadmap中
​

| 基礎設施
如今不少用戶都但願在雲端運行本身的集羣鏡像，sealer自帶對接公有云能力，sealer本身實現的基礎設施管理器，得益於咱們更精細的退避重試機制，30s便可完成基礎設施構建(阿里雲6節點)性能是同類工具中的佼佼者，且API調用次數大大下降，配置兼容Clusterfile。

總結

sealer將來的一些願景與價值提現：

• sealer能夠以極其簡單的方式讓用戶自定義集羣，解決分佈式軟件製做者與使用者的協做問題。
• 極其簡單友好的User Interface, 能屏蔽和兼容各類底層技術細節，處處運行
• 生態建設，官方倉庫裏將會涵蓋經常使用的分佈式軟件

​

最後咱們總結下：

• 若是你要總體交付你的分佈式SaaS，請用sealer
• 若是你要集成多個分佈式服務在一塊兒，如數據庫消息隊列或者微服務運行時，請用sealer
• 若是你要安裝一個分佈式應用如mysql主備集羣，請用sealer
• 若是你須要安裝/管理一個kubernetes高可用集羣，請用sealer
• 若是你要初始化多個數據中心，保持多個數據中心狀態強一致，請用sealer
• 若是你須要在公有云上實現上述場景，請用sealer

​

sealer將會在近期宣佈開源，有興趣的能夠關注https://github.com/alibaba/se...