开发者故事：基于 KubeSphere LuBan 架构打造下一代云交付平台 ...

前言

在 KubeSphere Marketplace，个人开发者的创意和才能正在逐渐崭露头角。今日，我们荣幸地向大家介绍 Shipper 云交付平台的开发者——凌波，一位云原生领域的资深专家。
凌波巧妙融合 KubeSphere 平台的特性，通过原生适配的精湛技艺，匠心独运地打造了 Shipper 平台。现在，让我们一同走进凌波的开发世界，聆听他在开发过程中的宝贵心得与独特领会。我们等候，凌波的故事能够激励更多开发者在 KubeSphere 平台上展现才华，共同推动云原生技术的创新与发展。
开发者简介

• 昵称：凌波（lingbohome）
  
• 邮箱：lingbo@lingbohome.com
  
• 博客: https://www.lingbohome.com/
  
• GitHub 主页：https://github.com/lingbohome
  
• 简介: 曾在 HIT 公司负责容器云平台设计研发及信创适配工作，对云原生相干领域技术怀有浓厚的兴趣，同时也会沉淀一些自己的思考和想法，有多年的云原生 devops 平台设计开发经验，K8s 容器云平台设计开发经验。
  

创作配景

云交付（Shipper），这一面向未来的云原生构建与交付平台，是我多年云原生 DevOps 经验与独到思考的结晶。它最初以 K8s 为基础，构建了一个功能强大的容器云平台。然而，当 KubeSphere v4 这一全新版本发布，其分布式云原生可扩展开放架构，尤其是 KubeSphere LuBan 架构所展现的云原生微内核与可热插拔扩展组件理念，瞬间吸引了我的注意。这一架构不仅与我在云原生领域的诸多思考不谋而合，更激发了我将理论付诸实践的强烈愿望。
在深入了解了 KubeSphere v4 后，我意识到，这不仅仅是一个堆砌功能的容器云平台，而是一个具有革命性意义的架构创新。因此，我决定将云交付（Shipper）以扩展组件的形式，适配到 KubeSphere LuBan 架构上，并通过 KubeSphere Marketplace，让更多用户能够轻松体验与使用它。
在适配过程中，我最初考虑采用 iframe 嵌入的方式，以节省开发时间。然而，在仔细研究了几个以 iframe 集成的组件后，我发现这种方式虽然简单，但扩展组件与 KubeSphere 主体之间的割裂感却非常明显，不利于后续的可持续迭代和推广。
为了追求更好的融合效果和用户沉醉式体验，我终极决定采用原生适配的方式，将云交付（Shipper）的设计基于 KubeSphere LuBan 架构重新开发。虽然这一决定意味着更大的工作量，但我相信，只有通过如许的方式，才能真正实现云交付（Shipper）与 KubeSphere 的完善融合，为用户带来更加出色的体验。在未来的日子里，我会持续迭代分多个版本完成适配，并不断改进和实现更好的想法和设计。
云交付（Shipper）简介

云交付（Shipper），是面向未来的云原生构建与交付平台，基于平台工程理念自助式、开箱即用的云原生 DevOps 平台，致力于让云原生应用的构建与交付，变得更简单、更高效，同时赋能产研、交付运维一体化高效协作，助力企业产品的业务价值快速高质量的交付给客户。
主要特性：

• 高度机动易用易扩展的构建器，开箱即用，无需任何配置
  
• 社区驱动共建丰富生态，共享可重用、功能多样性的模板
  
• 平台内置默认模板堆栈，由平台驱动维护，不定期更新和上线更多实用模板
  
• 高效协作，关注点分离，产研团队使用模板完成自己的需求，运维架构团队提供差别自定义模板功能的支持
  
• 支持触发器，轻松与第三方体系集成及构建器之间的联动，支持 cron 表达式定时执行
  
• 多类型成品管理，支持文本类型成品在线预览
  
• 基于平台工程理念的自服务式应用全生命周期管理，包括但不限于（版本化，发布，部署、运维，监控，打包交付），无需了解底层技术细节，即可轻松交付业务价值，减轻用户的使用负担
  
• 基于 KubeSphere 天生的多云多租户能力，团队之间资源隔离，互不干扰
  
• 管理端全局效能洞察看板，提供分析各维度效能度量数据、成本分析数据
  
• 支持面向 toB 行业的交付能力，办理 toB 产品交付痛点，降低 toB 产品交付成本
  
• 信创支持能力，助力企业高效高质量交付信创应用
  

搭建环境

我的开发环境搭建相对还是比较轻松的，因为在腾讯云上有一台测试用的单机 K8s 环境，直接通过官方文档中的 helmchart 下令一键部署了 KubeSphere，然后还需要在当地安装  create-ks-project
和  ksbuilder,分别用于初始化扩展组件前端工程目次和打包、发布扩展组件，后端扩展的话，就比较机动了，不需要安装 KubeSphere 特定的相干开发工具，我这里后端是以 APIService 和 crd 的形式扩展的，最后打包扩展组件的时候，将后端注册到相应的 APIService 中就可以了，其它的额外的开发工具，按照平常的开发需求，按需安装即可。
如果你也在寻找一个高效、便捷的开发环境搭建方案，那么我强烈推荐你试试 KubeSphere Cloud 的轻量级集群。它能够秒级拉起整个集群环境和 KubeSphere，让你轻松享受省时省力的开发体验。
开发过程

KubeSphere 的扩展组件开发跟平时的开发流程和方式没什么太大区别，只是前端按照 KubeSphere 提供的一套组件库（Kube Design）来开发，同时 KubeSphere 还提供了许多扩展组件开发示例，可以参考官方给的这个 extension-samples 这个代码堆栈，有了这些例子后，上手也就更快了，可以减轻不少开发负担。
前面提到，我的当地开发环境是连接的云上面的长途集群，这对当地前后端联调不是很友好，为了办理这个痛点，我这里使用了一个比较简单且不用额外工具的方案，大家可以视自己的实际环境参考：
通过 SSH 配置当地隧道端口转发，来进行当地联调，具体如下：

