Kubernetes 几种存储方式性能对比

存储 存储设备
本文展示了一个简单的存储对比,使用未经性能优化的多种存储提供的存储卷进行测试和比较。

 摘要

本文展示了一个简单的存储对比,使用未经性能优化的多种存储提供的存储卷进行测试和比较。

忽略 Azure 的原生 PVC 或 hostPath ,我们可以得出如下测试结果:

  • Portworx 是 AKS 上最快的容器存储。
  • Ceph 是私有云集群上最快的开源存储后端。对公有云来说,其操作太过复杂,这些多余的复杂性并没有能提供更好的测试表现。
  • OpenEBS 的概念很棒,但是其后端需要更多优化。

如果你正在运行 Kubernetes,你可能正在使用,或者准备使用动态供给的块存卷 ,而首当其冲的问题就是为集群选择合适的存储技术。这个事情并不能用一个简单的测试来做出简单的回答,告诉你目前市面上比较好的技术是什么。存储技术的选择过程中,集群上运行的负载类型是一个重要的输入。对于裸金属集群来说,需要根据实际用例进行选择,并集成到自己的硬件之中。公有云中的托管 K8s,例如 AKS、EKS 或者 GKE,都具有开箱可用的块存储能力,然而这也不见得就是很好的选择。有很多因素需要考虑,比如说公有云的 StorageClass 的故障转移时间太长。例如在 一个针对 AWS EBS 的故障测试中,加载了卷的 Pod 用了超过五分钟才成功的在另一个节点上启动。Portworx 或者 OpenEBS 这样的云原生存储产品,正在尝试解决这类问题。

本文的目标是使用最常见的 Kubernetes 存储方案,进行基本的性能对比。我觉得在 Azure AKS 上使用下列后端:

  • AKS 原生 Storageclass:Azure native premium
  • 使用 cStor 后端的 OpenEBS
  • Portworx
  • Heketi 管理的 Gluster
  • Rook 管理的 Ceph

现在我们来介绍每种存储后端,并交代一下安装过程,然后进入 AKS 测试环境进行测试,最后得出结果。

存储

这一节中介绍测试中用到的存储方案,包含安装过程以及该方案的优缺点。

Azure 原生 StorageClass

我选择这一方案的动机是以此作为所有测试的基线。这个方案 应该 提供优质性能。Azure 动态的创建托管磁盘,并把它们映射到 K8s 的虚拟机中,最终成为 Pod 的存储卷。

这个方案很方便,什么多余的步骤都不需要。创建一个新的 AKS 集群之后,就自动提供了两个预定义的 StorageClass,分别是 default 和 managed-premium ,premium 使用的是基于 SSD 的高性能低延迟磁盘。

 

  1. $ kubectl get storageclassesNAME                PROVISIONER                AGEdefault(default)   kubernetes.io/azure-disk   8mmanaged-premium     kubernetes.io/azure-disk   8m$ kubectl get pvcNAME              STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGEdbench-pv-claim   Bound     pvc-e7bd34a4-1dbd-11e9-8726-ae508476e8ad   1000Gi     RWO            managed-premium   10s$ kubectl get poNAME           READY     STATUS              RESTARTS   AGEdbench-w7nqf   0/1ContainerCreating029s 

优点

AKS 开箱即用。

缺点

故障转移非常缓慢,有时需要十分钟以后,存储卷才能重新挂载到不同节点上的 Pod 里。

OpenEBS

对我来说 OpenEBS 是个全新事物,因此我很有兴趣做他的测试。他提出了一个新的 Container Attached Storage(容器挂载存储) 概念,这是一个基于微服务的存储控制器,以及多个基于微服务的存储副本。他和 Portworx 同样,属于云原生存储分类的成员。

它是一个完全开源的方案,目前提供两种后端——Jiva 和 cStor。我最开始选择的是 Jiva,后来切换到 cStor。cStor 有很多长处,例如他的控制器和副本被部署到单一的 OpenEBS 所在的命名空间之中,能够管理原始磁盘等。每个 K8s 卷都有自己的存储控制器,能在节点存储容量的许可范围内对存储进行扩展。

在 AKS 上运行

