![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/b49777257b574925821f72fe710ac467.png)

作者 | fanux.中弈
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/0SBslzaMWtqn9H8Q57urNA)

# 什麼是叢集映象

顧名思義，和作業系統 .iso 映象或 Docker 映象類似，叢集映象是**用一定的技術手段把整個叢集的所有檔案以一定格式打成的一個資源包**。

![1.jpg](https://ucc.alicdn.com/pic/developer-ecology/fe37cf50fbbb4f1a9ec1741ed4ee160f.jpg)

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

- 單機有計算、儲存、網路等驅動；叢集有 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/sealer_ 。

Docker 解決了單個容器的映象化問題，而 **sealer 透過把整個叢集打包，實現了分散式軟體的 Build Share Run!!!**

試想我們要去交付一個 SaaS 應用，它依賴了 MySQL/ES/Redis 這些資料庫和中介軟體，所有東西都在 Kubernetes 上進行編排，如果沒有叢集映象時，要做如下操作：

1. 找個工具去安裝 K8s 叢集
1. helm install mysql es redis... 如果是離線環境可能還需要匯入容器映象
1. kubectl apply yoursaas

看似好像也沒那麼複雜，但其實從整個專案交付的角度來說，以上操作是程式導向極易出錯的。

現在如果提供另外一個方式，只需一條命令就可解決上面的問題，你會不會用？

sealer run your-saas-application-with-mysql-redis-es:latest

可以看到，只需要 run 一個叢集映象，整個叢集就被交付了，細節複雜的操作都被遮蔽掉了，而且任何應用都可以使用相同的方式執行。這個叢集映象是怎麼來的呢？

![2.jpg](https://ucc.alicdn.com/pic/developer-ecology/e4866989932f414ca1ed471d865137c0.jpg)

如上圖所示：我們只需要定義一個類似 Dockerfile 的檔案，將其稱之為 Kubefile, 然後執行 build 命令即可：

`sealer build -t your-saas-application-with-mysql-redis-es:latest .`

從單機和叢集兩個緯度進行對比，就可以一目瞭然：

![3.jpg](https://ucc.alicdn.com/pic/developer-ecology/c6678420e86b4e3e8e33795d77bd7109.jpg)

- 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 具體能幫我們做哪些事呢？下面列舉幾個主要場景：

## 1. 安裝 Kubernetes 與叢集生命週期管理(升級/備份/恢復/伸縮)

這是個最簡單的場景，不管你是需要在單機上安裝個開發測試環境，還是在生產環境中安裝一個高可用叢集；不管是裸機還是對接公有云，或者各種體系結構作業系統，都可以使用 sealer 進行安裝，這裡只安裝 Kubernetes 的話就選擇個基礎映象即可。

與其它的安裝工具對比，sealer 優勢在於：

1. 簡單到令人髮指：sealer run 一條命令結束。
1. 速度快到令人窒息：3min 裝完 6 節點，可能你使用別的工具時還沒下載完 sealer 就已經裝完了，不僅如此，後續我們還有黑科技最佳化到 2min 甚至 1min 以內。
1. 相容性與穩定性：相容各種作業系統，支援 x86 arm 等體系結構。
1. 一致性設計：會讓叢集保持 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 該層。

## 2. 雲原生生態軟體的打包/安裝等，如 prometheus mysql 叢集

sealer run prometheus:latest 就可以建立一個帶有 prometheus 的叢集，或者在一個已有的叢集中安裝 prometheus。

那麼問題來了：它和 helm 啥區別？

1. sealer 不關心編排，更注重打包，上面例子 prometheus 可以用 helm 編排，sealer 會把 chart 和 chart 裡需要的所有容器映象打包起來，這是在 build 的過程中透過黑科技做到的，因為 build 過程會像 docker build 一樣起臨時的 Kubernetes 叢集，然後我們就知道叢集依賴了哪些容器映象，最後把這些容器映象打包。
1. 和 Kubernetes 一起打包，拿了一個 chart 它未必能安裝成功，比如使用了廢棄的 api 版本，但是做成映象把 Kubnernetes 也包在一起了，只要 build 沒問題，run 就沒問題，這點和 docker 把作業系統 rootfs 打包在一起有異曲同工之妙。
1. 整合性，叢集映象更關注整個分散式應用叢集整體打包，如把 prometheus ELK mysql 叢集做成一個映象服務與業務。

所以 sealer 與helm是協作關係，分工明確。

後續可以在 sealer 的官方映象倉庫中找到這些通用的叢集映象，直接使用即可。

## 3. SaaS 軟體整體打包/交付 專有云離線交付

從分散式應用的視角看，通常從上往下，少則幾個多則上百的元件，現有整體交付方式大多都是程式導向的，中間需要很多進行干預的事，sealer 就可以把這些東西統統打包在一起進行一鍵交付。

可能你會問：我們做個 tar.gz 再加個 ansible 指令碼不也能一鍵化嗎？答案是肯定的。就和 docker 映象出現之前，大家也透過 tar.gz 交付一樣，你會發現**標準和技術的出現解決了人與人之間的協作問題,** 有了叢集映象就可以直接複用別人的成果，也能製作好東西供別人使用。

專有云場景就非常適合使用 sealer，很多客戶機房都是離線的，而叢集映象會把所有依賴打到映象中，只要映象製作得好，那麼所有局點都能以相同的方式進行一鍵交付，獲得極佳的一致性體驗。

## 4. 在公有云上實踐上述場景

sealer 自帶對接公有云屬性，很多情況下對接公有云會有更好的使用體驗，比如安裝叢集時，只需要指定伺服器數量和規格而不用關心 IP，伸縮直接修改 Clusterfile 中定義的數字即可。

# 技術原理簡介

## 1. 寫時複製

叢集映象的儲存也是透過寫時複製的方式實現的。這樣做有兩個好處：我們可以把同一叢集中不同的分散式軟體打在不同層，以實現複用；還可以實現直接把叢集映象 push 到 docker 映象倉庫中。

## 2. 容器映象快取

build 的過程中 sealer 是如何知道待構建的叢集映象裡有哪些容器映象，以及怎麼把容器映象儲存下來呢？其中有一些難點問題:

1. 如何知道分散式軟體中有哪些容器映象？因為我們需要把這些映象快取下來，不管是掃描使用者的 yaml 檔案還是用 helm template 之後掃描都是不完美的。首先不能確定使用者的編排方式是什麼，其次有些軟體不把映象地址寫在編排檔案中，而是透過自己的程式去拉起，無法保證 build 成功執行就一定沒問題。
1. 容器映象是需要被儲存到私有倉庫中打包在叢集映象裡，那容器映象倉庫地址勢必和編排檔案中寫的不一樣，特別是怎麼保證使用者 alwayPull 的時候還是能夠在私有倉庫中下載到映象？

對待第一個問題，sealer 解決方式是：sealer build 的過程中和 Docker build 一樣，會拉起一個臨時的 Kubernetes 叢集，並執行使用者在 Kubefile 中定義的 apply 指令。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/5ac6fcab785d4a5397c2dc25425c828e.png)

如上圖所示，這樣就可以保證使用者依賴的所有映象都被打包進去，無論使用者使用什麼樣的編排方式。

第二個問題，我們打包容器映象到私有映象倉庫中，怎樣使用這個私有映象也是個難題，假設私有映象倉庫名為 localhost:5000，肯定會和編排檔案中寫的不一致，對此我們有兩種方式解決：

- 第一種是 hack 和 docker，做了一個只要私有映象倉庫中有就直接從私有映象中拉取，沒有才去公網拉取映象的能力。
- 第二種方案是無侵入 docke r的 proxy，把 docker 請求全部打給代理，讓代理去決定如果私有倉庫有就從私有倉庫拉取。同時我們還增強了 registry 的能力讓 registry 可以 cache 多個遠端倉庫的能力。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/330de92ea73b4d6f929cd56bd8578987.png)

sealer 的這種方案完美解決了離線場景映象打包的問題。

## 3. 負載均衡

sealer 的叢集高可用使用了輕量級的負載均衡 lvscare。相比其它負載均衡，lvscare 非常小僅有幾百行程式碼，而且 lvscare 只做 ipvs 規則的守護，本身不做負載非常穩定，直接在 node 上監聽 apiserver，如果跪了就移除對應的規則，重新起來之後會自動加回，相當於是一個專用的負載均衡器，在 sealos 專案中也用了兩年多，有廣泛的實踐。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/eff272ca0f514a5d8a03b66c9e5f32b3.png)