1. # 语法
2. ssh -NfR ${公网端口}:${本地地址}:${本地端口} ${公网服务器用户名}@${公网服务器地址}
3. # 示例
4. # 假设需要将本地localhost的5000端口映射到远程主机的5300端口,则使用下面的命令
5. ssh -NfR 5300:localhost:5000 user@10.13.0.6
6. # 然后就可以在远程服务器上通过127.0.0.1:5300访问到本地的localhost:5000后端服务了

复制代码

如许配置后还不够，还需要将你的后端服务通过 APIService 注册到 KubeSphere ，具体如下：

1. apiVersion: extensions.kubesphere.io/v1alpha1
2. kind: APIService
3. metadata:
4.   name: v1alpha1.resource.lingbohome.com
5. spec:
6.   group: resource.lingbohome.com
7.   version: v1alpha1                                      
8.   url: http://10.0.16.3:7500
9. status:
10.   state: Available  

复制代码

最后再长途主机上启动一个监听在 7500 端口的 nginx 服务，来反代到 127.0.0.1:5300。

1.     server {
2.         listen 7500 default backlog=8192;
4.         location / {
5.             proxy_pass http://127.0.0.1:5300/;
6.             client_max_body_size 2050m;
7.             proxy_buffer_size 128k;
8.             proxy_buffers 4 256k;
9.         }
10.     }  

复制代码

现在就可以通过 KubeSphere 控制台当地前端联调，访问到当地的 localhost:5000 后端了。
建议

前端扩展打包后，会在扩展组件源代码目次  extensions//dist  下会生成  index.js  文件，KubeSphere 提供了多种方式来托管index.js  文件，有 configmap、secret、service，因为打包后index.js  文件内容比较长且格式是紧凑的，将其存储到 configmap 和 secret 中，很容易因为格式题目导致错误，而且 index.js内容有更新时再次修改 configmap 或者 secret 也贫苦，所以这里强烈推荐使用 service 的方式，将其index.js  文件打包到容器镜像中，最后通过 deployment 部署起来，后续有更新改镜像 tag 或者覆盖之前的镜像就行了。
功能展示

后续完整的功能也在有序的推进中，下面展示了现在适配的部分功能：
云原生构建器：致力于让构建更简单、一切皆可构建为目的

构建器通过模板来执行具体的任务，模板可以独立维护和分发，当前内置了默认的模板堆栈，同时也会不定期更新和上线更多实用模板，现在堆栈内上线了两种实用模板：

• S2i：基于源码构建镜像，并推送到镜像堆栈，支持云原生多语言构建
  
• helmchart-generator：helmchart 包生成器，快速自动生成 helmchart package,并支持同时推送到 chart 的经典堆栈和 oci 堆栈
  

基于 S2i 的构建器

基于 S2i 模板创建一个构建器。

配置 S2i 模板的构建器参数，然后确认即可。

运行刚刚创建的构建器，也可以在这里运行前做一些参数的临时调整。

运行之后，可以查看构建器流水线实例执行日记。

流水线执行成功后，一般都会有产物，基于 S2i 模板的构建器产物就是 docker 镜像了，可以在成品页面查看。

基于 helmchart-generator 的构建器

基于 helmchart-generator 模板创建一个构建器。

配置 helmchart-generator 模板的构建器参数，helmchart-generator 模板提供了许多可选的参数，来满意你生成 helm chart 包，根据自己的需求配置即可。

后续的运行和查看日记的操作流程都是一样的，只不过最后执行成功后，生成的成品产物差别。
基于 helmchart-generator 模板的构建器生成的成品是 helm chart 包，切到成品页面查看，可以看到生成了两种类型的 helm chart 成品，然后 oss 类型成品是可以在线导出的。

基于 KubeSphere 内置的应用功能部署 helmchart

虽然构建器也可以做到 helmchart 的部署，但以为如许不太好，因此部署相干的功能是放在云原生交付模块去做的，那基于现在适配的功能，如何去实现部署，可以借助 KubeSphere 本身的功能。
前不久，给 KubeSphere 开源社区贡献了基于 OCI 的 Helm Chart 堆栈支持，在这里配合基于 helmchart-generator 模板的构建器使用再合适不过了。
起首在应用堆栈管理页面，添加基于 OCI 的 Helm Chart 堆栈，堆栈地址就是上面提到的生成的 oci 类型的 helmchart 成品的地址去掉 chart 基础名称就是堆栈地址了，这个堆栈地址其本质就是这个构建器所在 project 下面生成的所有 helmchart 成品地址。
后续这个 project 下面基于 helmchart-generator 模板的所有构建器生成的 oci 成品，都会自动同步到这个应用堆栈中。

应用堆栈配置完成后，就可以在内置的应用功能页面，选择应用堆栈中同步过来的 helmchart 进行部署了。

基于 helmchart-generator 模板生成的 helmchart 包，符合 helm 官方的最佳实践，会在包中生成 README.md使用说明文件，在这里可以得到表现。
最后

欢迎大家体验和使用，最后希望 KubeSphere 社区能更加繁荣热闹，我也会继续完善后续的功能适配，欢迎大家找我交流。
我们将持续分享更多开发者的故事，展示他们如何将对技术的热情转化为实际的产品，为社区带来价值。敬请关注，与我们一起见证 KubeSphere Marketplace 的成长和繁荣。

本文由博客一文多发平台 OpenWrite 发布！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。