干货 | eBay Kubernetes集群的存储实践

供稿 | TESS 高文俊&谢文利&沈涛

翻译&编辑 | 顾欣怡

本文3289字，预计阅读时间10分钟

更多干货请关注“eBay技术荟”公众号

导读

Kubernetes 作为eBay内部广泛使用的容器管理平台，承担着巨大的存储功能。本文将从 本地存储、网络存储、应用场景、磁盘监控、管理部署和后续工作 这几方面介绍eBay Kubernetes集群的存储实践。

如今，eBay已在内部广泛使用 Kubernetes 作为容器管理的平台，并自研了 AZ和联邦级别的控制平面 ，用以负责 50多个 集群 的创建、部署、监控、修复等工 作，并且规模在不断扩大。

我们的生产集群上，针对各种应用场景，大量使用了 本地存储 和 网络存储 ，并通过原生的PV/PVC来使用。 其中本地存储分为 静态分区类型 和 基于lvm的动态类型 ，支持ssd, hdd, nvme等介质。网络块存储使用ceph RBD和ISCSI，共享文件存储使用cephfs和nfs。

一、本地存储

01

静态分区

我们最早于 2016年 开始做 localvolume（本地卷） ，当时社区还没有本地的永久存储方案，为了支持内部的NoSQL应用使用 PV（Persistent Volume） ，开发了第一版的localvolume方案：

首先 ，在节点创建的时候，provision系统根据节点池flavor定义对数据盘做分区和格式化，并将盘的信息写入系统配置文件。

同时 ，我们在集群内部署了daemonset localvolume-provisioner，当节点加入集群后，provisioner会从配置文件中读取配置信息并生成相应的PV，其中包含相应的path，type等信息。 这样，每个PV对象也就对应着节点上的一个分区。

除此之外 ，我们改进了scheduler，将本地 PV/PVC的绑定（binding）延迟到scheduler里进行。 这也对应现在社区的volumeScheduling feature。

现在cgroup v1不能很好地支持buffer io的限流和隔离，对于一些io敏感的应用来说，需要尽可能防止这些“noisy neighbors”干扰。 同时对于disk io load很高的应用，应尽可能平均每块盘的负担，延长磁盘寿命。

因此，我们增加了PVC的反亲和性（anti affinity）调度特性 ，在满足节点调度的同时，会尽可能调度到符合反亲和性规则的盘上。

具体做法是 ，在PV中打上标签表明属于哪个节点的哪块盘，在PVC中指定反亲和性规则，如下图一所示。 scheduler里增加相应的预选功能，保证声明了同类型的反亲和性的PVC，不会绑定到处在同一块盘的PV上，并在最终调度成功后，完成选定PV/PVC的绑定。

图1（点击可查看大图）

02

LVM动态存储

对于上述静态存储的方案，PV大小是固定的，我们同时希望volume空间能够更灵活地按需申请，即动态分配存储。

类似地，我们在节点flavor里定义一个vg作为存储池，节点创建的时候，provision系统会根据flavor做好分区和vg的创建。同时集群内部署了 daemonset local-volume-dynamic-provisioner ，实现CSI的相应功能。

在CSI 0.4版本中，该daemonset由CSI的 四个 基本组件组成， 即：csi-attacher, csi-provisioner, csi-registrar以及csi-driver。其中csi-attacher, csi-provisioner和csi-registrar为社区的 sidecar controll er 。csi-driver是根据存储后端自己实现CSI接口, 目前支持xfs和ext4两种主流文件系统，也支持直接挂载裸盘供用户使用。

为了支持scheduler能够感知到集群的存储拓扑，我们在csi-registrar中把从csi-driver拿到的拓扑信息同步到Kubernetes节点中存储，供scheduler预选时提取，避免了在kubelet中改动代码。

如图2所示，pod创建后，scheduler将根据vg剩余空间选择节点、local-volume-dynamic-provisioner来申请相应大小的lvm logical volume，并创建对应的PV，挂载给pod使用。

图2 （点击可查看大图）

二、网络存储

01