在 AKS 上的安装非常容易。

  1. 连接到所有 K8s 节点上,安装 iSCSI,这是因为他需要使用 iSCSI 协议在 K8s 节点之间进行 Pod 和控制器的连接。apt-get update apt install -y open-iscsi
  2. 使用一个 YAML 定义在 K8s 集群上完成部署:kubectl apply -f https://openebs.github.io/charts/openebs-operator-0.8.0.yaml
  3. 下一步,OpenEBS 控制器发现了节点中的所有磁盘。但是我必须手工标识出我附加的 AWS 托管磁盘。$ kubectl get disk NAME AGE disk-184d99015253054c48c4aa3f17d137b15m disk-2f6bced7ba9b2be230ca5138fd0b07f15m disk-806d3e77dd2e38f188fdaf9c46020bdc5m
  4. 然后把这些磁盘加入 StoragePoolClaim,这个对象会在 StorageClass 中进行引用:--- apiVersion: storage.k8s.io/v1 kind:StorageClass metadata: name: openebs-custom annotations: openebs.io/cas-type: cstor cas.openebs.io/config - name:StoragePoolClaim value:"cstor-disk" provisioner: openebs.io/provisioner-iscsi --- apiVersion: openebs.io/v1alpha1 kind:StoragePoolClaim metadata: name: cstor-disk spec: name: cstor-disk type: disk maxPools:3 poolSpec: poolType: striped disks: diskList: - disk-2f6bced7ba9b2be230ca5138fd0b07f1 - disk-806d3e77dd2e38f188fdaf9c46020bdc - disk-184d99015253054c48c4aa3f17d137b1

完成这些步骤之后,就可以用 K8s 的 PVC 来动态的创建存储卷了。

优点

  • 开源
  • Maya 在资源使用的可视化方面做得非常好。可以在 K8s 中部署多个服务,方便的为集群的各方面数据设置监控和日志。对于排错工作来说,这十分重要。
  • CAS 概念:我非常欣赏这一概念,我相信这是未来的趋势。
  • OpenEBS 社区:在社区中我的任何问题都能在几分钟内得到解决。Slack 上的团队非常有帮助。

缺点

  • 不成熟:OpenEBS 还很年轻,目前还没有发布稳定版。核心团队还在进行后端的优化,未来几个月里会对性能做出很大提升。
  • Kubelet 和存储控制器之间的 iSCSI 连接是通过 K8s Service 进行的,这在 Tungsten Fabric 之类的 CNI 插件环境中可能会出问题。
  • 需要在 K8s 节点上安装额外的软件(iSCSI),这对于托管集群来说非常不便。

注:OpenEBS 团队对我的案例场景进行了调整:

https://github.com/kmova/openebs/tree/fio-perf-tests/k8s/demo/dbench

Portworx

Portworx 是另一个面向 Kubernetes 的容器原生存储方案,它专注于高度分布式的环境。这是一个主机可寻址的存储,每个卷都直接映射到挂在的主机上。他提供了基于应用 I/O 类型的自动微调能力。 官方网站 提供了更多信息。不幸的是,它也是本文中唯一的非开源产品。然而它提供了 3 节点的免费试用。

在 AKS 上运行

在 AKS 上的安装同样简单,我用了他们 网站 提供的生成器。

 

  1. azure0 

 

  1. $ kubectl get pods -o wide -n kube-system -l name=portworxNAME             READY     STATUS    RESTARTS   AGE       IP          NODE                       NOMINATED NODEportworx-g9csq   1/1Running014m10.0.1.66   aks-agentpool-20273348-2<none>portworx-nt2lq   1/1Running014m10.0.1.4    aks-agentpool-20273348-0<none>portworx-wcjnx   1/1Running014m10.0.1.35   aks-agentpool-20273348-1<none> 

为 PVC 创建一个 StorageClass,定义高优先级,以及三个副本:

 

  1. root@aks-agentpool-20273348-0:~# kubectl get storageclass -o yaml portworx-scapiVersion: storage.k8s.io/v1kind:StorageClassmetadata:  creationTimestamp:2019-01-28T21:10:28Z  name: portworx-sc  resourceVersion:"55332"  selfLink:/apis/storage.k8s.io/v1/storageclasses/portworx-sc  uid:23455e40-2341-11e9-bfcb-a23b1ec87092parameters:  priority_io: high  repl:"3"provisioner: kubernetes.io/portworx-volumereclaimPolicy:DeletevolumeBindingMode:Immediate 

