作者:宇轩辞白,运维研发工程师,目前专注于云原生、Kubernetes、容器、Linux、运维自动化等领域。
2020 年我国互联网医疗企业迎来了“爆发元年”,越来越多居民在家隔离期间不方便去医院看诊,只好采取在线诊疗的手段。互联网医疗企业的迅速发展的同时,也暴露出更多的不足。互联网医疗作为医疗行业发展的趋势,对于解决中国医疗资源分配不平衡和人们日益增长的医疗健康需求之间的矛盾具有诸多意义。但对于能否切实解决居民就诊的问题,以及企业能否实现持续发展等是国家以及企业十分关注的问题。而我司在这条道路上沉淀多年,一直致力于互联网医疗服务,拥有自己完善医疗产品平台以及技术体系。
第三方客户业务环境均是 IDC 自建机房环境,提供虚拟化服务器资源,计划引入 Kubernetes 技术,满足互联网医疗需求。
据悉,第三方客户已有的架构体系已不满足日益增长的业务量,缺少一个完整且灵活的技术架构体系。
上图便是我们项目生产企业架构图,从逻辑上分为四大版块。
关于 CI/CD 自动化开源工具相信大家都了解不少,就我个人而言,我所熟知的就有 Jenkins、GitLab、Spug 以及我接下来将会为大家介绍的 KubeSphere。它同样也能完成企业级 CI/CD 持续交付事宜。
因业务需要,这里将测试、生产两套环境独立开,避免相互影响。如上图所示是三个 Matsre 节点,五个 Node 节点,这里 Master 节点标注污点使其 Pod 不可调度,避免主节点负载过高等情况发生。另外测试环境集群规模相对较小,Master 节点数量相同,但 Node 节点仅只有两个作为使用,因仅作测试,没有问题。
底层存储环境我们并未采用容器化的方式进行部署,而是以传统的方式部署。这样做也是为了高效,而且在互联网业务中,存储服务都有一定的性能要求来应对高并发场景。因此将其部署在裸机服务器上是最佳的选择。MySQL、Redis、NFS 均做了高可用,避免了单点问题,NFS 在这里是作为 KubeSphere StorageClass 存储类。关于 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 以及后期更加稳定可控,于是乎我采用了一下战略性方案:
Devops CI/CD 流程剖析:
SNAPSHOT-$BRANCH_NAME-$BUILD_NUMBER
标签推送至 Docker Hub,其中 \$BUILD_NUMBER
为流水线活动列表中的运行序号。无状态服务在 KubeSphere 中的服务如下图所示,包括应用层的前后端服务,另外 Minio 都是以 Deployment 方式容器部署。
有状态服务主要是一些基础设施服务,如下图所示:比如 MySql、Redis 等,我仍然是选择采用虚机部署,RocketMQ 较为特殊,选择了 Statefulset 方式进行部署。
该资源类需要定义在 git 上,当我们运行 KubeSphere DevOps 流水线部署环节,需要调用该 yaml 资源进行服务更新迭代。
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: boot-preject
name: boot-preject
namespace: middleware #定义Namespace
spec:
progressDeadlineSeconds: 600
replicas: 1
selector:
matchLabels:
app: boot-preject
strategy:
rollingUpdate:
maxSurge: 50%
maxUnavailable: 50%
type: RollingUpdate
template:
metadata:
labels:
app: boot-preject
spec:
imagePullSecrets:
- name: harbor
containers:
- image: $REGISTRY/$HARBOR_NAMESPACE/boot-preject:SNAPSHOT-$BUILD_NUMBER #这里定义镜像仓库地址+kubesphere 构建变量值
imagePullPolicy: Always
name: app
ports:
- containerPort: 8080
protocol: TCP
resources:
limits:
cpu: 300m
memory: 600Mi
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
terminationGracePeriodSeconds: 30
定义流水线凭据:
KubeSphere 3.3.2 版本提供了已有的模版,不过我们可以尝试自己定义流水线体系图形编辑面板包括两个区域:左侧的画布和右侧的内容。它会根据您对不同阶段和步骤的配置自动生成一个 Jenkinsfile,为开发者提供更加用户友好的操作体验
该阶段主要是拉取 git 代码环境,阶段名称命名为 Pulling Code
,指定 maven 容器,在图形编辑面板上,从类型下拉列表中选择 node,从 Label 下拉列表中选择 maven:
选择+号,开始定义代码编译环境,名称定义为 Build compilation
,添加步骤。
该阶段主要是通过 Dockerfile 打包生成镜像的过程,同样是生成之前先指定容器,然后新增嵌套步骤,指定 shell 命令定义 Dockerfile 编译过程:
该阶段主要是基于 Dockerfile 编译之后的镜像上传至镜像仓库中:
docker tag boot-preject:latest $REGISTRY/$HARBOR_NAMESPACE/boot-preject:SNAPSHOT-$BUILD_NUMBER
该阶段主要是部署环境,镜像上传至 Harbor 仓库中,就开始着手部署的工作了。
在这里我们需要提前把 Deployment 资源定义好,通过 kubectl apply -f
根据定义好的文件执行即可。
流程如下:选择 +,定义名称 Deploying to k8s
,选择下方“添加步骤”--->"添加凭据"--->"添加嵌套步骤"--->"指定容器"--->"添加嵌套步骤"--->"shell"。
这里命令是指定的 git 事先定义完成的 yaml 文件。
envsubst < deploy/deploy.yml | kubectl apply -f -
以上,一个完整的流水线制作完毕。接下来我们运行即可完成编译。
工作负载展示:
在这里给大家附上我本人生产 Pipeline 案例,可通过该 Pipeline 流水线,直接应用于企业生产环境,
pipeline {
agent {
node {
label 'maven'
}
}
stages {
stage('Pulling Code') {
agent none
steps {
container('maven') {
//指定git地址
git(url: 'https://gitee.com/xxx/test-boot-projext.git', credentialsId: 'gitee', branch: 'master', changelog: true, poll: false)
sh 'ls'
}
}
}
stage('Build compilation') {
agent none
steps {
container('maven') {
sh 'ls'
sh 'mvn clean package -Dmaven.test.skip=true'
}
}
}
stage('Build a mirror image') {
agent none
steps {
container('maven') {
sh 'mkdir -p repo/$APP_NAME'
sh 'cp target/**.jar repo/${APP_NAME}'
sh 'cp ./start.sh repo/${APP_NAME}'
sh 'cp ./Dockerfile repo/${APP_NAME}'
sh 'ls repo/${APP_NAME}'
sh 'cd repo/${APP_NAME}'
sh 'docker build -t boot-preject:latest . '
}
}
}
stage('Pack and upload') {
agent none
steps {
container('maven') {
withCredentials([usernamePassword(credentialsId : 'harbor' ,passwordVariable : 'DOCKER_PWD_VAR' ,usernameVariable : 'DOCKER_USER_VAR' ,)]) {
sh 'echo "$DOCKER_PWD_VAR" | docker login $REGISTRY -u "$DOCKER_USER_VAR" --password-stdin'
sh 'docker tag boot-preject:latest $REGISTRY/$HARBOR_NAMESPACE/boot-preject:SNAPSHOT-$BUILD_NUMBER'
sh 'docker push $REGISTRY/$HARBOR_NAMESPACE/boot-preject:SNAPSHOT-$BUILD_NUMBER'
}
}
}
}
stage('Deploying to K8s') {
agent none
steps {
withCredentials([kubeconfigFile(credentialsId : 'demo-kubeconfig' ,variable : 'KUBECONFIG' )]) {
container('maven') {
sh 'envsubst < deploy/deploy.yml | kubectl apply -f -'
}
}
}
}
}
environment {
DOCKER_CREDENTIAL_ID = 'dockerhub-id' #定义docker镜像认证
GITHUB_CREDENTIAL_ID = 'github-id' #定义git代码仓库认证
KUBECONFIG_CREDENTIAL_ID = 'demo-kubeconfig' #定义kubeconfig kubectl api认证文件
REGISTRY = 'harbor.xxx.com' #定义镜像仓库地址
HARBOR_NAMESPACE = 'ks-devopos'
APP_NAME = 'boot-preject'
}
parameters {
string(name: 'TAG_NAME', defaultValue: '', description: '')
}
}
业务存储我们选择的是 MySQl、Redis。MySQL 结合 Xenon 实现高可用方案。
引入 KubeSphere 很大程度的减轻了公司研发持续集成、持续部署的负担,极大提升了整个研发团队生产里项目交付效率,研发团队只需自行在本地实现 function 修复 Bug,之后 Commit 提交代码至 git,然后基于 KubeSphere 的 DevOps 直接点击运行,发布测试环境/生产环境的工程,此时整套 CI/CD 持续集成交付的工作流程就彻底完成了,剩余的联调工作就交给研发。
基于 KubeSphere 实现 DevOps,给我们带来了最大的效率亮点如下:
从目前来看,通过这次生产项目中引入 KubeSphere 云原生平台实践,发现确实给我们解决了微服务部署和管理的了问题,极大的提高我们的便捷性。负载均衡、应用路由、自动扩缩容、DevOps 等等,都能对我们 Kubernetes 产生极大的推进,未来继续深耕云原生以及 Kubernetes 容器化领域,继续推进现有业务容器化,去拥抱云原生这个生态圈,为我们的业务保驾护航。
本文由博客一文多发平台 OpenWrite 发布!