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 平台整体架构如下：

部署流程的优化：

整体的架构流程如下：

我们建设基于 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 等峰值流量。因为，在大促销期间动态的租用公有云服务，在平时只保留满足日常流量的机器即可。

微服务架构

我们现在的微服务架构基本上也是多数公司的微服务架构，都是 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，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。