运营商业务系统基于 KubeSphere 的容器化实践

本篇文章是 KubeSphere 2020 年度 Meetup 上讲师宋磊分享内容整理而成。

大家好，我是宋磊，在运营商的一个科技子公司任职，主要做大数据业务。我主要负责公司的 IaaS 层和 PaaS 层的建设和运营的工作，涉及到两个层面。因为 Kubernetes 是一个非常全面的技术体系，并不是我们部署了一个集群把业务放上去就能开箱即用，涉及到很多方面，比如服务器、网络、存储，还有一系列的工具链的支持，我们才能真正的去投产，所以我们团队是比较适合做这件事的。

业务类型和实践架构

我们目前有三种类型的业务：

1.接口的服务，容量占比是比较大的一块

2.APP 的应用

3.外部的应用系统，主要做智慧政务、智慧生态、智慧城市、智慧旅游等业务

这三个类型的业务，整体的 TPS 的峰值大约在 2500，平均在 1500 左右。

我们整体的集群规模：我们所有的集群都是以物理服务器进行部署的，生产集群有 50 个物理节点，测试的集群有 20——30 个节点，整体的 Kubernetes 集群的规模不到 100 个物理节点。

上面这张图是我们 Kubernetes 的实践。

IaaS 层：

数据中心物理层的网络是 SDN 加 VXLAN 的架构，后续对于网络插件的选型是有考虑的。

存储这一块我们主要是对接 Ceph，我们有一个比较大的 Ceph 集群，大概有 50 个物理节点，其中对接层不单单跑了 KubeSphere 的这些业务，还跑了一些 OpenStack 的虚拟机。我们在 Ceph 上面做了一些数据的分层，闪存盘(存放集群元数据)和 SATA 盘(存放真正的数据)，也做了一些数据的热度分层，然后以 KubeSphere 为中心的容器集群周边做了很多对接的工具链。这其中的一些工具链不是容器化的，而是外链的，比如说 CMDB 配置管理，Prometheus 的监控，Skywalking 主要做微服务的全链路监控，还有一些日志的采集分析，主要还是以 ELK 的工具链为主，也是在 KubeSphere 集群之外的，DevOps 这层是基于 Jenkins 的 pipeline 去做的。

然后流量入口这一块，因为我们所有的业务类型都是互联网性质的，所以我们在互联网区域有一个整体的 Nginx 的集群，主要做业务的路由分发和流量的集中控制。

存储和网络的选型与实践

网络

上文已经提到我们的物理网络已经是 SDN 加 VXLAN 的大二层的租户性质，所以对于 KubeSphere 的网络插件的选型，目前主要就两种——Calico 和 Flannel。

Flannel 本身就是基于 VXLAN的，如果选择它的话，相当于我们两个层面——物理网络和 Kubernetes 网络都是 VXLAN，这就涉及到两次层面的封包和解包的问题，对性能还是有一定的影响的，所以我们最终还是选择了 Calico 这种纯三层的 BGP 的网络，然后做网络的插件。

存储

目前我们主要对接的是 Ceph 的块存储，服务于一些有状态的服务，比如我们会做一些 helm 的镜像，主要是 Zookeeper、Redis、MySQL。但是这些有状态的服务主要是在测试集群，给开发测试人员使用的。生产环境主要是一些无状态的服务，比如分布式框架的 Java微服务应用，还有 Python 和 go。go 主要是用来做区块链，因为现在区块链跟 K8s 结合是非常有必要的业务类型。

但是 RBD 块存储有局限性，我们很多业务需要多个 Pod 或者多个容器共同读写某一块存储，但块存储是实现不了的，后续我们还会有对象存储和网络存储（NFS）的对接。

DevOps 和日志采集的实践

CI/CD 这块，底层是 Jenkins，没有集成到 KubeSphere 里，因为我们之前有一个 Jenkins 的 Master 和 Slave 的架构的平台，基于 pipeline，镜像直接打到 Kubernetes 集群，做自动化的 CD。

日志采集相对来说会麻烦一点，目前对接的 ELK 的工具链，底层主要是采集三种类型的日志，宿主机日志、Pod 业务日志和 Kubernetes 组件相关的日志。宿主机和 Kubernetes 组件日志都是基于宿主机采集。

Pod 业务日志的采集，主要有两种方式：

在 Pod 里加一个 Sidecar 的容器
在一个业务容器里起两个服务，前台服务是 Java 的微服务，后台是采集的 Filebeat 的 agent，然后将采集agent直接打到镜像里运行

ELK 的工具链是比较成熟的工具链了，可以参见上图。

灰度发布

我们是以两种形式来进行灰度发布。

针对小版本迭代

基于权重，通过 Kubernetes 控制器的副本特性来做灰度发布。一个业务中有多个副本，先灰度发布一两个，没有问题就继续灰度发布，如果有问题就回退。这种方式是比较常规的。
针对大版本迭代

使用业务灰度方式。针对用户的 HTTP 请求的头部以及 body 里用户的 ID，通过 Nginx 和 lua 脚本，分发到不同的版本上面去。

服务治理

我们对于服务治理这块后续可能会有一些需求，目前没有一种特别好的实践方式。

目前来说我们对于微服务治理都是基于辅助的手段，比如全链路监控，日志的指标，来做微服务的流量控制和垄断。后续我们想往服务网格上探索，把流量的监测和控制放在平台层，开发只需要专注于业务的逻辑，目前还没有比较好的落地方案。

本文由博客一文多发平台 OpenWrite 发布！