如何进行Docker和Kubernetes中使用Ceph RBD卷的原理分析

如何进行Docker和Kubernetes中使用Ceph RBD卷的原理分析，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。在Docker或者Kubernetes中使用Ceph RBD块设备，相比于在宿主机中，是否会对性能造成额外损失？带着这些疑问对相关技术进行原理分析。Linux Mount命名空间通过隔离文件系统挂载点对隔离文件系统提供支持，它是历史上第一个 Linux Namespace，所以它的标识位比较特殊，就是 CLONE_NEWNS。隔离后，不同 Mount Namespace 中的文件结构发生变化也互不影响。你可以通过 /proc/[pid]/mounts 查看到所有挂载在当前 Namespace 中的文件系统，还可以通过 /proc/[pid]/mountstats 看到 Mount Namespace 中文件设备的统计信息，包括挂载文件的名字、文件系统类型、挂载位置等等。进程在创建 Mount Namespace 时，会把当前的文件结构复制给新的 Namespace。新 Namespace 中的所有 Mount 操作都只影响自身的文件系统，而对外界不会产生任何影响。这样做非常严格地实现了隔离，但是某些情况可能并不适用。比如父节点 Namespace 中的进程挂载了一张 CD-ROM，这时子节点 Namespace 拷贝的目录结构就无法自动挂载上这张 CD-ROM，因为这种操作会影响到父节点的文件系统。2006 年引入的挂载传播（Mount Propagation）解决了这个问题，挂载传播定义了挂载对象（Mount Object）之间的关系，系统用这些关系决定任何挂载对象中的挂载事件如何传播到其他挂载对象（参考自：http://www.ibm.com/developerworks/library/l-mount-namespaces/）。所谓传播事件，是指由一个挂载对象的状态变化导致的其它挂载对象的挂载与解除挂载动作的事件。共享关系（Share Relationship）。如果两个挂载对象具有共享关系，那么一个挂载对象中的挂载事件会传播到另一个挂载对象，反之亦然。从属关系（Slave Relationship）。如果两个挂载对象形成从属关系，那么一个挂载对象中的挂载事件会传播到另一个挂载对象，但是反过来不行；在这种关系中，从属对象是事件的接收者。一个挂载状态可能为如下的其中一种：共享挂载（Shared）从属挂载（Slave）共享 / 从属挂载（Shared And Slave）私有挂载（Private）不可绑定挂载（Unbindable）传播事件的挂载对象称为共享挂载（Shared Mount）；接收传播事件的挂载对象称为从属挂载（Slave Mount）。既不传播也不接收传播事件的挂载对象称为私有挂载（Private Mount）。另一种特殊的挂载对象称为不可绑定的挂载（Unbindable Mount），它们与私有挂载相似，但是不允许执行绑定挂载，即创建 Mount Namespace 时这块文件对象不可被复制。共享挂载的应用场景非常明显，就是为了文件数据的共享所必须存在的一种挂载方式；从属挂载更大的意义在于某些“只读”场景；私有挂载其实就是纯粹的隔离，作为一个独立的个体而存在；不可绑定挂载则有助于防止没有必要的文件拷贝，如某个用户数据目录，当根目录被递归式的复制时，用户目录无论从隐私还是实际用途考虑都需要有一个不可被复制的选项。默认情况下，所有挂载都是私有的。设置为共享挂载的命令如下：从共享挂载克隆的挂载对象也是共享的挂载；它们相互传播挂载事件。设置为从属挂载的命令如下：从从属挂载克隆的挂载对象也是从属的挂载，它也从属于原来的从属挂载的主挂载对象。将一个从属挂载对象设置为共享 / 从属挂载，可以执行如下命令或者将其移动到一个共享挂载对象下：如果你想把修改过的挂载对象重新标记为私有的，可以执行如下命令：通过执行以下命令，可以将挂载对象标记为不可绑定的：查看本机块设备：创建和绑定目录：查看绑定目录的详细信息：可以看到两个绑定目录都是共享的，且共享ID为1，父目录在253:0设备上。参考文档：Manage data in Docker；Use bind mounts。Docker支持的挂载模式：创建一个数据卷（卷挂载）：映射一个外部卷（绑定挂载）：使用数据型容器（卷挂载）：带打包数据的容器（卷挂载）：编辑Dockerfile创建容器使用临时外部卷（临时挂载）：在容器内通过绑定挂载使用宿主机的块设备，只能使用已经在宿主机格式化和挂载好的目录：在容器内通过共享设备使用块设备，可以读写，但是不能挂载：在容器内通过特权模式使用块设备，可以读写和挂载：查看kublet初始化根目录/var/lib/kubelet时的源码，可以看到kubelet使用syscall.MS_SHARED|syscall.MS_REC标志，该目录下下所有的Mount都默认共享（相当于执行mount --make-开发云主机域名rshared /var/lib/kubelet）：创建一个使用PVC创建RBD的Pod：查看PVC的状态：查看PV的状态：查看创建和映射的RBD：查看RBD的挂载信息：可以看到RBD被挂载在两个位置，一个是Pod的Volume目录，还有一个是RBD插件目录，而且这两个目录都是shared:262，说明这两个目录是被绑定的。查看RBD挂载目录的位置：可以看到RBD挂载在253:0设备上，这是宿主机的根目录所挂载的位置。查看Pod挂载的卷目录：可以看到Pod挂载了两个卷，除了之前的RBD，还有就是一个存放Secret的卷。查看Pod的Docker容器中挂载目录：可以看到Docker的这些卷最后都是通过Bind挂载的，而且Mount广播使用的是rprivate属性。看看Pod的容器内Mount情况：可以看到Pod的容器内的确主要挂载了RBD和Secret两个目录。在Docker中，无论使用哪种方式使用数据卷，实际上都是利用的Linux的的mount --bind绑定挂载功能实现。在Kubernetes中使用RBD卷时，首先通过rbd map到宿主机并进行格式化，然后mount到宿主机目录，最后把这个宿主机目录mount --bind到容器的指定目录中使用。根据原理分析可以初步推断：在宿主机中测试RBD读写性能和在Docker和Kubernetes中分别测试的性能没有本质区别，Docker和Kubernetes本身不会对RBD性能造成影响（之后我又使用Fio对其进行完整的性能测试，和这个结论也是一致的）。关于如何进行Docker和Kubernetes中使用Ceph RBD卷的原理分析问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注开发云行业资讯频道了解更多相关知识。