DockOne微信分享(二二二):小公司如何优雅地推进应用上Kubernetes容器云


【编者的话】随着公司业务高速发展,叠加市场变化莫测,业务也要及时作出反应,这要求我们需要更快速的交付和部署。本文主要介绍公司在容器化落地过程中遇到的困难和解决方案,希望能帮助正在上或准备上容器云平台的朋友们。

为何要上容器?

首先了解下公司背景,如下图所示:
1.png

  1. 随着公司业务高发展,市场变化莫测,业务也要及时作出反应,这要求我们能更快速的交付和部署。
  2. 系统资源利用率可提升空间大,随着业务规模不断扩大后,会引起服务器资源浪费。
  3. 系统环境多,久而久之存在环境差异严重的可能性增大,影响业务交付效率,同时环境相对较复杂,维护管理成本较大。


综上所述3大原因导致运维团队迫不及待推进容器云平台,主要为了达到以下三大点收益:
2.png

容器编排如何选择?

3.png

从生产经验、学习和运维成本几个维度对比现阶段的几个主流编排工具优缺点后,公司运维团队成员在技术选型上毅然一致性选择Kubernetes。Kubernetes(简称为K8s)是用于自动部署、扩展和管理容器化(containerized)应用程序的开源系统。它适用于多种生产环境,包括裸机,内部部署虚拟机,大多数云提供商,以及三者的组合/混合。目前已经从CNCF毕业,已然成为容器编排领域的标准,Kubernete包括以下所列功能:
  • 服务发现
  • 健康检测
  • 实例复制
  • 弹性伸缩、自动扩展
  • 负载均衡
  • 自动部署和回滚
  • 资源监控
  • 调试应用程序
  • 提供认证和授权
  • ……


如何推动应用落地Kubernetes?

上面列举Kubernetes能实现如此之多功能,那么到底应该如何快速落地?经团队商议研究简单归纳总结了以下五大痛点:
  • 变更不能太大(包括开发修改难度、原发布系统修改、日志访问等)
  • 需要解决哪些问题?(如:Dubbo连接,网络等)
  • 如何快速安装扩容节点?
  • 如何保证高可用?(如:集群等)
  • 监控告警如何做?


如何做到变更不能太大?

尽可能减少开发人员代码变改,不能单纯地为了上容器而推翻原有代码。如涉及到代码变更或需重构过大,会影响业务开发进度,进而加慢Kubernetes落地速度。同时建议Dockerfile编写尽可能掌握在运维手上,减少开发人员学习成本,同时有效减少分层问题发生。

兼容原来发布系统,在此采取新增容器发布页面,原来应用发布方式保留,应用在Jenkins构建过程中推送多一份镜像到Harbor仓库,原来的压缩包方式保留。

简单画了下架构图如下所示:
4.png

发布过程此处并没有使用Helm,当然Helm是管理Kubernetes应用程序非常友好的打包工具。发布平台发布主要是基于Kubernetes Api调用执行指定的yaml文件,进而达到更新、回滚、重启效果,具体可参考:https://github.com/kubernetes-client/python
5.png

6.png

日志访问,兼容原有日志访问方式,原来的日志采取上传到阿里云的日志服务,上容器后保留原有的方式,同时为了保证磁盘IO问题,日志采取不落盘模式(建议大家根据司情出发,如原使用EFK方式查看,可以兼容原有系统,毕竟让开发去改变已经习惯的事情时候,还是需要点时间适应)。
7.png

具体架构图如上所示:Java/Node --> Syslog--> Logstash--> Kafka --> Logstash --> 阿里云日志服务

网络问题如何解决?

  1. 注册中心(如Dubbo或Eureka)的注册IP网络问题等可以采取路由跳转方式解决
  2. DNS采取Kubernetes集群内CoreDNS+原来外置自建DNS方式,原内网域名依然支持使用
  3. 为了减少发布过程网络推送慢问题,本地和生产采取Harbor自带复制模式,镜像推送后自动同步到生产仓库,减少异地拉取镜像慢问题出现。


如何快速安装扩容节点?

Node节点部署方式主要采取基于Ansible快速安装,建议初学者采取二进制安装一次集群,主要加深各组件认知,以便出现问题时能快速定位问题所在。
8.png

Pod伸缩提供变更页面。
9.png

如何保证高可用?

首先保证组件高可用,特别是Master组件高可用,具体可参考:https://k8smeetup.github.io/do ... lity/

为何上面强调建议二进制安装一次,主要加深对下图(来源于网络)每个组件的认识。
10.png

在Master组件中需保证的高可用组件包括:Apiserver(提供认证、授权、访问控制、API注册和发现等机制)、Controller Manager(负责维护集群的状态,比如故障检测、自动扩展、滚动更新等)、Scheduler(负责资源的调度),可以采取手段为:Haproxy+ Keepalived(如果是使用云服务器也可使用相应的负载均衡器,例如阿里云的SLB)
  • Keepalived提供Kube-apiserver对外服务访问的VIP
  • Haproxy提供健康检查和负载均衡功能,后端服务为Kube-apiserver


保证etcd数据库高可用,etcd保存了整个集群的状态,基本上核心不能再核心的组件了。所以推荐部署多节点,组成etcd集群模式,在etcd高可用集群中可挂节点数为(n-1)/2个,所以推荐部署3个节点或以上,同时养成良好备份习惯,定时备份。注意下v2和v3版本数据结构完全不同,互不兼容,各自创建的数据只能使用对应的版本访问。

