DockOne微信分享(二一四):震坤行的容器云实践


【编者的话】本文通过分享 Kubernetes 的好处,说明使用 Kubernetes 是震坤行的必然选择,重点讲解安装 Kubernetes 以及目前震坤行的容器云平台实践,最后分享震坤行的微服务架构实践。

我们为什么要用Kubernetes

拥抱微服务

微服务架构将巨大单体式应用分解为多个服务,每个服务通过 RPC 或者API 进行通信,具备了各个自服务容易开发、维护的优点,另外子服务还具备独立部署、快速扩展等优点。Kubernetes 对微服务本身有很好的支持,应用本身通过Deployment 进行部署,各个服务运行在 Pod 中,Pod 之间服务通过 Service 具备的服务发现实现相互间的通信。同时微服务架构也恰好是云原生应用的一种体现。

容器编排

Kubernetes 帮助使用者通过简单易用的 API 高效地管理成千上万个运行在容器中的微服务。Kubernetes 在 1.6 版本中已经支持 5000 个节点,这也说明 Kubernetes具备大规模集群的编排管理能力。同时,Kubernetes 还具备包括监控、日志、包管理等各种完善而专业的工具链,这将大大减轻运维和开发人员的负担。

服务注册发现

微服务的实践过程中存在各种服务依赖关系,因此服务的注册发现十
分重要。Kubernetes 对服务进行抽象,通过抽象的服务层动态地解析到对应的容器服务。Kubernetes 同时提供了 DNS 和环境变量两种方式,帮助实现服务的注册和发现,Kubernetes 早期版本中使用的环境变量方式实现,现在 Kubernetes 则默认使用 DNS,通过使用 DNS 将服务名称解析为服务的 IP 地址,然后 Proxy 转到对应的 Pod。

主机资源利用率

Kubernetes 对主机的资源利用率,也是一种提升,基本上物理机,ECS,EC2,主机的利用率通常都在30%左右,极大的浪费了资源。使用 Kubernetes 后,可以根据主机资源使用情况,自动的调度 Pod 运行到那台机器上。可以极大的提高主机的资源利用率。

弹性扩容

例如我们新上线的应用,因不同的业务场景,初次上线的时候不太确定给多少资源,默认就给应用 4G 内存,在 Kubernetes 中我们可以根据内存的使用率,来定义是否启动一个新的 Pod,以及 Pod 最少多少个,最多多少个。

应用横向扩展

例如我们应用在在访问资源高峰期,应用需要进行添加机器,如果在 ECS、EC2 等机器,就需要再安装服务呀,配置负载之类的,在容器中就简单多了,直接修改ReplicaSet,修改节点数量,就会根据镜像自动启动新服务。

使用 Kubespray 安装 Kubernetes

使用 Kubespray 安装 Kubernetes 比常规要方便很多,配置完 ssh-ke y后,直接使用 Ansible 就可以快速的添加节点,删除节点。
  1. 安装 Ansible
  2. 集群配置,修改镜像源
  3. 部署 Kubernetes 集群
  4. 安装 SVC Ingress
  5. 安装 Helm
  6. 添加节点


我们使用容器云平台

我们最早也是 LAMP,LNMP 平台,后来因服务器数量众多,服务器多数靠各项目的开发和运维进行管理,没有统一的 CMDB,同时服务器资源利用率也不高,有很大的资源闲置和资源浪费。我们是从 18 年 8 月份开始使用容器的。目前 60% 的业务都运行在容器平台上。目前业务正在向容器云平台迁移中。

如何建设 DevOps 平台

DevOps 平台整体架构如下:

部署流程的优化:
1.png


整体的架构流程如下:
2.png

我们建设基于 Kubernetes 容器云平台,目标就是希望能够提高研发人员从代码构建到业务上线的整体效率。这个过程是一个完整的 CI/CD 流程,包括从开发人员提交代码,进行代码 Review,到代码编译、单元测试、集成测试,最后构建出业务镜像,在不同的环境中部署业务,上下线服务等各个环节,形成统一的应用生命周期管理。

