集群镜像-集群总体打包,分布式应用build share run

做者 | fanux.中弈node

什么是集群镜像

顾名思义和操做系统.iso镜像或者Docker镜像相似,集群镜像是用必定的技术手段把整个集群的全部文件以必定格式打成的一个资源包

对比单机和集群会发现一些有趣现象:mysql

  • 单机有计算存储网络这些驱动,集群有CNI/CSI/CRI的实现像是集群的驱动
  • 操做系统单机有ubuntu centos这些,咱们能够把kubernetes当作云操做系统
  • 单机上能够运行docker容器 或者是虚拟机,至关于一个运行的实例,集群也有运行着k8s的实例
  • 单机上的虚拟机镜像,docker镜像,因此随着云计算技术的发展,在集群这个纬度也会抽象出相似的镜像技术。

以基于kubernetes的集群镜像为例,里面包含了除操做系统之外的全部文件:git

  • docker的依赖的二进制与systemd配置,dockerd的配置,以及一个私有的容器镜像仓库
  • kubernetes核心组件二进制,容器镜像,kubelet system配置等
  • 应用须要用到的yaml配置或者helm chart,以及应用的容器镜像
  • 其它脚本,配置与二进制工具等应用运行须要的全部依赖

一样集群镜像运行时确定不是起一个容器或者装在一台机器上,而是这个镜像能够直接安装到多台服务器上或者直接对接到公有云的基础设施上。github

sealer介绍

sealer是阿里巴巴开源的集群镜像的一个实现方式,项目地址: https://github.com/alibaba/se...
Docker解决了单个容器的镜像化问题,而sealer经过把整个集群打包,实现了分布式软件的Build Share Run!!!
golang

试想咱们要去交付一个SaaS应用,它依赖了mysql es redis这些数据库和中间件,全部东西都在kubernetes上进行编排,那若是没有集群镜像那要作以下操做:redis

  1. 找个工具去安装k8s集群
  2. helm install mysql es redis... 若是是离线环境可能还须要导入容器镜像
  3. kubectl apply yoursaas

看似好像也没那么复杂,可是其实从整个项目交付的角度来讲是面向过程极易出错的
sql

那如今若是如今提供另一个方式只要一条命令解决上面的问题你会不会用?
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启动整个集群。docker

快速体验

制做和运行一个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 .
ubuntu

运行集群镜像

# 下面命令会在服务器上安装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...
image.png