保证镜像仓库高可用,Harbor高可用可包括以下方案,公司采取两者混合使用(测试高可用仓库-- > 生产高可用仓库):
  • 多实例共享后端存储(采取挂载文件系统方式)
    11.png
  • 多实例相互数据同步(基于镜像复制模式)


进行容灾演练,提前预知风险问题点,可以参考以下图(篇幅问题截取部分内容),具体可依据司情制定方案:
12.png

监控告警如何做?

监控方面采取主流监控方案Prometheus,Prometheus是一个云原生计算基础项目,是一个系统和服务监控系统。目前Prometheus已经从CNCF孵化完成,应该可以说是容器云场景中监控的首选方案,具体架构图如下:
13.png

安装方式采取用了Prometheus-operator,当然也推荐使用Helm chart安装部署,可参考:https://github.com/coreos/prometheus-operator

网页图形展示使用Grafana UI如下所示:(截取测试环境某台Node)
14.png

告警方案:如上面的架构图所示,Alertmanager通过配置Webhook告警信息发送到监控平台,开发或者运维人员到监控平台订阅相关指标即可实现推送。
15.png

16.png

微信接收告警如下所示:
17.png

后期将要做些什么?

  1. 进一步提高应用容器化接入率
  2. 完善容器接入CMDB平台数据
  3. 评估是否需要引入服务网格,将服务治理能力降到基础设施层面
  4. 容器计费系统,把运维成本转化为开发业务部门上,记录业务所花费资源


Q&A

Q:Helm如何落地?是否有方案开发替代的系统完成版本管理功能?
A:暂时没有使用Helm,公司使用版本管理是通过调用官方API接口来实现更新、回滚、重启等操作。

Q:你们部署Kubernetes应用,是有用到通用的yaml模板结合Helm使用吗?
A:是的,使用通用的yaml模板,但是并没有使用Helm。首先在运维平台网页上配置相关参数,发布时候传入变量值,例如启动参数、镜像地址、等生成yaml配置,然后通过API方式调用来实现部署应用。

Q:请问从虚拟机正式环境迁移到Kubernetes正式环境,需要做些什么准备,迁移过程会不会中断业务,数据库如何切换?
A:不需要中断任务,应用部署后验证没有问题才切换负载,数据库其实不需要做啥操作,如果你是问数据库上容器的话,这块暂时还没有迁移上去。

Q:前端和后端是不是改造完全分离的,有没有耦合在一起的项目,这些项目能用Ingress吗?
A:大部分项目前后端分离,耦合一起的也能用,关键如何做好转发,现在逻辑上是SLB-->负载层-->Ingress->-Service-->Pod。

Q:生产部署二进制还是kubeadm?
A:开发、测试、预发布、生产环境都是使用二进制安装,主要基于Ansible剧本安装,只需要修改部分地址变量(例如vip、etcd地址等)即可。

Q:你们公司有做蓝绿发布或金丝雀部署吗?在容器云平台上是通过什么方式去实现的?
A:金丝雀部署功能已提供,容器这块暂时还没有开放出去,跑在原来服务器的已开发,不过公司有点特殊,金丝雀暂时只开放给测试人员测试使用。方式有以下两种:
  • 不同的入口,测试人员可以通过切换hosts。
  • 浏览器设置header参数即可,负载层会判断来源实现不同转发。


Q:平时这么多微服务的yml文件是如何管理的?通过什么方式编辑和修改?
A:文件其实是不存在的,是直接脚本生成yaml数据,通过API调用,Python脚本会写好基本变量,只需要传值即可,脚本截取部分你应该能看明白。
18.png


Q:一个微服务yml文件是Deployment和SVC配置一起,还是分开的2个文件?
A:文件其实是不存在的,是直接脚本生成yaml数据,通过API调用。

Q16:etcd看到v2的数据和v3的数据备份方式不一样。如何一起备份?是直接拷贝任意节点的数据文件备份就行了么?
A:备份需要了解网络和Pod数据存放在v2还是v3,明白了就可以确定哪些需要备份了,容器的IP对业务应该来说是不影响的,也就是说网络地址变更后,业务还是可以正常运行。

Q:网络用的Canal还是Flannel?有测试过性能么。能否满足需求?
A:网络使用Flannel,测试过暂时满足性能需要,后继这块有考虑替换其他,但短时间先不动为主。

Q:有让开发人员看监控么?比如说资源使用情况?
A: 监控平台是会开放出去的,开发人员能看到对应的Pod使用情况。

Q:请问,那个管理告警并发送告警监控平台是怎么设计和实现的?
A:告警发送到监控平台不难,监控平台提供接口,数据过来做过滤存库处理,监控平台通过调用微信企业通讯录,绑定工号,发送也是调用API接口,并没有其他,只是简单做了合并收敛,5分钟内非级别为高的,统一合并发送。

以上内容根据2019年8月20日晚微信群分享内容整理。分享人林文杰,广州博鳌纵横网络科技有限公司(即汇桔网)运维开发工程师,负责运维平台研发和部分系统运维工作,减轻系统运维部分重复性操作,推动公司应用容器化落地。DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiese,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

0 个评论

要回复文章请先登录注册