生产实践：基于K8S的私有化部署解决方案

本文主要是介绍生产实践：基于K8S的私有化部署解决方案，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

随着国内数字化转型的加速和国产化进程推动，软件系统的私有化部署已经成为非常热门的话题，因为私有化部署赋予了企业更大的灵活和控制权，使其可以根据自身需求和安全要求定制和管理软件系统。下面分享下我们的基于k8S私有化部署经验。

私有化交付的目标

要支持系统快速部署至客户机房
支持版本在线升级
支持动态扩容
能快速集成系统监控告警
支持在线运维
可快速移植

因此基于k8s做私有化交付是最合适的方案，当然如果项目规模比较小，就几个服务也没有动态扩容等需求，那么也没必要引入k8s，如果项目规模较大，使用k8s进行私有化部署是不错的解决方案。

基于k8s私有化部署如何做？

以上我们确认了使用k8s做私有化部署，但是还有一些细节问题，需要考虑

在公司内部一般使用gitlab+Jenkins做服务部署，在客户现场，这种方式一般不可行，因为一般不允许在客户现场访问公司的代码仓库

镜像仓库要能支持公网访问，这样才可以在客户机房下载到镜像
一个服务就有很多yaml文件，如果几十个服务的yaml文件怎么管理，如何快速部署或者升级
中间件要支持快速部署，有些中间件不能部署在k8s，所以需要支持自动化脚本快速部署。
系统配置如何管理，每个服务都依赖数据库、消息等中间件，这些地址怎么管理起来

基于问题，我们的解决方案如下：

在公司内部构建镜像时，直接推送至公网镜像仓库Harbar，在客户机房直接拉取部署，而部署服务使用Helm进行部署，Helm是一个 k8s的包管理工具，他可以把一组服务yaml文件管理起来，并且支持部署和更新，非常方便。比如有一个文件系统，包括Deployment、Service、gateway vs、pv pvc等文件，如果用Helm管理起来,如下图

上面文件大部分是模板，而引用的是values.yaml定义的参数，同时这个参数，可以在系统部署时指定，如下要部署文件系统，执行以下命令即可完成

helm install fss myrepo/fss  \
--set pv.log.type=storageClass \
--set pv.log.pvc.storageName=gfs-storage \
--set pv.log.pvc.storage=5Gi \
--set pv.file.type=storageClass \
--set pv.file.pvc.storageName=gfs-storage \
--set pv.file.pvc.storage=1Gi \
--set istioGateway.schema=http \
--set istioGateway.hosts={test-user.com} \
--set istioGateway.ucenterHost=test-order.com \
--set apollo.cluster=test\
--set sv.fssManager.replicaCount=1 \
--set sv.fssRest.replicaCount=1

中间件部署，对部署在k8s外部的中间件，可以使用Ansiable编写自动化脚本，进行快速部署，几分钟就可以部署一个高可用集群。

系统参数配置，一般使用Nacos进行管理配置，但是由于服务过多，配置起来工作量相对较大，而且很多都是重复工作。比如数据库地址、kafka地址、es地址都是相同的，那么如何避免做重复工作，比如可以写一个shell脚本把公共的参数提取出来，然后进行修改替换，或者开发一个运维部署平台，把相关公共参数进行图形化配置，并对接配置中心，进行发布替换。

系统监控告警，目前可使用deepFlow、kube-prometheus、夜莺等解决方案

在线运维平台，可以使用Rancher或KuberSphere，这两个都是目前非常热门图形化运维平台

快速移植，k8s设计之初就考虑到移植性的问题，所以与底层基础设施无关联性，所以不管是在公有云、私有云、混合云都是可以进行部署的，而且现在各大云厂商，都有 k8s 的商用解决方案，让我们部署起来更加快速，也不用考虑集群的稳定性，比如阿里的ACK、华为的CCE、腾讯云的TKE等。

这篇关于生产实践：基于K8S的私有化部署解决方案的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！