公司的所有java项目（微服务）基本上都采用kubesphere来进行CD/CI的持续集成管理，关于kubesphere的资料，大家可以上它的官网：kubesphere.cloud/ 进行查看。
一、引入kubesphere的背景
在17〜18年这段时间中，随着公司电商业务的发展，单体项目在开发及运维、扩展等方式都遇到了瓶劲，为了提升效率，降低复杂度，可视化监控等目标，引入了kubernetes，从早期单纯依靠jenkins打包部署到服务器上的虚拟机上，调整为通过jenkins + kubernetes这样的集成部署方式（引入jenkins，解决了在拆分微服务后，手工进行项目的打包，上传，启动等复杂的过程）。
调整完后，有时需要去了解kubernetes上各个节点及资源的使用情况，需要通过后台输入命令的方式来进行查看，不够直观，一直想有没有什么可视化的工具来管理，最好也能把流水线管理起来，做到按不同人不同权限来进行分配与管理。
二、发现 kubeSphere
在一个偶然的时候，在查找kubernetes的信息时，发展了一个kubeSphere的管理平台，当初的版本是2.几，通过对kubesphere的调研与分析，发展很适合公司的开发与运管理，随后就按排运维人员进行研究与搭建。
kubesphere从使用上来说，有以下的功能很不错：
- 支持多租户（企业空间）的方式进行管理；
- 对kubernetes提供界面层的操作与调度（让你摒弃命令行的操作）；
- 可视化监控界面，可以实时了解整个集群资源/pod等的使用情况；
- 通过集成kubersphere-devops-system，提供可视化 CI/CD 流水线。
- 支持按不同人员分开权限进行部署及运维管理（这点很重要，按不同开发人员进行发布配置权限）；
- 多维度监控告警日志；
- 提供可视化的界面来查看每个pod中运行服务的日志，不需要让开发人员去登录服务器查看了；
- 服务岩机自动恢复等。
以上是我觉得不错的地方，公司现有服务都托管在这个上面。
三、 KubeSphere初使用
目前公司的KubeSphere是采用集群方式，共有5个master节，31个从节点。
集群情况
项目划分情况
企业空间情况
四、KubeSphere中的用户关系
在KubeSphere中，帐号是独立管理的，通过添加或授权的方式，添加到不同的企业空间，项目组中，帐号要么由管理员创建，要么由具备users-manager权限的用户进行创建。除非特殊情况，一般创建的角度默认分配platform-regular角度就可以。
帐号创建完后，他只是一个帐号，要将帐号添加到企业空间中，才具备相应项目的权限，如下：
成为企业成员后，帐号才能被添加到“项目管理”， “DevOps工程“中。项目管理，是对本企业空间下的各个kubernetes的namespace进行管理。每个namespace就是具体部署的pod容器了。
DevOps工程，是部署流水线管理，负责编辑各种流水线部署任务，来进行服务的部署。
进入到每个流水线管理，又可以新建很多的发布任务
可以关注“凭证”，“工程角色”，“工程成员”，“创建”的功能。一般情况：
- 凭证：这里负责管理各种帐号密码，比如连接git的帐号密码， harbor的帐号密码，kubeconfig等。
- 工程角色：平台有提供默认的角色，也可以根据实际的需要进行创建与分配。一般admin的角色，可以看到本流水线工程下所有的发布任务。
- 工程成员：管理本流水线工程的操作者（帐号），只有加入进来后，才有权限看到发布的任务。
五、流水线配置
提供界面化的流水线发布配置（简化了jenkins的配置），可以通过直接编辑jenkinsfile ,也可以通过编辑流水线（拉拖的试）来进行配置。
当配置完成后，就可以点击”运行“，就可以实现自动化部署。从gitlab拉取代码，然后在容器中进行编译打包，发布到harbor私仓中，通过kubernetes的yaml文件实现拉取及部署到指定的节点上。
六、总线
使用KubeSphere后，项目的开发及部署清晰可见，不同人不同权限进行管理，发布日志有依可巡。后面都推广到了前端项目中去，让前告别打包上传的痛苦。