优点

  • 部署方便:生成器包含配置细节。
  • 不像 Ceph 和 Glusterfs 那样需要进行额外配置。
  • 云原生存储:公有云和裸金属都可以运行。
  • 存储级别感知和应用感知的 I/O 微调。

缺点

  • 闭源:商业解决方案

GlusterFS Heketi

GlusterFS 是知名的开源存储方案,是由 Redhat 提供的开源存储方案。 Heketi 是 GlusterFS 的 RESTful 卷管理界面。它提供了易用的方式为 GlusterFS 卷提供了动态供给的功能。如果没有 Heketi 的辅助,就只能手工创建 GlusterFS 卷并映射到 K8s PV 了。关于 GlusterFS 的更多信息,请阅读 官方文档 。

在 AKS 上运行

根据 Heketi 的 快速入门 文档进行部署。

  1. 参照 样例 ,创建一个包含磁盘和主机名的拓扑文件。
  2. Heketi 主要的开发和测试都在基于 RHEL 的操作系统上,我在 AKS 上使用 Ubuntu 主机时,出现了内核模块路径错误的问题,我提交了一个 PR 来修正这个问题。~~~ +++ b/deploy/kube-templates/glusterfs-daemonset.yaml @@ -67,7 +67,7 @@ spec: mountPath: “/etc/ssl” readOnly: true – name: kernel-modules name: kernel-modules hostPath: mountPath: “/usr/lib/modules” mountPath: “/lib/modules” readOnly: true securityContext: capabilities: {} @@ -131,4 +131,4 @@ spec: path: “/etc/ssl” path: “/usr/lib/modules” path: “/lib/modules” ~~~
  3. 我在 AKS 环境中遇到的另一个问题是一个非空磁盘,所以我用 wipefs 为 glusterfs 进行清理。这个磁盘并未用过。 $ wipefs -a /dev/sdc /dev/sdc: 8 bytes were erased at offset 0x00000218 (LVM2_member): 4c 56 4d 32 20 30 30 31
  4. 最后运行 gk-deploy -g -t topology.json ,会在每个节点上运行 Heketi 控制器管理之下的 GlusterFS Pod。$ kubectl get po -o wide NAME READY STATUS RESTARTS IP NODE NOMINATED NODE glusterfs-fgc8f 1/1Running010.0.1.35 aks-agentpool-20273348-1 glusterfs-g8ht6 1/1Running010.0.1.4 aks-agentpool-20273348-0 glusterfs-wpzzp 1/1Running010.0.1.66 aks-agentpool-20273348-2 heketi-86f98754c-n8qfb 1/1Running010.0.1.69 aks-agentpool-20273348-2 然后我遇到了新问题。K8s 控制面无法使用 Heketi 的 restURL 。我测试了一下 kube dns 的记录,pod IP 和 svc IP 都没有生效。最后只能手工使用 Heketi CLI 来创建存储卷。

 

  1. $ export HEKETI_CLI_SERVER=http://10.0.1.69:8080$ heketi-cli volume create --size=10--persistent-volume --persistent-volume-endpoint=heketi-storage-endpoints | kubectl create -f -persistentvolume/glusterfs-efb3b155 created$ kubectl get pvNAME                 CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGEglusterfs-efb3b155   10Gi       RWX            RetainAvailable 

然后把现存 PV 映射为 PVC,加载给测试 工具 进行测试。

 

  1. kind:PersistentVolumeClaimapiVersion: v1metadata:  name: glusterfs-efb3b155spec:  accessModes:    -ReadWriteMany  storageClassName:""  resources:    requests:      storage:10Gi  volumeName: glusterfs-efb3b155 

 

  1. $ kubectl get pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEglusterfs-efb3b155 Bound glusterfs-efb3b155 10Gi RWX 36m 

