一、引言

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

二、 为何要上容器?

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

2.1、随着公司业务高发展,市场变化莫测,业务也要及时作出反应,这要求我们需要更快速的交付和部署。
2.2、系统资源利用率可提升空间大,随着业务规模不断扩大后,会引起服务器资源浪费。
2.3、系统环境多,久而久之存在环境差异严重的可能性增大,影响业务交付效率,同时环境相对较复杂,维护管理成本较大。
综上所述3大原因导致运维团队迫不及待推进容器云平台,主要为了达到以下三大点收益:

三、容器编排如何选择?

通过对比现阶段几个主流编排工具优缺点,从生产经验、学习和运维成本几个维度后,公司运维团队成员在技术选型上毅然一致性选择kubernetes。Kubernetes(简称为K8s)是用于自动部署、扩展和管理容器化(containerized)应用程序的开源系统。它适用于多种生产环境,包括裸机,内部部署虚拟机,大多数云提供商,以及三者的组合/混合。目前已经从CNCF毕业,已然成为容器编排领域的标准,Kubernete包括以下所列功能:

  • 服务发现
  • 健康检测
  • 实例复制
  • 弹性伸缩、自动扩展
  • 负载均衡
  • 自动部署和回滚
  • 资源监控
  • 调试应用程序
  • 提供认证和授权
  • ……

四、如何推动应用落地kubernetes?

上面列举kubernetes能实现如此之多功能,那么到底应该如何快速落地?经团队商议研究简单归纳总结了以下五大痛点:

  • 变更不能太大(包括开发修改难度、原发布系统修改、日志访问等)
  • 需要解决的问题?(如:Dubbo连接,网络等)
  • 如何快速安装扩容节点?
  • 如何保证高可用?(如:集群等)
  • 监控告警如何做?

4.1 如何做到变更不能太大???

4.1.1 尽可能减少开发人员代码变改,不能单纯地为了上容器而推翻原有代码。如涉及到代码变更或需重构过大,会影响业务开发进度,进而加慢kubernetes落地速度。同时建议Dockerfile编写尽可能掌握在运维手上,减少开发人员学习成本,同时有效减少分层问题发生。
4.1.2 兼容原来发布系统,在此采取新增容器发布页面,原来应用发布方式保留,应用在Jenkins构建过程中推送多一份镜像到harbor仓库,原来的压缩包方式保留。

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

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

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

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

4.2网络问题如何解决???

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

4.3如何快速安装扩容节点???

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


4.3.2 Pod伸缩提供变更页面

4.4如何保证高可用???

4.4.1 首先保证组件高可用,特别是Master组件高可用,具体可参考https://k8smeetup.github.io/docs/admin/high-availability/
为何上面强调建议二进制安装一次,主要加深对下图(来源于网络)每个组件的认识。

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

  • Keepalived提供 Kube-apiserver 对外服务访问的 VIP
  • Haproxy提供健康检查和负载均衡功能,后端服务为 Kube-apiserver

4.4.2 保证Etcd数据库高可用
Etcd保存了整个集群的状态,基本上核心不能再核心的组件了。所以推荐部署多节点,组成Etcd集群模式,在Etcd高可用集群中可挂节点数为(n-1)/2个,所以推荐部署3个节点或以上,同时养成良好备份习惯,定时备份。注意下v2和v3版本数据结构完全不同,互不兼容,各自创建的数据只能使用对应的版本访问。
3.4.3保证镜像仓库高可用
Harbor高可用可包括以下方案,公司采取两者混合使用(测试高可用仓库– > 生产高可用仓库)

  • 多实例共享后端存储(采取挂载文件系统方式)
  • 多实例相互数据同步(基于镜像复制模式)
    4.4.4进行容灾演练,提前预知风险问题点,可以参考以下图(篇幅问题截取部分内容),具体可依据司情制定方案:

4.5 监控告警如何做???

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

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

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

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


微信接收告警如下所示:

五、 后期将要做些啥?

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

当然也可以查看:https://blog.csdn.net/M2l0ZgSsVc7r69eFdTj/article/details/100072142

Comments

2020-02-13