作者：宇轩辞白，运维研发工程师，目前专注于云原生、Kubernetes、容器、Linux、运维自动化等领域。
第三方客户业务环境均是IDC自建机房环境，提供虚拟化服务器资源，计划引入Kubernetes技术，满足互联网医疗需求。
据悉，第三方客户已有的架构体系已不满足日益增长的业务量，缺少一个完整且灵活的技术架构体系。
上图便是我们项目生产企业架构图，从逻辑上分为四大版块。
关于CI/CD自动化开源工具相信大家都了解不少，就我个人而言，我所熟知的就有Jenkins、GitLab、Spug以及我接下来将会为大家介绍的KubeSphere。它同样也能完成企业级CI/CD持续交付事宜。
因业务需要，这里将测试、生产两套环境独立开，避免相互影响。如上图所示是三个Matsre节点，五个Node节点，这里Master节点标注污点使其Pod不可调度，避免主节点负载过高等情况发生。另外测试环境集群规模相对较小，Master节点数量相同，但Node节点仅只有两个作为使用，因仅作测试，没有问题。
底层存储环境我们并未采用容器化的方式进行部署，而是以传统的方式部署。这样做也是为了高效，而且在互联网业务中，存储服务都有一定的性能要求来应对高并发场景。因此将其部署在裸机服务器上是最佳的选择。MySQL、Redis、NFS均做了高可用，避免了单点问题，NFS在这里是作为KubeSphereStorageClass存储类。关于StorageClass存储类选型还有很多，比如Ceph、OpenEBS等等，它们都是KubeSphere能接入的开源底层存储类解决方案。尤其是Ceph，得到了很多互联网大厂的青睐，此时你们可能会问我，为什么选择NFS而不选择Ceph，我只能说，在工具类选型中，只有最合适的，没有最好的，适合你的业务类型你就选择什么，而不是人云亦云，哪个工具热度高而去选择哪个工具。
一个完整的互联网应用平台自然是少不了监控告警了。在过去几年，我们所熟知的Nagios、Zabbix、Cacti这几款都是老牌监控了，现如今都渐渐退出历史的舞台。如今Prometheus脱颖而出，深受各大互联网企业青睐，结合Grafana，不得不说是真的香。在该架构体系中，我也是毫不犹豫的选择了它。
客户现有平台环境缺少完整的技术架构体系，业务版本更新迭代困难，无论是业务还是技术平台都出现较为严重的瓶颈问题，不足以支撑现有的业务体系。为了避免导致用户流失，需要重新制定完整的架构体系。而如今，互联网技术不断更新迭代，随着Kubernetes日益盛行，KubeSphere也应运而生。一个技术的兴起必定会能带动整个技术生态圈的发展，我相信，KubeSphere的出现，能带给我们远不止你想象的价值和便捷。
Kubernetes集群建设完毕之后，随后便面临一个问题，就是我们内部研发人员如何去管理维护它。需求新增要求版本迭代，研发人员如何去进行发版上线自己的业务代码；出现问题如何更好的去分析定位处理等等一系列问题都需要考虑，难不成让他们登陆到服务器上通过命令行敲？因此为了解决上面的问题，我们需要再引入一个Dashboard管理平台。
KubeSphere为企业用户提供高性能可伸缩的容器应用管理服务，旨在帮助企业完成新一代互联网技术驱动下的数字化转型，加速应用的快速迭代与业务交付，以满足企业日益增长的业务需求。我所看重的KubeSphere四大主要优势如下：
随着容器应用的日渐普及，各个企业跨云或在本地环境中部署多个集群，而集群管理的复杂程度也在不断增加。为满足用户统一管理多个异构集群的需求，KubeSphere配备了全新的多集群管理功能，帮助用户跨区、跨云等多个环境管理、监控、导入和运维多个集群，全面提升用户体验。
多集群功能可在安装KubeSphere之前或之后启用。具体来说，该功能有两大特性：
KubeSphere的可观测性功能在v3.0中全面升级，进一步优化与改善了其中的重要组件，包括监控日志、审计事件以及告警通知。用户可以借助KubeSphere强大的监控系统查看平台中的各类数据，该系统主要的优势包括：
自动化是落地DevOps的重要组成部分，自动、精简的流水线为用户通过CI/CD流程交付应用提供了良好的条件。
KubeSphere为用户提供不同级别的权限控制，包括集群、企业空间和项目。拥有特定角色的用户可以操作对应的资源。
底层集群环境准备就绪之后，我们就需要考虑（CI/CD）持续集成交付的问题，为了保证最后生产服务容器化顺利部署至Kubernetes以及后期更加稳定可控，于是乎我采用了一下战略性方案：
DevopsCI/CD流程剖析：
无状态服务在KubeSphere中的服务如下图所示，包括应用层的前后端服务，另外Minio都是以Deployment方式容器部署。
有状态服务主要是一些基础设施服务，如下图所示：比如MySql、Redis等，我仍然是选择采用虚机部署，RocketMQ较为特殊，选择了Statefulset方式进行部署。
该资源类需要定义在git上，当我们运行KubeSphereDevOps流水线部署环节，需要调用该yaml资源进行服务更新迭代。
apiVersion:apps/v1kind:Deploymentmetadata:labels:app:boot-prejectname:boot-prejectnamespace:middleware#定义Namespacespec:progressDeadlineSeconds:600replicas:1selector:matchLabels:app:boot-prejectstrategy:rollingUpdate:maxSurge:50%maxUnavailable:50%type:RollingUpdatetemplate:metadata:labels:app:boot-prejectspec:imagePullSecrets:-name:harborcontainers:-image:$REGISTRY/$HARBOR_NAMESPACE/boot-preject:SNAPSHOT-$BUILD_NUMBER#这里定义镜像仓库地址+kubesphere构建变量值imagePullPolicy:Alwaysname:appports:-containerPort:8080protocol:TCPresources:limits:cpu:300mmemory:600MiterminationMessagePath:/dev/termination-logterminationMessagePolicy:FilednsPolicy:ClusterFirstrestartPolicy:AlwaysterminationGracePeriodSeconds:30定义流水线凭据：
KubeSphere3.3.2版本提供了已有的模版，不过我们可以尝试自己定义流水线体系图形编辑面板包括两个区域：左侧的画布和右侧的内容。它会根据您对不同阶段和步骤的配置自动生成一个Jenkinsfile，为开发者提供更加用户友好的操作体验
该阶段主要是拉取git代码环境，阶段名称命名为PullingCode，指定maven容器，在图形编辑面板上，从类型下拉列表中选择node，从Label下拉列表中选择maven：
选择+号，开始定义代码编译环境，名称定义为Buildcompilation，添加步骤。
该阶段主要是通过Dockerfile打包生成镜像的过程，同样是生成之前先指定容器，然后新增嵌套步骤，指定shell命令定义Dockerfile编译过程：
该阶段主要是基于Dockerfile编译之后的镜像上传至镜像仓库中：
该阶段主要是部署环境，镜像上传至Harbor仓库中，就开始着手部署的工作了。
在这里我们需要提前把Deployment资源定义好，通过kubectlapply-f根据定义好的文件执行即可。
流程如下：选择+，定义名称Deployingtok8s，选择下方“添加步骤”--->"添加凭据"--->"添加嵌套步骤"--->"指定容器"--->"添加嵌套步骤"--->"shell"。
这里命令是指定的git事先定义完成的yaml文件。
以上，一个完整的流水线制作完毕。接下来我们运行即可完成编译。
工作负载展示：
在这里给大家附上我本人生产Pipeline案例，可通过该Pipeline流水线，直接应用于企业生产环境，
引入KubeSphere很大程度的减轻了公司研发持续集成、持续部署的负担，极大提升了整个研发团队生产里项目交付效率，研发团队只需自行在本地实现function修复Bug，之后Commit提交代码至git，然后基于KubeSphere的DevOps直接点击运行，发布测试环境/生产环境的工程，此时整套CI/CD持续集成交付的工作流程就彻底完成了，剩余的联调工作就交给研发。
基于KubeSphere实现DevOps，给我们带来了最大的效率亮点如下：
从目前来看，通过这次生产项目中引入KubeSphere云原生平台实践，发现确实给我们解决了微服务部署和管理的了问题，极大的提高我们的便捷性。负载均衡、应用路由、自动扩缩容、DevOps等等，都能对我们Kubernetes产生极大的推进，未来继续深耕云原生以及Kubernetes容器化领域，继续推进现有业务容器化，去拥抱云原生这个生态圈，为我们的业务保驾护航。