块存储

对于网络块存储，我们使用ceph RBD和ISCSI作为存储后端，其中ISCSI为远端SSD，RBD为远端HDD，通过openstack的cinder组件统一管理。

网络存储卷的管理主要包括provision/deletion/attach/detach等，在provision/deletion的时候，相比于localvolume（本地卷）需要以daemonset的方式部署， 网络存储只需要一个中心化的provisioner 。

我们利用了社区的cinder provisioner方案(详情可见： https://github.com/kubernetes/cloud-provider-openstack )，并加以相应的定制，比如支持利用已有 快照卷（snapshot volume） 来创建PV，secret统一管理等。

Provisioner的基本思路是 ：

watch PVC创建请求 

→ 调用cinder api创建相应类型和大小的卷，获得卷id

→ 调用cinder的initialize_connection api，获取后端存储卷的具体连接信息和认证信息，映射为对应类型的PV对象 

→ 往apiserver发请求创建PV 

→ PV controller负责完成PVC和PV的绑定。

Delete 为逆过程。

Attach 由volume plugin或csi来实现，直接建立每个节点到后端的连接，如RBD map, ISCSI会话连接，并在本地映射为块设备。 这个过程是分立到每个节点上的操作，无法在controller manager里实现中心化的attach/detach。因此放到kubelet或csi daemonset来做，而controller manager主要实现逻辑上的accessmode的检查和volume接口的伪操作，通过节点的状态与kubelet实现协同管理。

Detach 为逆过程。

在使用RBD的过程中，我们也遇到过一些问题：

1） RBD map hang:

RBD map进程hang，然而设备已经map到本地并显示为/dev/rbdX。经分析，发现是RBD client端的代码在执行完attach操作后，会进入顺序等待udevd event的loop，分别为”subsystem=rbd” add event和”subsystem=block” add event。而udevd并不保证遵循kernel uevent的顺序，因此如果”subsystem=block” event先于 “subsystem=rbd” event, RBD client将一直等待下去。通过人为触发add event（udevadm trigger –type=devices –action=add），就可能顺利退出。

这个问题后来在社区得到解决，我们反向移植（backport）到所有的生产集群上。

（详情可见：

https://tracker.ceph.com/issues/39089 ）

2） kernel RBD支持的RBD feature非常有限 ，很多后端存储的特性无法使用。

3） 当节点map了RBD device并被container使用，节点重启会一直hang住， 原因是network shutdown先于RBD umount，导致kernel在cleanup_mnt()的时候kRBD连接ceph集群失败，进程处于D状态。我们改变systemd的配置ShutdownWatchdogSec为 1分钟 ，来避免这个问题。

除了kernel RBD模块，Ceph也支持块存储的用户态librbd实现 ： rbd-nbd。 Kubernetes也支持使用rbd-nbd。

如图3所示，我们对kRBD和rbd-nbd做了对比：

图3 （点击可查看大图）

如上，rbd-nbd在使用上有 16个 device的限制，同时会耗费更多的cpu资源，综合考虑我们的使用需求，决定继续使用kRBD。

图4为三类块存储的性能比较：

图4 （点击可查看大图）

02

文件存储

我们主要使用 cephfs 作为 存储后端 ，cephfs可以使用 kernel mount ，也可以使用 cephfs-fuse mount ，类似于前述kRBD和librbd的区别。前者工作在 内核态 ，后者工作在 用户态 。

经过实际对比，发现性能上fuse mount远不如kernel mount，而另一方面，fuse能更好地支持后端的feature，便于管理。 目前社区cephfs plugin里默认使用ceph fuse，为了满足部分应用的读写性能要求，我们提供了pod annotation（注解）选项，应用可自行选择使用哪类mount方式，默认为fuse mount。

下面介绍一下在使用ceph fuse的过程中遇到的一些问题 (ceph mimic version 13.2.5， kernel 4.15.0-43)

1）ceph fuse internal type overflow导致mount目录不可访问

ceph fuse设置挂载目录dentry的attr_timeout为 0 ，应用每次访问时kernel都会重新验证该dentry cache是否可用，而每次lookup会对其对应inode的reference count + 1 。

经过分析，发现在kernel fuse driver里count是uint_64类型，而ceph-fuse里是int32类型。 当反复访问同一路径时，ref count一直增加，如果节点内存足够大，kernel没能及时触发释放 dentry缓存，会导致ceph-fuse里ref count值溢出。

针对该问题，临时的解决办法是周期性释放缓存（drop cache） ，这样每次会生成新的dentry，重新开始计数。同时我们存储的同事也往ceph社区提交补丁，将ceph-fuse中该值改为uint_64类型，同kernel 匹配起来。 （详情可见：

https://tracker.ceph.com/issues/40775 ）

2）kubelet du hang

kubelet会周期性通过du来统计emptydir volume使用情况，我们发现在部分节点上存在大量du进程hang，并且随着时间推移数量越来越多，一方面使系统load增高，另一方面耗尽pid资源，最终导致节点不响应。

经分析，du会读取到cephfs路径，而cephfs不可达是导致du hang的根本原因，主要由以下两类问题导致：

a. 网络问题导致mds连接断开。 如图5所示，通过ceph admin socket，可以看到存在失效链接（stale connection），原因是client端没有主动去重连，导致所有访问mount路径的操作hang在等待fuse answer上，在节点启用了client_reconnect_stale选项后，得到解决。

b. mds连接卡在opening状态，同样导致du hang。 原因是服务端打开了mds_session_blacklist_on_evict，导致连接出现问题时客户端无法重连。

图5 （点击可查看大图）

3）性能

kernel mount性能远高于fuse性能，经过调试，发现启用了fuse_big_write后，在大块读写的场景下，fuse性能几乎和kernel差不多。

三、应用场景

01

本地数据备份还原

本地存储相比网络存储，具有成本低，性能高的优点，但是如果节点失效，将会导致数据丢失，可靠性比网络存储低。

为了保证数据可靠性，应用实现了自己的备份还原机制。使用本地PV存储数据，同时挂载RBD类型的PV，增量传输数据至远端备份集群。同时远端会根据事先定义规则，周期性地在这些RBD盘上打 snapshot（快照） ，在还原的时候，选定特定snapshot，provision出对应PV，并挂载到节点上，恢复到本地PV。

02

盘加密

对于安全要求级别高的应用，如支付业务，我们使用了kata安全容器方案，同时对kata container的存储进行加密。如图6所示，我们使用了kernel dm-crypt对盘进行加密，并将生成的key对称加密存入eBay的密钥管理服务中，最后给container使用的是解密后的盘，在pod生命周期结束后，会关闭加密盘，防止数据泄漏。

图6 （点击可查看大图）

四、磁盘监控

1） smart工具检测每块盘的健康状况。

2） 系统日志中是否有坏盘信息。 根据已有的模式（pattern）对日志进行匹配，如图7所示。

3） 丢盘检测，对比实际检测到的盘符和节点flavor定义的盘符。

图7 （点击可查看大图）

以上检测结果以 metrics（指标） 的形式被prometheus收集，同时也更新到自定义crd computenode的状态中，由专门的 remediation controller（修复控制器） 接管，如满足预定义的节点失效策略，将会进入后续修复流程。

对于有问题的盘，monitor会对相应PV标记taint，scheduler里会防止绑定到该类PV，同时对于已绑定的PV，会给绑定到的PVC发event，通知应用。

五、管理部署

以上提到了几类组件，local-volume-provisioner，local-volume-dynamic-provisioner，cinder-provisioner，node-problem-detector等， 我们开发了gitops + salt的方案对其进行统一管理。

首先把每个组件作为一个 salt state ，定义对应的salt state文件和pillar，写入git repo，对于key等敏感信息则存放在secret中。这些manifest文件通过AZ控制面同步到各个集群并执行。我们将所有的组件视为 addon ，salt会生成最终的yaml定义文件，交由kube addon manager进行apply。在需要更新的时候，只需更新相应的salt文件和pillar值即可。