左侧是持续集成框架,其中由应用基线管理、代码编译、单元测试、发布系统等模块组成。中间是多集群统一管理平台。业务会分别在开发、预发和生成三个不同的环境中部署。业务的最上层是由 SLB 软负载统一管理 DNS、Nginx、LVS 等组件,将业务流量转发给不同 Kubernetes 集群中的业务容器。基于 Kubernetes 的 CaaS 由多集群管理、镜像管理、权限管理、服务发现等子模块组成。

右边是自研的监控告警系统和运维对接平台,包括监控平台、日志平台和运维 CMDB 等系统

镜像管理

我们是使用的 Harbor 作为自己的镜像仓库,目前都集中在阿里云,我们的服务都是基于基本的 JDK、Tomcat、Nginx、PHP、Nodejs等基于镜像起来的,我们只需要维护这几个基础镜像就可以。

权限管理

用户的容器集群由权限模块进行管理,目前提供给开发的只有日志查询权限,账户与公司的 LDAP 对接。目前不支持虚拟账户的认证。

服务发现

我们是在各个项目中,单独引用了一个自己写的 jar 包,在 jar 包中定义了注册中心地址。

稳定性

目前我们容器云平台,dev 环境是自建的,UAT 和 PRO 都是使用的阿里云。关于容器监控我们额外做了 Prometheus + Alerting 关联钉钉机器人和微信报警。除了应用本身的错误外,整个容器云平台没有出现过因服务类的 down 机情况。

成本

降低机器成本和运维成本是一项长期艰苦的工作,我们在迁入容器云的过程中发现资源利用较好的两种情况。
  1. 混合调度。我们在提高容器部署的密度后,对业务带来的好处就是快速扩展和资源混合利用,我们多条线的 Pod 会集中在一台实例中,可以很好的提高单机资源利用率。
  2. 弹性能力。电商行业的特征决定了每年都会出现 618,双 11,双 12 等峰值流量。因为,在大促销期间动态的租用公有云服务,在平时只保留满足日常流量的机器即可。


微服务架构

3.png

我们现在的微服务架构基本上也是多数公司的微服务架构,都是 Zuul + Eureka + Apollo 来完成了,Eureka本身有个监测机制,例如我的容器 A1、A2 注册到了 Eureka,此时要部署容器,例如新部署的容器要 B1、B2,在健康检查完全通过后,A1、A2已经被替换掉。在 Kubernetes 层面做到了无缝切换,但是 Eureka 本身还会将 A1、A2 保留约 2 分钟。也就是这个时间内,Eureka(注册中心)会同时存在 4 个 Pod。

在这个时间点通过 Zuul 来访问服务的话,则会有 50% 的请求发布到老地址上去。推荐更换掉 Eureka,使用 Istio,Istio 可以避免这个问题。

我们现在正在替换掉 Eureka,向 Istio 迁移。

Istio 具备统一的入口。
  1. 动态服务发现和路由规则
  2. 负载均衡
  3. 策略和请求tracing
  4. 熔断器
  5. 健康检查,基于百分比流量拆分和灰度发布
  6. 认证和鉴权


我们左侧注册中心,到时候这一块就会被砍掉,包括前端的网关,也会使用 Istio 来代替。目的是为了灰度发布这一块。

Q&A

Q:Kubernetes 云平台和物理机平台,在性能对比上,Kubernetes 差多少?
A: Kubernetes 的最小单元是 Pod,Pod 是跑在云主机上的。整个 Kubernetes 都是基于云主机/物理机来完成的。

Q:数据库集群是否适合丢在 Kubernetes 上,如果千万级的日活是否有好的解决架构?
A: 首先数据库是可以跑在 Kubernetes 上的,数据库集群直接互连的 IP 是可以通过 Kubernetes 的内部 .svc.cluster.local 来代替。如果跑数据库集群,则需要将 Pod 使用硬盘 volume mount 将数据映射到硬盘上。目前我们 DEV,UAT 环境的数据库在集群中。针对千万级的日活,主要是看瓶颈卡在那一块。