Heketi 的更多输出:

 

  1. $ gluster volume info vol_efb3b15529aa9aba889d7900f0ce9849VolumeName: vol_efb3b15529aa9aba889d7900f0ce9849Type:ReplicateVolume ID:96fde36b-e389-4dbe-887b-baae32789436Status:StartedSnapshotCount:0Number of Bricks:1 x 3=3Transport-type: tcpBricks:Brick1:10.0.1.66:/var/lib/heketi/mounts/vg_5413895eade683e1ca035760c1e0ffd0/brick_cd7c419bc4f4ff38bbc100c6d7b93605/brickBrick2:10.0.1.35:/var/lib/heketi/mounts/vg_3277c6764dbce56b5a01426088901f6d/brick_6cbd74e9bed4758110c67cfe4d4edb53/brickBrick3:10.0.1.4:/var/lib/heketi/mounts/vg_29d6152eeafc57a707bef56f091afe44/brick_4856d63b721d794e7a4cbb4a6f048d96/brickOptionsReconfigured:transport.address-family: inetnfs.disable: onperformance.client-io-threads: off$ kubectl get svcNAME                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGEheketi                     ClusterIP192.168.101.75<none>8080/TCP   5hheketi-storage-endpoints   ClusterIP192.168.103.66<none>1/TCP      5h$ kubectl get endpointsNAME                       ENDPOINTS                            AGEheketi                     10.0.1.69:80805hheketi-storage-endpoints   10.0.1.35:1,10.0.1.4:1,10.0.1.66:15hkubernetes                 172.31.22.152:4431droot@aks-agentpool-20273348-0:~# kubectl get endpoints heketi-storage-endpoints -o yamlapiVersion: v1kind:Endpointsmetadata:  creationTimestamp:2019-01-29T15:14:28Z  name: heketi-storage-endpoints  namespace:default  resourceVersion:"142212"  selfLink:/api/v1/namespaces/default/endpoints/heketi-storage-endpoints  uid:91f802eb-23d8-11e9-bfcb-a23b1ec87092subsets:- addresses:  - ip:10.0.1.35  - ip:10.0.1.4  - ip:10.0.1.66  ports:  - port:1    protocol: TCP 

优点

  • 久经考验的存储方案。
  • 比 Ceph 轻量。

缺点

  • Heketi 在公有云上表现不佳。在私有云上表现良好,安装会方便一些。
  • 并非为结构化数据设计,例如 SQL 数据库。然而可以使用 GlusterFS 为 数据库 提供备份和恢复支持。

Ceph Rook

我在 OpenStack 私有云上尝试过安装和运行 Ceph。它需要为特定硬件定制参数,根据数据类型设计 pg 组、SSD 分区和 CRUSH 图等。所以第一次听说在 3 节点的 K8s 集群上运行 Ceph 的时候,我不太相信它能工作。结果 Rook 的编排工具让我印象深刻,它把所有的步骤和 K8s 的编排能力结合在一起,让安装变得非常简便。

在 AKS 上运行