## 4. 執行時

執行時就是支撐應用執行的環境，像 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 中。

## 5. 基礎設施

現在很多使用者都希望在雲端執行自己的叢集映象，sealer 自帶對接公有云能力，sealer 自己實現的基礎設施管理器，得益於我們更精細的退避重試機制，30s 即可完成基礎設施構建（阿里雲 6 節點）效能是同類工具中的佼佼者，且 API 呼叫次數大大降低，配置相容 Clusterfile。

# 總結

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

- sealer 可以以極其簡單的方式讓使用者自定義叢集，解決分散式軟體製作者與使用者的協作問題。
- 極其簡單友好的 User Interface，能遮蔽和相容各種底層技術細節，到處執行。
- 生態建設，官方倉庫裡將會涵蓋常用的分散式軟體。

最後我們總結下：

- 如果你要整體交付你的分散式 SaaS，請用 sealer。
- 如果你要整合多個分散式服務在一起，如資料庫訊息佇列或者微服務執行時，請用 sealer。
- 如果你要安裝一個分散式應用如 mysql 主備叢集，請用 sealer。
- 如果你需要安裝/管理一個 Kubernetes 高可用叢集，請用 sealer。
- 如果你要初始化多個資料中心，保持多個資料中心狀態強一致，請用 sealer。
- 如果你需要在公有云上實現上述場景，請用 sealer。

sealer 將會在近期宣佈開源，有興趣的可以關注：[_https://github.com/alibaba/sealer_](https://github.com/alibaba/sealer)。

叢集映象：實現高效的分散式應用交付

相關文章