一、背景
目前公司的所有项目，基本上都实现了容器化部署与运维，全部都是托管在KubSphere上，并且也使用上了kubesphere的devops，实现CD/CI的流水线化。
默认情况下，kubesphere在执行CD/CI的流水线打包发布任务时，是在kubesphere的集群上随机找到某个节点（node节点）来执行作业的，包括java打包用的jenkins，最终都是使用了jnlp-slave的模式来运行；前端用nodejs来进行打包部署等。
之前在部署安装完后，就想过要指定特定的节点来做为CD/CI的作业环境，但由于后面工作的原因，一直没的安排上，最近出现了一次事故，导致集群上的某个节点出现了“污点“，在这个节点上的pod都变成“下线”状态，涉及的系统功能不能使用。
通过问题排查，发现是前端在执行“流水线“编译打包运行在本节点，可能是前端的原因，导致辞下载很多第三方的组件，然编译，导致节点的资源被占满，节点被迫离线。
二、如何让流水线的作业在指定的节点上运行？
发生了上面的事故后，运维组着手研究如何将生产环境的节点，与流水线的节点分开，不要让发布去影响生产。
kubesphere的casc 配置
一般来说，kubesphere中各种组件的配置，都是在集群管理-平台管理-配置中心-配置 里面。打开配置的界面，通过筛选框，找到kubesphere-devops-system的选项，如下图所示：
找到图中红框中的配置项，jenkins-casc-config项，点击后面的三个 ... 点，找到“修改配置”的菜单
点击上图中的“编辑”，进入到如下图的配置界面：
找到对应的模板配置项，在其中添加一个key-value的值，nodeSelector, 这个nodeSelector就是指定这个编译模板将要使用的节点（如上图中的env=pck-node，这个是在节点管理中，某个节点配置的变量）。
配置完成后，点击“√“进行保存，同时点击下面的”更新“。
节点的配置
在节点管理-集群节点中，找到你要更新的节点，进入节点后，选择”更多操作“中的”编辑标签“，如下图所示，添加标签
这样操作就完成了。但还有一步重要的操作，需要在kubesphere的jenkins上，重新reload下配置。
三、reload jenkins的configuration，让配置生效
上面是配置了kubesphere中有关jeninks的casc-config的全局配置，但是要在jenkins中重新reload才能生效，一般情况下，默认是主master的ip + 30180 ，就是jenkins的访问地址。
输入帐号密码（kubesphere的管理员/帐号密码）后,进入到jenkins的主界面，找到菜单：
按照上图操作，就可以完成前面配置的reload，如果reload失败，会跳到失败的界面，上面会提示失败的信息。如果成功，就还是停留在当前的界面。
四、测试
可以在流水线管理中，添加一个流水线的任务，来看上面的配置是否生效，编写如下的作业内容，在作业中执行了sleep 300,是为了看效果，执行这个后，可以到 “容器管理” 中，看生成的编译pod，是否已经分配到了指定的节点。
五、总结
调整kubesphere中devops在指定节点上运行的配置如上所述，希望能帮到各位。