Rook 的缺省安装无需任何特定步骤,如果没什么高级配置,会非常简单。

  1. 我使用的是 Ceph 快速入门指南
  2. 为 AKS 配置 FLEXVOLUME_DIR_PATH ,这是因为它需要 /etc/kubernetes/volumeplugins/ ,而不是 Ubuntu 中缺省的 /usr/libexec ,没有这个步骤,Kubelet 就 无法加载 PVC 了。~~~ diff –git a/cluster/examples/kubernetes/ceph/operator.yaml b/cluster/examples/kubernetes/ceph/operator.yaml index 73cde2e..33f45c8 100755 — a/cluster/examples/kubernetes/ceph/operator.yaml +++ b/cluster/examples/kubernetes/ceph/operator.yaml @@ -431,8 +431,8 @@ spec: # – name: AGENT_MOUNT_SECURITY_MODE # value: “Any” # Set the path where the Rook agent can find the flex volumes # – name: FLEXVOLUME_DIR_PATH# value: ““– name: FLEXVOLUME_DIR_PATHvalue: “/etc/kubernetes/volumeplugins” # Set the path where kernel modules can be found # – name: LIB_MODULES_DIR_PATH # value: ““ ~~~
  3. 还要在 deviceFilter 中指定要使用的设备,这里是 /dev/sdc 。~~~ diff –git a/cluster/examples/kubernetes/ceph/cluster.yaml b/cluster/examples/kubernetes/ceph/cluster.yaml index 48cfeeb..0c91c48 100755 — a/cluster/examples/kubernetes/ceph/cluster.yaml +++ b/cluster/examples/kubernetes/ceph/cluster.yaml @@ -227,7 +227,7 @@ spec: storage: # cluster level storage configuration and selection useAllNodes: true useAllDevices: false deviceFilter:deviceFilter: “^sdc” location: config: ~~~
  4. 安装之后,创建一个 Ceph block pool,以及 StorageClass,使用如下配置。apiVersion: ceph.rook.io/v1 kind:CephBlockPool metadata: name: replicapool namespace: rook-ceph spec: failureDomain: host replicated: size:3--- apiVersion: storage.k8s.io/v1 kind:StorageClass metadata: name: rook-ceph-block provisioner: ceph.rook.io/block parameters: blockPool: replicapool clusterNamespace: rook-ceph fstype: xfs reclaimPolicy:Retain
  5. 最后使用部署 工具 进行检查。

 

  1. $ gluster volume info vol_efb3b15529aa9aba889d7900f0ce9849VolumeName: vol_efb3b15529aa9aba889d7900f0ce9849Type:ReplicateVolume ID:96fde36b-e389-4dbe-887b-baae32789436Status:StartedSnapshotCount:0Number of Bricks:1 x 3=3Transport-type: tcpBricks:Brick1:10.0.1.66:/var/lib/heketi/mounts/vg_5413895eade683e1ca035760c1e0ffd0/brick_cd7c419bc4f4ff38bbc100c6d7b93605/brickBrick2:10.0.1.35:/var/lib/heketi/mounts/vg_3277c6764dbce56b5a01426088901f6d/brick_6cbd74e9bed4758110c67cfe4d4edb53/brickBrick3:10.0.1.4:/var/lib/heketi/mounts/vg_29d6152eeafc57a707bef56f091afe44/brick_4856d63b721d794e7a4cbb4a6f048d96/brickOptionsReconfigured:transport.address-family: inetnfs.disable: onperformance.client-io-threads: off$ kubectl get svcNAME                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGEheketi                     ClusterIP192.168.101.75<none>8080/TCP   5hheketi-storage-endpoints   ClusterIP192.168.103.66<none>1/TCP      5h$ kubectl get endpointsNAME                       ENDPOINTS                            AGEheketi                     10.0.1.69:80805hheketi-storage-endpoints   10.0.1.35:1,10.0.1.4:1,10.0.1.66:15hkubernetes                 172.31.22.152:4431droot@aks-agentpool-20273348-0:~# kubectl get endpoints heketi-storage-endpoints -o yamlapiVersion: v1kind:Endpointsmetadata:  creationTimestamp:2019-01-29T15:14:28Z  name: heketi-storage-endpoints  namespace:default  resourceVersion:"142212"  selfLink:/api/v1/namespaces/default/endpoints/heketi-storage-endpoints  uid:91f802eb-23d8-11e9-bfcb-a23b1ec87092subsets:- addresses:  - ip:10.0.1.35  - ip:10.0.1.4  - ip:10.0.1.66  ports:  - port:1    protocol: TCP 

优点

  • 在大型生产环境上的健壮存储系统。
  • Rook 很好的简化了生命周期管理。

缺点

  • 复杂:更加重量级,也不太适合在公有云上运行。在私有云上的运行可能更加合适。

AKS 测试环境

我用 3 个虚拟机创建了基本的 Azure AKS 集群。为了连接到 Premium SSD 上,我只能使用 type E 以上级别的虚拟机。因此我选择了 Standard_E2s_v3 ,其上配备了 2 vCPU 以及 16GB 的内存。

 

Kubernetes 几种存储方式性能对比

 

在 AKS 集群所在的资源足中,可以看到所有的虚拟机、网络接口等资源。在这里创建 3 个 1TB 的 Premium SSD 存储,并手工挂载到每个虚拟机上。

 

Kubernetes 几种存储方式性能对比

 

这样在每个实例上,我都有 1TB 的空磁盘。Azure 的页面上,根据我们选择的虚拟机和磁盘尺寸来看,性能应该有 5000 IOPS 以及 200MB/s 的吞吐量。最后一节会显示我们的真实结果。

 

Kubernetes 几种存储方式性能对比

 

性能结果

