叢集映象介紹

叢集映象是一個巨大的創新，把單機上的虛擬機器映象或者單個容器映象抽象到了叢集維度，未來

大部分軟體都是分散式的，所以叢集緯度的映象可以更好的保障分散式應用整體使用的一致性。

阿里巴巴sealer就是一個非常優秀的實現，把k8s看成

作業系統給分散式應用製作映象，比如docker只能給你製作單個mysql的映象，而sealer可以幫助

你製作整個mysql高可用叢集的映象。

背景介紹

應用視角的計算機或者是雲的發展歷程就是一個不斷遮蔽底層細節的過程，讓使用者只需要關心他應該關心的層面，遮蔽到哪一層取決於軟體工作在哪一層。 舉個例子：我想實現一個檔案瀏覽器，檢視系統中檔案目錄，那我僅需要關心繫統呼叫而不用關心核心怎麼實現，因為作業系統幫助我們很好的做了遮蔽。

然而並不在所有領域都像作業系統那樣把我們不需要關心的細節都遮蔽的很好，比如應用依賴一個數據庫，傳統一點的方式，我們需要去在作業系統上安裝啟動資料庫，每種作業系統上方式還不一樣，其實應用想要的是資料庫而卻要關心這樣一個不友好的實現過程。 好在有一些優化方案，比如製作虛擬機器映象，這樣只要有一個帶資料庫的虛擬機器映象啟動就可以滿足應用的需求了，應用不再關心資料庫下面的作業系統是什麼，同理Docker也實現一樣的能力。

但是假如應用依賴一個分散式資料庫，對於分散式的軟體，現有的方式幾乎都顯得力不從心(雲服務除外)。虛擬機器映象解決不了分散式軟體的開箱即用問題，雲原生社群的人可能會說用kubernetes+helm，說的不錯但是要知道一個現實是數千萬開發者有多少是瞭解這些複雜技術的,更多的可能只是聽過名詞，應用想要的是一個分散式資料庫，顯然再關心下面一層的內容就是沒有遮蔽好底層的細節。

叢集映象就可以從頂層使用者的視角把整個叢集的能力封裝到恰到好處

• 比如你想去使用一SaaS軟體，有了叢集映象你只需要run xxxSaaS才不需要關心它依賴了什麼資料庫用了什麼訊息佇列。
• 比如你想要一個分散式的mysql，有了叢集映象只需要run mysql-cluster,完全不用關心資料庫是不是跑在容器中，kubernetes單詞都不會拼寫都沒關係。
• 比如你想起一個kubernetes叢集，有了叢集映象只需要run kubernetes,也完全不用關心叢集是跑在哪種作業系統上

如此做到你想關注哪一層就封裝遮蔽到哪一層，叢集映象給你想要的結果而隱藏掉複雜的中間過程。熟悉Docker的同學一定有這樣的感覺，我們現在run一個mysql的容器很少關心是from centos還是utuntu了，那未來基於叢集映象的能力我們去run一個分散式應用也不用關心它底層的雲作業系統是什麼了。

本文聊一下叢集映象裡面配置應該如何進行管理。

kubernetes中的配置管理

大家都知道configmap中可以放使用者自定義的一些配置檔案，如果編排檔案比較多的時候，實際生產我們

又只關心少量的引數，我們就可以通過helm這類工具把少量引數抽到values裡面，在執行的時候只需要

關注values裡面的少量引數就可以。

叢集映象配置管理

難點在於叢集映象是一個黑盒，那不可能說需要改個引數還得重新構建一下叢集映象，所以sealer巧妙利用overwrite的特性解決這一問題。

Clusterfile檔案類似compose，是告訴你如何啟動整個叢集的，裡面包含一些重要資訊，比如使用的叢集

映象是什麼，節點IP列表是什麼等等。還有一部分就是用來定義覆蓋映象內部引數的一部分了：

apiVersion: sealer.aliyun.com/v1alpha1
kind: Cluster
metadata:
  name: my-cluster
spec:
  image: registry.cn-qingdao.aliyuncs.com/sealer-app/my-SAAS-all-inone:latest
  provider: BAREMETAL
---
apiVersion: sealer.aliyun.com/v1alpha1
kind: Config
metadata:
  name: mysql-config
spec:
  path: etc/mysql-valus.yaml
  data: |
       mysql-user: root
       mysql-passwd: xxx
...
---
apiVersion: sealer.aliyun.com/v1alpha1
kind: Config
metadata:
  name: redis-config
spec:
  path: etc/redis-valus.yaml
  data: |
       redis-user: root
       redis-passwd: xxx
...

如上，Config物件定義了檔名和檔案內容，這樣就可以覆蓋掉叢集映象裡面的預設配置。

sealer只做簡單的覆蓋，而不關心你的使用什麼編排工具編排的，甚至是docker 的deamon.json

配置都可以通過這種方式配置，就非常的解耦和靈活。

構建映象使用該配置：

FROM kuberentes:v1.19.9
...
CMD helm install mysql -f etc/mysql-config.yaml
CMD helm install mysql -f etc/redis-config.yaml

即可，這樣sealer起起來的叢集就可以注入應用的配置了。

少量配置

當然如果是少量配置可以通過“叢集環境變數”的方式注入。

如我需要配置叢集中dashboard的監聽埠號,可以這樣寫你的編排檔案：

...
kind: Service
apiVersion: v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kubernetes-dashboard
spec:
  ports:
    - port: 443
      targetPort: {{ DashBoardPort }}
  selector:
    k8s-app: kubernetes-dashboard
...

然後構建你的叢集映象，把這個模板檔案拷貝到叢集映象中：

FROM kubernetes:1.16.9
COPY dashobard.yaml manifests/
CMD kubectl apply -f manifests/dashobard.yaml

執行時通過環境變數指定具體埠號：

sealer run -e DashBoardPort=8443 mydashboard:latest

也可以通過Clusterfile指定：

apiVersion: sealer.aliyun.com/v1alpha1
kind: Cluster
metadata:
  name: my-cluster
spec:
  image: mydashobard:latest
  provider: BAREMETAL
  env:
    DashBoardPort: 6443 # Specify a custom port here, which will be rendered into the mirrored yaml
  ssh:
    passwd:
    pk: xxx
...

總結

sealer 的配置管理部分的實現非常簡單優雅，而且能滿足大部分場景的需求，這樣我們把不經常變更的東西打到叢集映象裡面，把經常變更的東西通過Config物件注入檔案。

特別一個saas應用通常有非常多的依賴，我們就可以把這些依賴的k8s docker 中介軟體 資料庫和saas本身都 打到叢集映象裡，把啟動整個叢集需要的少量引數暴露出來，就能幫助我們快速的複製叢集。

這樣玩專有云交付那都是小時級分鐘級交付，大大提升企業的競爭力。

企業在多機房部署時也一樣，構建一次，其它地方就可以快速批量複製，保障整個叢集的一致性。

哪怕你只是想裝一個k8s或者一個高可用mysql，都可以用sealer，因為映象打包什麼內容完全是由 Build的人決定的，我們也會構建好很多通用映象供使用者直接使用。 kubernetes一鍵安裝

sealer叢集整體打包！