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

本文主要是介绍开发者故事：基于 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 配置本地隧道端口转发，来进行本地联调，具体如下：

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

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

apiVersion: extensions.kubesphere.io/v1alpha1
kind: APIService
metadata:
  name: v1alpha1.resource.lingbohome.com
spec:
  group: resource.lingbohome.com
  version: v1alpha1                                      
  url: http://10.0.16.3:7500
status:
  state: Available

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

    server {
        listen 7500 default backlog=8192;

        location / {
            proxy_pass http://127.0.0.1:5300/;
            client_max_body_size 2050m;
            proxy_buffer_size 128k;
            proxy_buffers 4 256k;
        }
    }

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

建议

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