共计 3587 个字符，预计需要花费 9 分钟才能阅读完成。
作者：政采云 | 汪勋
近年来，互联网极速倒退，为了跟进业务快速增长的倒退步调，新的技术如雨后春笋般一直的涌现，一眼望去，漫天星光，群星争艳。以容器为外围的云原生技术成长迅速，其中 Kubernetes 作为新的基础设施，容器编排事实上的规范，无疑是最夺目的那颗星。
然而，Kubernetes 尽管很好的解决了大规模利用部署，资源管理及调度的问题，然而其对业务交付并不敌对，Kubernetes 本身的部署也比较复杂，在不断涌现的围绕 Kubernetes 生态的利用中，始终短少了能够将业务、中间件、集群整合起来一体化交付的利用。
在当下，由阿里云智能云原生利用平台团队发动，政采云、谐云科技单干共建的 sealer 开源我的项目补充了 Kubernetes 在一体化交付畛域的短板，sealer 以十分优雅的设计方案思考了集群 + 分布式应用的整体交付。而政采云作为政府洽购行业的代表，已胜利的利用 sealer 实现了大型分布式应用的整体私有化交付，交付的实际充分证明了：sealer 具备灵便，弱小的一体化交付能力。
背景
政采云的私有化交付客户为政企场景，需交付业务规模较大：300+ 业务组件，20+ 中间件，交付指标的基础设施不同构且不可控，网络限度严格，一些敏感的场景甚至是齐全隔离的网络，在这种背景下，业务交付的最大痛点就是部署依赖的解决以及交付一致性的问题。尽管业务对立基于 Kubernetes 进行交付实现了运行环境的统一，然而如何解决部署过程中所依赖的所有镜像、各种包的对立解决以及交付零碎本身的一致性等一系列问题，亟需解决。
如上图所示政采云本地化交付的流程中，次要分为：用户需要确认 -> 提出资源需要给用户 -> 取得用户所提供的资源清单 -> 依据资源清单生成筹备配置 -> 筹备部署脚本及依赖 -> 理论交付六个步骤。前置筹备和理论交付时，须要耗费大量的人力和工夫来筹备和进行部署。
私有化交付的痛
云原生时代，docker 的呈现解决了单个利用的环境一致性和打包问题，业务的交付不再像传统的交付那样破费大量的工夫在部署环境依赖上。而后 Kubernetes 等容器编排零碎的呈现解决了对底层资源进行对立的调度，对利用运行时进行对立的编排的问题，然而一个简单的业务，其交付的自身就是一个工程浩大的问题，以政采云的场景为例：各种 helm chart、RBAC，istio gateway，cni，中间件等各种资源对象的部署和配置，再加上 300 余业务组件的交付，每一次私有化交付带来的都是大量人力和工夫老本的耗费。
政采云正处于业务高速倒退的期间，私有化部署我的项目的需要一直新增，高老本的交付形式越来越难以撑持理论的须要，如何升高交付老本，并保障交付的一致性是运维团队最迫切的须要解决的问题。
发现 sealer
在晚期，政采云应用 ansible 来进行业务的交付，ansible 计划实现了肯定水平的自动化并升高了交付老本然而存在如下几个问题：
1、ansible 只解决部署过程问题，须要独自筹备部署所需的依赖，依赖的筹备和可用性验证产生了额定的老本，且政采云的本地化场景根本都会严格限度内部网络。间接从外网获取依赖的形式也不可行。
2、应用 ansible 应答差异化的需要会十分累，政采云的私有化交付场景中，各个用户的需要不一，业务的依赖不一，每一次的交付从新编辑 ansible playbook 都要花费不少的工夫进行调试。
3、波及到简单的管制逻辑时，ansible 的申明语言比拟乏力。
4、部署交付之前须要先筹备 ansible 的运行环境。无奈做到交付的 0 依赖。
ansible 更多的是在做一些粘合的事件，更适宜逻辑比较简单的运维工作。随着本地化我的项目一直新增，ansible 交付的弊病开始浮现，每个本地化我的项目都须要大量的工夫投入，政采云运维团队开始摸索和思考交付体系的优化方向。咱们调研了很多的技术计划，然而已有的 Kubernetes 的交付工具都专一于集群自身的交付而不思考业务层交付。尽管能够基于集群部署工具进行封装，然而这种计划和应用 ansible 进行集群部署后再去部署下层业务并没有实质的区别。
比拟侥幸的是，咱们发现了 sealer 我的项目, sealer 是一套分布式应用打包交付的解决方案，通过把分布式应用及其依赖一起打包以解决简单利用的交付问题。其设计理念十分优雅，能够以容器镜像的生态来治理整个集群的打包交付。
在应用 Docker 的时候，咱们通过 Dockerfile 来定义单个利用的运行环境和打包，相应的，sealer 的技术原理能够通过类比 Docker 来进行解释，把整个集群当做一台机器，把 Kubernetes 定义为操作系统，通过 Kubefile 来定义这个 ” 操作系统 ” 外面的利用并最终打包成镜像，而后像 Docker run 交付单个利用一样，sealer run 就能够将整个集群及利用交付进来。
发现 sealer 的惊喜之余，咱们邀请了社区的搭档来公司进行了交换，sealer 还是一个新我的项目，年老到只诞生了几个月的工夫，在理论的体验中咱们遇到了不少问题，也踩了不少的坑，落地尝试时，也发现了挺多不满足需要的中央，然而咱们并没有放弃，因为咱们对 sealer 的设计模式抱有很大的冀望和信念，咱们抉择了与社区一起合作共建，独特成长。而最终胜利的落地实际也证实了，咱们的抉择十分正确！
社区合作
在决定与社区单干之初，咱们对 sealer 进行了全面的测试评估，联合咱们的需要场景，次要存在如下几个问题：
1、镜像缓存老本太高，最后 sealer 只提供 cloud build 的形式，即打包 sealer 集群镜像的前提是须要先基于云资源拉起一个集群，咱们认为这种形式老本太高，基于这个需要咱们提案并且奉献了 lite build 的构建形式，反对通过解析 helm、资源定义 yaml、镜像清单的形式解析镜像并间接缓存。lite build 是老本最低的 build 形式，无需拉起集群，只需一台要可能运行 sealer 的主机即可实现 build。
2、业务交付完之后，短少 check 机制，须要手工去查看 Kubernetes 集群的各个组件状态，而后，咱们奉献了集群及组件状态的 check 性能。
3、晚期 sealer 的一些配置是固化在 rootfs 中的，例如 registry 的部署主机是固定在第一个 master 节点上的，在理论的场景中咱们有自定义的需要，于是咱们奉献了自定义 registry 配置的性能。
4、基于 sealer 部署完集群后，还会有向集群中增加节点的需要，因而咱们奉献了 sealer join 的性能。
此外，还有必要说一下咱们落地时几个很实用，很弱小的 sealer 个性：
1、必须提到的一点是 sealer 构建产出的集群镜像齐全能够间接 push 到公有的 docker 镜像仓库例如 harbor 中。而后像 docker 镜像一样，能够基于已有镜像的根底上裁减性能并再次 build。
2、sealer 社区优化了 registry 和 docker，使其反对多源，多域名的代理缓存，这是一个十分实用的性能，在解决镜像依赖的时候，咱们缓存一个镜像须要变动镜像的地址，例如须要把一个公共镜像缓存到公有镜像中，对应的资源对象援用的镜像地址也须要同步变更为公有镜像仓库的地址，但 sealer 内置的 registry 通过优化实现了不须要批改镜像地址也能匹配缓存的性能。此外，sealer 中内置的 registry 作为 proxy 时，能够代理多个私有化的镜像仓库，在具备多个公有仓库的场景中，是很实用的性能。
落地实际
应用 sealer 咱们从新定义了交付流程，通过 Kubefile 将业务组件、容器化中间件的交付、镜像缓存等组件的交付间接应用 sealer 来实现。利用 sealer lite build 模式，自动化的实现依赖镜像的解析及缓存内置。
利用 sealer 屏蔽了大量利用交付的简单过程逻辑，和依赖解决逻辑，使施行难度极大的简化。施行逻辑的继续简化，使得规模化交付成为可能。在咱们的实际场景中，应用新的交付零碎，交付周期从 15 天 / 人缩短至 2 天 / 人，实现了蕴含 20G 业务镜像缓存，2000G+ 内存 800+ 外围 CPU 规模集群的胜利交付。下一步咱们打算通过继续的简化交付过程，使一个老手只须要简略的培训即可实现整个我的项目的交付。
将来瞻望
落地的胜利，播种的不仅仅是交付零碎的成绩，更体现了开源的力量，摸索出了与社区单干共建的新模式。在将来，政采云将持续反对并参加 sealer 社区的建设，结合实际的业务场景，为社区提供更多的奉献。
作为一个新的开源我的项目，sealer 的当初并不完满，还存在一些待解决和优化的问题，还有更多的需要和业务场景期待咱们去实现，心愿通过继续的奉献，让 sealer 能够服务于更多的用户场景，同时也心愿有更多的合作伙伴可能参加社区建设，让 sealer 这颗星，更加的璀璨夺目！
kubernetes 一键装置
sealer 集群整体打包！