注意:每种存储的结果并不能作为独立的评估结果,但是其比较情况是可以参考的。有很多种对比测试的方法,这是最简单的一种。

为了运行测试,我决定使用现成的测试工具 Dbench ,它是一个 k8s 的 YAML 文件,会使用 FIO 运行 8 个测试用例。可以在 Dockerfile 中 指定不同测试 :

  • 随机读写带宽。
  • 随机读写 IOPS。
  • 读写延迟。
  • 顺序读写。
  • 混合读写 IOPS。

所有测试的结果可以在 Github 上找到。

随机读写带宽

随机读写测试表明,GlusterFS、Ceph 以及 Portworx 的读取性能比 AWS 本地盘的 hostPath 快了几倍。读缓存是罪魁祸首。GlusterFS 和 Portworx 的写入更快,其效率直逼本地磁盘。

 

Kubernetes 几种存储方式性能对比

 

 

Kubernetes 几种存储方式性能对比

 

随机读写 IOPS

随机 IOPS 测试中,Portworx 和 Ceph 表现较好。Portworx 在写入方面获得了接近 Azure 原生 PVC 的 IOPS。

 

Kubernetes 几种存储方式性能对比

 

 

Kubernetes 几种存储方式性能对比

 

读写延迟

延迟测试的结果比较有趣,Azure 原生 PVC 比多数其它存储都差。Portworx 和 Ceph 表现较好。写入方面,GlusterFS 要优于 Ceph。OpenEBS 的延迟相对来说非常的高。

 

Kubernetes 几种存储方式性能对比

 

 

Kubernetes 几种存储方式性能对比

 

顺序读写

顺序读写的结果和前面的随机测试差不多,然而 Cpeh 在读取方面比 GlusterFS 快了一倍多。写入结果基本一致,只有 OpenEBS 表现奇差。

 

Kubernetes 几种存储方式性能对比

 

 

Kubernetes 几种存储方式性能对比

 

混合读写 IOPS

最后一个测试用例检查的是混合读写情况下的 IOPS,Portworx 和 Ceph 都给出了优于 Azure 原生 PVC 的结果。

 

Kubernetes 几种存储方式性能对比

 

 

Kubernetes 几种存储方式性能对比

 

结论

本文展示了一个简单的存储对比,使用未经性能优化的多种存储提供的存储卷进行测试和比较。建议关注本文所述方法,不建议直接采用结果进行判断。

忽略 Azure 的原生 PVC 或 hostPath ,我们可以得出如下测试结果:

  • Portworx 是 AKS 上最快的容器存储。
  • Ceph 是私有云集群上最快的开源存储后端。对公有云来说,其操作太过复杂,这些多余的复杂性并没有能提供更好的测试表现。
  • OpenEBS 的概念很棒,但是其后端需要更多优化。

调整性能数据的测试规模应该会很有意思。另外值得关注的对比就是 CPU 和内存的消耗。我会持续关注,并分享更多。

责任编辑:华轩 来源: 伪架构师
相关推荐

2023-02-16 08:03:01

开源Kubernetes

2023-11-27 00:46:39

裸机虚拟机

2020-11-08 14:43:25

Python列表去重编程

2021-05-07 17:46:53

存储IO

2020-08-27 18:54:17

戴尔

2010-01-16 11:02:12

Ubuntu性能测试

2017-04-13 15:15:17

Netflix ZuuNginx性能

2010-06-28 13:11:05

2010-01-22 11:06:03

GNUkFreeBSDLinux

2022-12-05 17:01:20

MySQL数据库Oracle

2009-11-20 09:01:13

Ubuntu性能对比

2010-04-13 17:07:18

WindowsEmbe微软嵌入式开发Windows7

2010-04-13 17:28:09

WindowsEmbe微软嵌入式开发Windows7

2010-04-13 17:38:13

WindowsEmbe微软嵌入式开发Windows7

2009-07-24 13:17:43

世纪互联至强CloudEx

2010-04-13 17:47:50

WindowsEmbe微软嵌入式开发Windows7

2009-03-12 09:59:43

Windows7WindowsVistWindowsXP

2017-11-21 15:50:09

FlinkStorm性能

2011-08-05 13:41:46

Go

2009-05-31 10:00:26

点赞
收藏

51CTO技术栈公众号