关于云计算:运营商业务系统基于-KubeSphere-的容器化实践

6次阅读

共计 2107 个字符，预计需要花费 6 分钟才能阅读完成。

本篇文章是 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）的对接。

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 脚本，散发到不同的版本下面去。

咱们对于服务治理这块后续可能会有一些需要，目前没有一种特地好的实际形式。

目前来说咱们对于微服务治理都是基于辅助的伎俩，比方全链路监控，日志的指标，来做微服务的流量管制和垄断。后续咱们想往服务网格上摸索，把流量的监测和管制放在平台层，开发只须要专一于业务的逻辑，目前还没有比拟好的落地计划。