Q:根据你的描述:你们是从 18 年 8 月份开始使用容器的,到现在一共是 11 个月,把 Kubernetes 这套生态落地到生产,你们的筹备是几个阶段,然后难点是什么?是否发生重大的生产事故,怎么处理的?你们的后端存储使用的是商业存储数据库还是自己搭建的 Ceph 等开源数据库?电商活动临时购买阿里或者腾讯云机器,新增不同机房 Node 节点之间网络延迟如何解决的?
A:我们是分为了三个阶段,一个是测试 Kubernetes,一个是测试业务接入,一个是测试接入业务的稳定性。难点就在于以前的架构整改,包括 Kubernetes 结合微服务。重大的生产事故未发生过,因为涉及到 Ingress、网关等入口服务,一般都是多备份。我们后端的数据库,是在阿里云购买的,DEV,UAT 数据库是开源自建的。电商活动前,我们一般是会购买按量付费的机器,我们购买的都是阿里云。

Q:生产环境会跟着社区版本积极更新 Kubernetes 版本不?或者什么频率?
A:这个一般不会跟着社区积极更新,除非是当前版本出现重大bug,或者新功能比较适用于我们,才会考虑更新。

Q:Istio 有没有进行优化,QPS 大概是多少?如有优化都是从那些方面进行优化的?
A:Istio 目前是进行过优化的,优化的细节暂时还未统计。当前的 QPS 我们大约是每秒 5000 个左右吧。更具体的要看业务。

Q:有在用统一的文件存储吗?不同用户间会考虑做隔离不?
A: 统一的文件存储有,但是目前主要是拿来放日志,共享等。不通用户间的隔离不太清楚是啥意思,但是每个 Pod 之间是隔离的。我们在 DevOps 平台是有权限管理模块的。

Q:问下你们的日志采集方案是怎么做的?日志是否写在容器里?另外再问下 Kubernetes 的 CRI 是用的 Docker 吗?还是用其他的,谢谢。
A:日志收集是通过 ELK + 二次开发来完成的。 日志也会也在容器里,写容器里边随着下一次发布日志就会消失。是 Docker。

Q:Eureka 和 Istio 不是同一类东西吧,作用都不一样,怎么理解替换不替换?
A:看架构类型用到那个组件吧,Istio本身具备服务发现功能,我们刚好是服务发现这一块有问题。

Q:你们的 Kubernetes 集群节点规模有多大?日活?Kubernetes 运维团队多少人?
A: Kubernetes 集群节点有,dev 24台 4C 32G,UAT 30台 4C 32G,生产 67台 8C 64G,Kubernetes 运维团队2个人。

Q:更换成 Istio 之后,就不需要单独部署 Ingress 了吧?
A:需不需要不用 Ingress,具体还是得看下业务类型。我们是微服务 API 类的,走的 Istio,静态页面类,CDN --> Ingress 。或者是CDN --> SLB --> Pod。

Q:请问 Kubernetes 如何和云服务的弹性伸缩配合使用,例如,因为业务需要,短时间内从 2 台节点扩展到十多台节点。可以做到像云服务的弹性伸缩那样吗?不提前配置节点,或者如何让 Kubernetes 自己触发云服务的弹性,自动添加云服务的弹性节点。
A:我们一般会对容器云的 ECS 资源保留 20%-25%。如果发现资源不够了,就会提前购买 ECS 加进去。短时间扩容 Node 几点的话,就多购买几台 ECS 同时加进去就可以了。Pod 是可以做弹性伸缩,ECS云主机也可以做弹性伸缩增加到 Kubernetes 集群里边,这个阿里云提供服务的。

Q:Eureka 是类似 Dubbo 的注册中心吗?
A:是的,Eureka 也提供页面,可以查看到有多少个服务注册进来。

Q:请问一下注册到注册中心的 IP 是容器内 IP 的问题如何解决?
A:我们是将注册中心部署到 Kubernetes 集群中的。注册中心的内网 IP 和 Kubernetes 的内网是互相可以通信的。

以上内容根据2019年7月2日晚微信群分享内容整理。分享人雷广岩,震坤行工业超市(上海)有限公司高级运维工程师,负责公司容器云集体架构。DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiese,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

0 个评论

要回复文章请先登录注册