在Dubbo时代,虽然开发业务效率有一定提升,但跟WCF一样,服务对平台敏感,难以简单复用,在提供对外服务时,都会以REST的方式提供出去,另外框架对服务侵入性较大,不能很好的支撑后续技术发展,期间我们也有根据Thrift + ZooKeeper自研rpc框架,并且考虑支持多语言平台,但难度较高,团队规模也不允许,所以早早放弃,尽量使用开源平台,此时我们对Docker、Kubernetes进行调研,因此打开了另一扇大门,Kubernetes的功能足够炫!
Kubernetes——容器编排的王者,容器云的首选方案,对虚拟化平台的革新功能:
资源调度
弹性伸缩、自动扩展
资源高利用率
负载均衡
资源基本监控
容灾备份
滚动更新
日志访问
自检和自愈
2017-2018年间IaaS/PaaS、Docker、微服务、互联网架构等等各种概念侵袭,收到一波波的洗礼,我们完成了Kubernetes从无到有并应用至生产,SOA/微服务的业务边界划分,并推行了前后端分离开发,奠定业务与人员架构基础,使前后端可并行开发,更好的支撑后续业务、技术发展,人员更精于自身专业方向。
目前我们的服务器在IDC环境中,已有VMware虚拟化平台,因此在虚拟机上搭建私有容器云是首选方案。
Kubernetes高可用采用官方推荐方案,整体搭建采用Keepalived + Nginx + Kubernetes + Calico,基于Kubeadm方式安装1.11.1版本,3 Master + 3 etcd + 12 Node节点,整体流程图:
高可用集群采用1主2热备,将Keepalived的VIP绑定到VM网卡上,当Master因故障宕机,另外两个Master会根据Keepalived配置的优先级接管VIP,从而起到灾备作用,另外将kube-proxy的serverIP换成Keepalived生成的VIP和自定义端口号,通过Nginx转发至3个kube-apiserver,实现3 Master参与负载。
kubeadm-ha已经完全可以在生产环境使用,当Master故障无法恢复时,可以快速加入一个新Master节点,保障集群可靠性。
etcd采用集群内3节点方案,Kubeadm新版本可以友好支持etcd-SSL的操作,当etcd故障时,通过Kubeadm可以快速将新节点加入集群。
平台经过多次灾备演练,目前稳定可靠,如图大家应该比较熟悉:
我们采用ingress-nginx来取代VM上面的Nginx,服务内部通讯采用Kubernetes推荐的CoreDNS,通过ConfigMap方式配置DNS域名解析,取代原来挂载宿主机/etc/hosts方式。
外网访问,内网集群将Service以NodePort方式暴露端口,通过负载均衡器进行转发。
根据Kubernetes优秀的设计思想,开发也有相应的调整,新业务统一采用React+Spring Boot进行开发,因此我们的开发平台如下:
Node.js负责Web/H5前端
Android 、iOS移动端
Java/Spring Boot负责后端业务开发
一张图看懂开发架构:
在应用Spring Cloud Netflix套件时,Eureka安装在集群外的VM上,服务注册Eureka默认读取的是hostIP,在Kubernetes上Pod被分配的虚拟IP在集群外部无法访问,我们尝试过多种解决方案,例如挂载Volume方式,写入宿主机IP到容器内的env变量,最终还是统一将注册Eureka Clinet方法重写,将注册服务地址改为Ingress配置的CoreDNS域名,集群外部访问成功。
在分布式微服务中,各服务都有一套独立的配置,Spring框架尤以面向接口编程思想贯穿整个项目工程,配置项众多,我们选用携程Apollo配置中心来替代Properties,多个服务可共享一个namespace配置,解决复杂而繁琐的配置问题,配置中心已经上升到整个架构层面的作用。
API统一接口文档采用去哪儿开源的Yapi,可私有部署,功能齐全,QA也可做接口自动化测试,测试集脚本语言支持Pre-Script,遵循JavaScript语法,如图:
DevOps流水线设计
根据上面的介绍,经过一定积累和沉淀后,我们开始设计CI(持续集成)、CD(自动化部署),CI/CD的优势显而易见:
解放了重复性劳动:自动化部署工作可以解放集成、测试、部署等重复性劳动,而机器集成的频率明显比手工高很多。
更快地修复问题:持续集成更早的获取变更,更早的进入测试,更早的发现问题,解决问题的成本显著下降。
更快的交付成果:更早发现错误减少解决错误所需的工作量。集成服务器在构建环节发现错误可以及时通知开发人员修复。集成服务器在部署环节发现错误可以回退到上一版本,服务器始终有一个可用的版本。
减少手工的错误:在重复性动作上,人容易犯错,而机器犯错的几率几乎为零。
减少了等待时间:缩短了从开发、集成、测试、部署各个环节的时间,从而也就缩短了中间可以出现的等待时机。持续集成,意味着开发、集成、测试、部署也得以持续。
借助gitlab-runner,我们已实现多个DevOps流程,包括NodeJs、Spring MVC,以及在VM虚拟机上的CI/CD:
如部署遇到问题,可快速手工触发CI/CD,回滚上一个版本,保障线上始终有一个版本可用。
CI/CD流程代码示例:
stages :
- build_test #测试CI
- deploy_k8s_test #测试CD
- build_prod #生产CI
- deploy_k8s_prod #生产CD
#测试CI
build_test_job:
stage : build_test
script:
- mvn clean install
- cd target
- docker build -f classes/app.dockerfile -t registry/maven-project:$CI_COMMIT_SHA .
artifacts :
paths :
- target/classes/deploy.k8s.yaml
tags :
- runnerHost
only :
- master
#测试CD
deploy_k8s_test_job:
stage : deploy_k8s_test
before_script :
- docker push registry/maven-project:$CI_COMMIT_SHA
script: |
kubectl apply -f deploy.k8s.yaml
kubectl describe -f deploy.k8s.yaml
after_script :
- pwd
tags :
- runnerHost
only :
- master
Kubernetes在1.13+版本中已经剔除了Heapster + InfluxDB作为默认监控工具,主推Prometheus,Prometheus可以做到代码级的监控,我们在各虚机、中间件、应用程序中使用工具收集资源消耗信息。
Grafana可作为大数据展示平台,实时查看各项资源运营情况:
Prometheus也提供Java开发包,可以做到代码级统计,当服务响应报错或时间过长,可触发告警,通知相关开发人员查看原因:
平台整体架构
私有容器云和DevOps主流程已经实现,配合Prometheus监控,基础设施层形成闭环,这是从无到有的过程,整体架构一张图可以看懂:
总结:目前的框架都是原生应用,利用了各家的优秀特性,我们并没有针对性改造框架,原生功能足够满足团队业务需求;有许多地方还需要深入研究和应用,完善基础设施层,例如监控目标、告警规则、Service Mesh如何将服务间请求下放到基础设施层、CI/CD的持续完善,金丝雀发布等等。
Q:Kubernetes本身技术框架带来的问题在生产环境中有碰到没,请举几个例子。A:Kubernetes如果出问题带来的都是雪崩效应,例如网络Calico、存储etcd出现故障是灾难性的,我们也踩过不少这方面的坑,所以要做到高可用才能稳定生产。
Q:一个开发人员想在开发环境部署一个服务,他必须要懂Kubernetes,去写那些yaml吗,有什么易用的可视化平台?A;yaml有一套语法体系,非常简单,可以搜一下相关资料,主要是理解Kubernetes的相关原理,根据服务要求编写配置文件,可视化平台如Kubernetes Dashboard上就有,不过基本没用,如果运维体系比较成熟,这些yaml可以交给他们来编写。
Q:Calico网络你们如何解决跨中心的网络通信,BGP只能在同一个交换机才行。A:我们目前还没跨机房通讯,不过etcd需要高速网络才能数据同步,跨机房拉专线比较合适,BGP协议还没用到,小规模部署可以考虑添加静态路由的方式打通Kubernetes集群内外的网络。
Q:应用有是否有状虑使用,用的什么存储解决方案?A:我们提倡无状态部署,目前所有应用服务都是无状态,有状态服务存储可以考虑NFS。
Q:用二进制安装可以不,Kubeadm会有升级些问题,默认的Iptables不太好吧。现在是IPVS。A:二进制也可以,比较稳定,Kubeadm滚动升级我们还在踩坑中,升级策略目前我们是另外搭集群,一键部署所有应用(每次部署都会统一存储最新部署yml),对外网关可选择性切换应用,Iptables被Kubernetes捡起来又放弃了,未来的趋势是IPVS,目前我们也在测试环境中试验。
Q:服务监控和服务器监控这块的取舍,现在监控都是用Prometheus?A:Prometheus是CNCF旗下仅次于Kubernetes的项目,对应用程序比较友好,做服务监控非常棒,配合Grafana图形展示体验非常好,跟Zabbix相比各有特色。
Q:请问你们是创业问团队还是大规模团队?考虑Kubernetes机缘是?对于Kubernetes来说生态所存在的不足,如安全问题是怎么考虑的?A:不管创业还是大规模团队,适合自己业务,技术可持续演进、完善并提升效率就是好的方向,考虑Kubernetes是因为它的优秀功能,让技术团队可以站在更高的起点,看得更远;Kubernetes生态已经非常强大,在内网运行,相对较为安全,另外也有启用RBAC权限访问控制,配合其他持续集成工具,安全控制都可以个性化定制。
Q:Kubernetes集群你们为什么没有部实体机在署上?A:虚拟机和实体机都行,我们实体机数量有限,包括中间件那些,做高可用会用占用比较多的Node机。