作者：赵海亮，浙江大学计算机专业四年级在读博士生，钻研方向为云计算、边缘计算、分布式系统等。
尽管 KubeSphere 可能将咱们从 yaml 文件的编写中解放出来，然而我的项目上云依然非常繁琐。 此外，一旦我的项目源代码产生更替（如公布新性能或去除 bug 等），所有组件都须要从新经验 “源码打包 --> 制作镜像 --> 启动容器” 这个流程。 这意味着，我的项目运维人员不得不从事大量重复性劳动。为了进步我的项目公布的效率，工业界引入了 DevOps 的概念。
本文首先将介绍 DevOps 是什么，随后尝试利用 KubeSphere 集成的性能来实现 DevOps。
什么是 DevOps
目前绝大多数互联网公司将开发和系统管理划分成不同的部门。 开发部门的驱动力通常是 “频繁交付新个性”，而运维部门则更关注 IT 服务的可靠性和 IT 老本投入的效率。 两者指标的不匹配，因此存在鸿沟，从而减慢了 IT 交付业务价值的速度。 为了解决这个问题，DevOps（Development 和 Operations 的组合词）被提出。 DevOps 的目标是在企业外部搭建一个自动化 “软件交付” 和“架构变更”的流程，来使得构建、测试、公布软件可能更加地快捷、频繁和牢靠。
实现 DevOps 通常须要多个软件和工具的密切配合。 如图 1 所示，DevOps 将软件的交付流程顺次划分为 Plan、Code、Build、Test、Release、Deploy、Operate 以及 Monitor 这些阶段。 当需要变更时，将会从 Monitor 从新平滑过渡至 Plan 阶段。每个阶段都有一系列的软件和工具可供选择。 对于任意我的项目，咱们只须要基于这些软件和工具 搭建一条自动化流水线 ，再设置相似于 “一旦代码变更就主动执行” 这样的钩子函数，整个我的项目即可主动实现“继续集成 / 继续交付（CI/CD）”，这将大大减少重复劳动。
KubeSphere DevOps 基于 Kubernetes Jenkins Agent 实现。 和传统的 Jenkins Controller-Agent 架构不同的是，在 KubeSphere 中，Jenkins Agent 能够动静扩缩容，从而升高 CI/CD 对集群资源的自觉占用。 KubeSphere 的 DevOps 用户指南参见 https://kubesphere.io/zh/docs...。 本文将按照该指南将一个开源我的项目上云。
基于 DevOps 的我的项目部署
我的项目介绍
本次试验要部署的我的项目叫做尚医通，这是一个基于 Spring-Boot 实现的预约挂号对立平台。 该我的项目一共蕴含三个子局部，别离为 yygh-parent、yygh-site 和 yygh-admin。 在架构上，该我的项目依赖的数据层中间件有 mysql、redis、mongodb 以及 rabbitmq，依赖的流量治理中间件有 sentinel 和 nacos。
接下来，咱们约定我的项目根目录为 his，而后别离从开源地址 https://gitee.com/leifengyang...、https://gitee.com/leifengyang... 和 https://gitee.com/leifengyang... 拉取源代码：
(base) ➜ his lsatotal 0drwxr-xr-x 5 hliangzhao staff 160B Nov 15 10:33 .[email protected] 42 hliangzhao staff 1.3K Nov 15 10:33 ..drwxr-xr-x 24 hliangzhao staff 768B Nov 15 10:33 yygh-admindrwxr-xr-x 15 hliangzhao staff 480B Nov 15 10:33 yygh-parentdrwxr-xr-x 24 hliangzhao staff 768B Nov 15 10:34 yygh-site顺次查看三个我的项目的文件布局：
(base) ➜ his cd yygh-parent(base) ➜ yygh-parent git:(master) tree -L 2.├── common # 通用模块│ ├── common-util│ ├── pom.xml│ ├── rabbit-util│ └── service-util├── data # 我的项目演示数据│ ├── json│ └── sql├── hospital-manage # 医院后盾│ ├── Dockerfile│ ├── deploy│ ├── pom.xml│ ├── src├── model # 数据模型│ ├── pom.xml│ └── src├── pom.xml├── server-gateway # 网关│ ├── Dockerfile│ ├── deploy│ ├── pom.xml│ └── src├── service # 微服务层│ ├── pom.xml│ ├── service-cmn # 公共服务│ ├── service-hosp # 医院数据服务│ ├── service-order # 预约下单服务│ ├── service-oss # 对象存储服务│ ├── service-sms # 短信服务│ ├── service-statistics # 统计服务│ ├── service-task # 定时服务│ └── service-user # 会员服务└── service-client ├── pom.xml ├── service-cmn-client ├── service-hosp-client ├── service-order-client └── service-user-client30 directories, 12 files(base) ➜ yygh-parent git:(master) cd ../yygh-admin(base) ➜ yygh-admin git:(master) tree -L 1 # 医院挂号后盾（前端 UI）.├── Dockerfile├── LICENSE├── build├── config├── deploy├── favicon.ico├── index.html├── package.json├── src└── static5 directories, 9 files(base) ➜ yygh-site git:(master) tree -L 1 # 用户挂号前台（前端 UI）.├── Dockerfile├── api├── assets├── components├── deploy├── layouts├── middleware├── nuxt.config.js├── package-lock.json├── package.json├── pages├── plugins├── static├── store└── utils11 directories, 7 files对于本我的项目，咱们须要部署如下内容：
yygh-parent/hospital-manage # 医院治理yygh-parent/server-gateway # 网关# 8 个微服务yygh-parent/service/service-cmnyygh-parent/service/service-hospyygh-parent/service/service-orderyygh-parent/service/service-ossyygh-parent/service/service-smsyygh-parent/service/service-statisticsyygh-parent/service/service-taskyygh-parent/service/service-user# 2 个前端yygh-adminyygh-site以上 12 个待部署的子项目将以独立 Pod 的模式在集群中部署。 每一个子项目根目录须要具备一个 Dockerfile 文件以及一个名为 deploy 的文件夹。 前者是本子我的项目的镜像制作文件，后者是本子我的项目的资源清单文件 *.yaml（用于在集群中部署）。 以 service-cmn 为例，其文件布局如下：
(base) ➜ service-cmn git:(master) tree -L 2.├── Dockerfile # 将本子我的项目构建为镜像的 Dockerfile├── deploy # 寄存用于部署本子我的项目的资源清单文件│ └── deploy.yml├── pom.xml # 我的项目依赖├── src # 源代码│ └── main└── target # maven 打包后主动创立遵循上的一篇文章 应用 KubeSphere 部署 Ruoyi-Cloud · KS 实际 02 中所述的部署流程，咱们首先须要将中间件上云。而后，咱们将三个我的项目以流水线的形式上云。
部署中间件
本我的项目所应用的中间件除了 Sentinel 和 MongoDB，其余均已在前文中部署。 接下里顺次部署这两个中间件。
对于 Sentinel，咱们间接应用雷丰阳曾经制作好的镜像 leifengyang/sentinel:1.8.2，而后裸露一个 NodePort 类型的 Service，端口号为 32636。 拜访 http://192.168.23.160:32636，以默认用户 sentinel 和默认明码 sentinel 登录，能够进入 Sentinel 控制台。 如果一切顺利，应该能够看到相似的页面：
对于 MongoDB，咱们间接通过利用模版部署它（不勾选登录认证）：
为 MongoDB 利用裸露一个 NodePort 类型的 Service，端口号为 31801，而后在本机通过 MongoDB Compass 连贯它（192.168.23.160:31801）：
如果能够连上，则一切正常。
导入初始数据
应用 DataGrip 将位于 his/yygh-parent/data/sql 目录下的全副演示数据（一共有 5 个 sql 文件须要执行，会创立 5 个 yygh 打头的数据库）导入集群中的 MySQL 实例：
MongoDB 的演示数据将在我的项目启动后导入。
在 Nacos 中创立微服务的启动配置
察看每一个子项目的 Dockerfile，以 service-cmn 为例：
# service-cmn 的 DockerfileFROM openjdk:8-jdkLABEL maintainer=leifengyang# 启动 prod 环境，以 service-cmn-prod.yml 作为启动配置ENV PARAMS="--server.port=8080 --spring.profiles.active=prod --spring.cloud.nacos.server-addr=his-nacos.his:8848 --spring.cloud.nacos.config.file-extension=yml"RUN /bin/cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && echo 'Asia/Shanghai' >/etc/timezoneCOPY target/*.jar /app.jarEXPOSE 8080ENTRYPOINT ["/bin/sh","-c","java -Dfile.encoding=utf8 -Djava.security.egd=file:/dev/./urandom -jar /app.jar ${PARAMS}"]这意味着该子项目在启动时，会激活 prod 环境，并从 Nacos 中读取 service-cmn-prod.yml 文件作为启动配置。 因而，咱们首先须要在 Nacos 中创立其生产环境配置文件 service-cmn-prod.yml，而后将 子项目门路 / src/main/resources/application-dev.yml 的内容复制进去，在其根底上批改。 须要批改的内容次要是中间件的拜访地址。 以 service-cmn 为例，它的配置文件被命名为 service-cmn-prod.yml，其最终内容如下：
# service-cmn-prod.ymlserver: port: 8080mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl mapper-locations: classpath:mapper/*.xml global-config: db-config: logic-delete-value: 1 logic-not-delete-value: 0spring: cloud: sentinel: transport: # 批改 sentinel 拜访地址 dashboard: http://his-sentinel-nodeport.his:8080 redis: # 批改 redis 拜访地址 host: his-redis-nodeport.his port: 6379 database: 0 timeout: 1800000 password: lettuce: pool: max-active: 20 # 最大连接数 max-wait: -1 # 最大阻塞等待时间 (正数示意没限度) max-idle: 5 # 最大闲暇 min-idle: 0 # 最小闲暇 datasource: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.jdbc.Driver # 批改 mysql 拜访地址和连贯凭证 url: jdbc:mysql://his-mysql-nodeport.his:3306/yygh_cmn?characterEncoding=utf-8&useSSL=false username: root password: 123456 hikari: connection-test-query: SELECT 1 connection-timeout: 60000 idle-timeout: 500000 max-lifetime: 540000 maximum-pool-size: 12 minimum-idle: 10 pool-name: GuliHikariPool jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8如图 6 所示，除了 hospitla-manage，其余所有 9 个 Spring-Boot 子项目均须要依照上述规定编写对应的配置文件。 hospitla-manage 的启动不依赖 Nacos，因而不须要。
创立微服务部署流水线
流水线示意利用从代码编译、测试、打包和部署的过程，KubeSphere 的流水线治理应用了业界罕用的 Jenkinsfile 来表述一组 CI/CD 流程。 Jenkinsfile 是一个文本文件，应用了 Jenkins 提供的 DSL（Domain-Specific Language）语法。 KubeSphere 提供了可视化编辑器，用户只需在页面上输出大量配置信息，接口主动组装实现 Jenkinsfile。 当然，也可间接编辑 Jenkinsfile。
流水线波及如下几个概念：
- Stage：阶段，一个 Pipeline 能够划分为若干个 Stage，每个 Stage 代表一组操作。Stage 是一个逻辑分组的概念，能够跨多个 Node。
- Node：节点，一个 Node 就是一个 Jenkins 节点，或者是 Master，或者是 Agent，是执行 Step 的具体运行时环境。
- Step：步骤，Step 是最根本的操作单元，小到创立一个目录，大到构建一个 Docker 镜像，由各类 Jenkins Plugin 提供。
KubeSphere 默认提供的 Agent 有 base、go、maven 和 nodejs。它们别离实用于不同编程语言开发的我的项目的打包构建。 因为咱们行将部署的 10 个子我的项目均是 Spring-Boot 利用，因而咱们抉择 maven 作为启动流水线的 agent。
咱们能够间接编写流水线的 Jenkinsfile，也能够通过 KubeSphere 提供的可视化页面编辑流水线。 通常，流水线的第一步是下载我的项目源代码 4，咱们在 UI 上间接增加相干命令：
KubeSphere 会主动生成这次编辑的 Jenkinsfile 代码片段：
stage('clone code') { agent none steps { // 拉取代码并展现代码文件布局 container('maven') { git(url: 'https://gitee.com/leifengyang/yygh-parent', branch: 'master', changelog: true, poll: false) sh 'ls -al' } }}流水线的第二个阶段通常是我的项目的打包与编译。 默认状况下，Maven 从官网仓库下载我的项目依赖，如果想要批改默认镜像仓库，须要批改集群中名为 ks-devops-agent 的 ConfigMap，它领有一个叫做 MavenSetting 的键：
[email protected]:~$ k get cm -A | grep devopshis-devopsqxxv7 istio-ca-root-cert 1 24hhis-devopsqxxv7 kube-root-ca.crt 1 24hkubesphere-devops-system devops-config 1 5d7hkubesphere-devops-system devops-jenkins 9 5d7hkubesphere-devops-system istio-ca-root-cert 1 5d7hkubesphere-devops-system jenkins-agent-config 1 5d7hkubesphere-devops-system jenkins-casc-config 2 5d7hkubesphere-devops-system kube-root-ca.crt 1 5d7hkubesphere-devops-worker istio-ca-root-cert 1 5d7hkubesphere-devops-worker ks-devops-agent 1 5d7hkubesphere-devops-worker kube-root-ca.crt 1 5d7h[email protected]:~$ k describe cm ks-devops-agent -n kubesphere-devops-workerName: ks-devops-agentNamespace: kubesphere-devops-workerLabels: app.kubernetes.io/managed-by=HelmAnnotations: meta.helm.sh/release-name: devops meta.helm.sh/release-namespace: kubesphere-devops-systemData====MavenSetting:----<?xml version="1.0" encoding="UTF-8"?>...<!-- | This is the configuration file for Maven. It can be specified at two levels:...<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">...咱们须要批改 MavenSetting 文件，在其中增加国内镜像仓库地址：
咱们通过命令 mvn clean package -Dmaven.test.skip=true 进行我的项目打包编译。由此，流水线的第二阶段须要执行的命令如下：
相应地，在 Jenkinsfile 中也会主动生成第二步的代码：
stage('project compilation') { agent none steps { container('maven') { sh 'mvn clean package -Dmaven.test.skip=true' } }}流水线的第三个阶段是制作镜像。咱们在章节 2.1 说过，每个子项目的根目录有一个 Dockerfile，并且在章节 2.4 展现过 Dockerfile 的内容。 因而，对于单体利用 hospitla-manage，它的镜像构建命令为 docker build -t hospital-manage -f hospital-manage/Dockerfile hospital-manage/；对于网关子项目 server-gateway，它的镜像构建命令为 docker build -t server-gateway/Dockerfile server-gateway/；其余 8 个微服务的构建命令则是 docker build -t service/service-xxx service/service-xxx/。这里的 xxx 被替换为具体的微服务名称。 在上述构建命令中，尤其须要留神的是 Dockerfile 绝对于我的项目根目录 yygh-parent 所在的地位以及镜像构建上下文的绝对地位。
因为上述 10 个镜像的构建相互之间独立，因而能够并行化执行。咱们能够很轻易地在 KubeSphere 中做到这一点：
相应地，Jenkinsfile 中减少了如下内容：
stage('default-2') { parallel { // 并行构建 10 个镜像 stage('build hospital-manage') { agent none steps { container('maven') { sh 'docker build -t hospital-manage -f hospital-manage/Dockerfile hospital-manage/' } } } stage('build server-gateway') { ... } stage('build service-cmn') { ... } ... }}流水线的第四个阶段是镜像推送。在企业外部，构建好的镜像通常会被推送到企业的公有仓库中。 笔者采纳阿里云给集体开发者收费提供的镜像仓库作为推送指标。因为指标仓库是一个公有仓库，因而须要提供账户和明码作为凭证（credential）。 如何在 KubeSphere 中为镜像推送命令提供凭证呢？ 咱们能够在 DevOps 的我的项目设置中创立：
上图中，笔者创立一个名为 aliyun-docker-hub 的凭证，用户名是我的阿里云账户名，明码则是申请容器镜像服务所创立的明码。 读者须要替换成本人的账户明码：
基于该凭证，咱们在 Jenkinsfile 中编写镜像推送的代码如下：
steps { container('maven') { // 应用'aliyun-docker-registry'这个凭证登录公有仓库并将镜像推送至其中 withCredentials([usernamePassword(credentialsId: 'aliyun-docker-registry', passwordVariable: 'ALIYUN_REG_PWD', usernameVariable : 'ALIYUN_REG_USER' ,)]) { sh 'echo"$ALIYUN_REG_PWD"| docker login $REGISTRY -u"$ALIYUN_REG_USER"--password-stdin' sh 'docker tag hospital-manage:latest $REGISTRY/$DOCKERHUB_NAMESPACE/hospital-manage:SNAPSHOT-$BUILD_NUMBER' sh 'docker push $REGISTRY/$DOCKERHUB_NAMESPACE/hospital-manage:SNAPSHOT-$BUILD_NUMBER' } }}...environment { ... REGISTRY = 'registry.cn-hangzhou.aliyuncs.com' DOCKERHUB_NAMESPACE = 'hliangzhao-private' ...}同样地，上述过程也以并行的形式执行。最终，Jenkinsfile 中被增加了如下代码：
stage('default-3') { parallel { // 并行推送 10 个镜像 stage('push hospital-manage') { agent none steps { container('maven') { withCredentials([usernamePassword(credentialsId : 'aliyun-docker-registry' ,passwordVariable : 'ALIYUN_REG_PWD' ,usernameVariable : 'ALIYUN_REG_USER' ,)]) { sh 'echo"$ALIYUN_REG_PWD"| docker login $REGISTRY -u"$ALIYUN_REG_USER"--password-stdin' sh 'docker tag hospital-manage:latest $REGISTRY/$DOCKERHUB_NAMESPACE/hospital-manage:SNAPSHOT-$BUILD_NUMBER' sh 'docker push $REGISTRY/$DOCKERHUB_NAMESPACE/hospital-manage:SNAPSHOT-$BUILD_NUMBER' } } } } stage('push server-gateway') { ... } stage('push service-cmn') { ... } ... }}测试一下到目前为止的流水线，所有运行顺利：
流水线的最初阶段是部署到开发环境和生产环境。因为这一阶段须要和 Kubernetes API Server 打交道，所以须要指定 Kubernetes 上下文 5。 KubeSphere 主动为咱们创立了名为 demo-kubeconfig 的凭证，该凭证提供了形如 .kube/config 的文件，使得咱们能够依据凭证发动 kubectl apply 命令。 与此同时，咱们还须要指定待部署的资源清单文件的地位。 以子项目 hospital-manage 为例，它的资源清单文件在 yygh-parent/hospital-manage/deploy/ 目录下。 察看该目录下的 deploy.yaml 文件，能够发现它要求集群从阿里云公有镜像仓库拉取镜像，须要咱们提供 imagePullSecrets 字段：
这意味着咱们须要在 his 我的项目中创立名为 aliyun-docker-hub 的 Secret。 留神，这里是在为 his 我的项目创立 Secret，而先前是在 DevOps 的我的项目设置中创立 Credential。二者的服务对象是不同的。 对于部署这个操作，咱们能够间接在 UI 上抉择 “增加 kubernetesDeploy”：
由此生成的 Jenkinsfile 代码为
stage('deploy hospital-manage to dev') { agent none steps { container('maven') { kubernetesDeploy(enableConfigSubstitution: true, deleteResource: false, kubeconfigId: 'demo-kubeconfig', // 存储了 kubeconfig 上下文信息的文件 configs: 'hospital-manage/deploy/**' // 资源清单文件所在位置 ) } }}咱们尝试运行一下当初的流水线，诡异的事件却产生了。在我的项目部署阶段产生了如下谬误：
Starting Kubernetes deploymentLoading configuration: /home/jenkins/agent/workspace/his-devopsqxxv7/yygh-parent-devops/hospital-manage/deploy/deploy.ymlERROR: ERROR: java.lang.RuntimeException: io.kubernetes.client.openapi.ApiException: Bad Requesthudson.remoting.ProxyException: java.lang.RuntimeException: io.kubernetes.client.openapi.ApiException: Bad Request at com.microsoft.jenkins.kubernetes.wrapper.ResourceManager.handleApiExceptionExceptNotFound(ResourceManager.java:180) ...Api call failed with code 400, detailed message: { "kind": "Status", "apiVersion": "v1", "metadata": { }, "status": "Failure", "message": "the export parameter, deprecated since v1.14, is no longer supported", "reason": "BadRequest", "code": 400}Kubernetes deployment ended with HasError观察报错内容，仿佛是负责执行流水线的 Jenkins Agent 版本太老所导致的。 通过查阅，笔者发现 KubeSphere 的官网保护人员曾经提交了相干 issue（https://github.com/kubesphere...）来阐明此事。依据阐明，报错的本源在于 Jenkins 的官网插件 kubernetes-cd-plugin “年久失修”，我所装置的 Kubernetes 的 API 版本是 v1.22，而 Jenkins 的 kubernetes-cd-plugin 却曾经停摆两年。 对于这个问题，KubeSphere 官网提供的解决方案是以 shell 命令 kubectl apply -f your-crd-file.yaml 的形式进行部署，而非在 UI 上增加 kubernetesDeploy。
侥幸的是，在笔者撰写此文的 40 分钟前，KubeSphere 官网发动了一个针对此问题的长期解决方案：https://github.com/kubesphere...。 在该 Pull request 中，贡献者提供了一种提供 kubeconfig 验证的写法：
stage('deploy hospital-manage to dev') { agent none steps { container('maven') { // 如果不提供 kubeconfigFile，则 kubectl 上下文找不到 withCredentials([kubeconfigFile(credentialsId: env.KUBECONFIG_CREDENTIAL_ID, variable: 'KUBECONFIG')]) { sh 'kubectl apply -f hospital-manage/deploy/**' } } }}试验证实，该办法无效。同样地，10 个子我的项目能够并行化部署到 dev 环境。相应的 Jenkins 代码就不再展现了。 部署到 prod 环境的操作相似。此外，还能够增加部署条件，例如，只有取得相干管理员受权之后部署操作才会启动。
创立前端我的项目部署流水线
接下来，还剩两个前端我的项目 yygh-site 和 yygh-admin 须要部署。 前端我的项目的部署遵从类似的步骤：首先下载源码，而后须要通过 Node.js 之类的工具为我的项目装置依赖并构建（产生 dist 目录），最初是镜像构建、推送和部署。 以 yygh-site 为例，它最终的 Jenkinsfile 如下所示：
pipeline { agent { node { label 'nodejs' } } stages { stage('拉取代码') { agent none steps { container('nodejs') { git(url: 'https://gitee.com/leifengyang/yygh-site', branch: 'master', changelog: true, poll: false) sh 'ls -al' } } } stage('我的项目编译') { agent none steps { container('nodejs') { sh 'ls' sh 'npm install --registry=https://registry.npm.taobao.org' sh 'npm run build' } } } stage('构建镜像') { agent none steps { container('nodejs') { sh 'ls' sh 'docker build -t yygh-site:latest -f Dockerfile .' } } } stage('推送镜像') { agent none steps { container('nodejs') { withCredentials([usernamePassword(credentialsId: 'aliyun-docker-registry', usernameVariable: 'DOCKER_USER_VAR', passwordVariable: 'DOCKER_PWD_VAR',)]) { sh 'echo"$DOCKER_PWD_VAR"| docker login $REGISTRY -u"$DOCKER_USER_VAR"--password-stdin' sh 'docker tag yygh-site:latest $REGISTRY/$DOCKERHUB_NAMESPACE/yygh-site:SNAPSHOT-$BUILD_NUMBER' sh 'docker push $REGISTRY/$DOCKERHUB_NAMESPACE/yygh-site:SNAPSHOT-$BUILD_NUMBER' } } } } stage('部署到 dev 环境') { agent none steps { kubernetesDeploy(configs: 'deploy/**', enableConfigSubstitution: true, kubeconfigId: "$KUBECONFIG_CREDENTIAL_ID") } } // 1、配置全零碎的邮件： 全零碎的监控 // 2、批改 ks-jenkins 的配置，外面的邮件； 流水线发邮件 stage('发送确认邮件') { agent none steps { mail(to: '[email protected]', subject: 'yygh-site 构建后果', body: "胜利构建 $BUILD_NUMBER") } } } environment { ... }}此处不再展现更多细节。
总结
KubeSphere 为咱们提供了 Jenkins 流水线的编辑页面，在肯定水平上能够简化操作。
参考
本文参考了雷丰阳的视频课程 云原生 Java 架构师的第一课 K8s+Docker+KubeSphere+DevOps。 如果想全面而深刻地自主实际，举荐观看原视频。
本文由博客一文多发平台 OpenWrite 公布！