在 Fluid 中,
Dataset
资源对象中所定义的远程文件是可被调度的,这意味着您能够像管理您的 Pod 一样管理远程文件缓存在 Kubernetes 集群上的存放位置。而执行计算的 Pod 可以通过 Fuse 客户端访问数据文件。Fuse 客户端提供两种模式:
global 为 false,该模式为 Fuse 客户端和缓存数据强制亲和性,此时 Fuse 客户端的数量等于 Runtime 的 replicas 数量。此配置默认模式,无需显式声明,好处是可以发挥数据的亲和性优点,但是 Fuse 客户端的部署就变得比较固定。
global 为 true,该模式为 Fuse 客户端,可以在 Kubernetes 集群中全局部署,并不要求数据和 Fuse 客户端之间的强制亲和性,此时 Fuse 客户端的数量可能远超 Runtime 的 replicas 数量。建议此时可以通过 nodeSelector 来指定 Fuse 客户端的部署范围。
前提条件
$ kubectl get pod -n fluid-systemgoosefsruntime-controller-5b64fdbbb-84pc6 1/1 Running 0 8hcsi-nodeplugin-fluid-fwgjh 2/2 Running 0 8hcsi-nodeplugin-fluid-ll8bq 2/2 Running 0 8hdataset-controller-5b7848dbbb-n44dj 1/1 Running 0 8h
通常来说,您会看到一个名为
dataset-controller
的 Pod、一个名为 goosefsruntime-controller
的 Pod 和多个名为 csi-nodeplugin
的 Pod 正在运行。其中 csi-nodeplugin
这些 Pod 的数量取决于您的 Kubernetes 集群中结点的数量。新建工作环境
$ mkdir <any-path>/fuse-global-deployment$ cd <any-path>/fuse-global-deployment
运行示例
示例1: 设置 global 为 true
查看全部结点
$ kubectl get nodesNAME STATUS ROLES AGE VERSION192.168.1.146 Ready <none> 7d14h v1.18.4-tke.13192.168.1.147 Ready <none> 7d14h v1.18.4-tke.13
使用标签标识结点
$ kubectl label nodes 192.168.1.146 cache-node=true
在接下来的步骤中,我们将使用
NodeSelector
来管理集群中存放数据的位置,所以在这里标记期望的结点。再次查看结点
$ kubectl get node -L cache-nodeNAME STATUS ROLES AGE VERSION cache-node192.168.1.146 Ready <none> 7d14h v1.18.4-tke.13 true192.168.1.147 Ready <none> 7d14h v1.18.4-tke.13
目前,在全部2个结点中,仅有一个结点添加了
cache-node=true
的标签,接下来,我们希望数据缓存仅会被放置在该结点之上。检查待创建的 Dataset 资源对象
apiVersion: data.fluid.io/v1alpha1kind: Datasetmetadata:name: hbasespec:mounts:- mountPoint: https://mirrors.tuna.tsinghua.edu.cn/apache/hbase/stable/name: hbasenodeAffinity:required:nodeSelectorTerms:- matchExpressions:- key: cache-nodeoperator: Invalues:- "true"
说明
在该
Dataset
资源对象的 spec
属性中,我们定义了一个 nodeSelectorTerm
的子属性,该子属性要求数据缓存必须被放置在具有 cache-node=true
标签的结点之上。创建 Dataset 资源对象
$ kubectl create -f dataset.yamldataset.data.fluid.io/hbase created
检查待创建的 GooseFSRuntime 资源对象
apiVersion: data.fluid.io/v1alpha1kind: GooseFSRuntimemetadata:name: hbasespec:replicas: 1tieredstore:levels:- mediumtype: SSDpath: /mnt/disk1/quota: 2Ghigh: "0.8"low: "0.7"fuse:global: true
该配置文件片段中,包含了许多与 GooseFS 相关的配置信息,这些信息将被 Fluid 用来启动一个 GooseFS 实例。上述配置片段中的
spec.replicas
属性被设置为1,这表明 Fluid 将会启动一个包含1个 GooseFS Master 和1个 GooseFS Worker 的 GooseFS 实例。 另外一个值得注意的是 Fuse 包含global: true
,这样意味着 Fuse 可以全局部署,而不依赖于数据缓存的位置。创建 GooseFSRuntime 资源并查看状态
$ kubectl create -f runtime.yamlgoosefsruntime.data.fluid.io/hbase created$ kubectl get po -owideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATEShbase-fuse-gfq7z 1/1 Running 0 3m47s 192.168.1.147 192.168.1.147 <none> <none>hbase-fuse-lmk5p 1/1 Running 0 3m47s 192.168.1.146 192.168.1.146 <none> <none>hbase-master-0 2/2 Running 0 3m47s 192.168.1.147 192.168.1.147 <none> <none>hbase-worker-hvbp2 2/2 Running 0 3m1s 192.168.1.146 192.168.1.146 <none> <none>
在此处可以看到,有一个 GooseFS Worker 成功启动,并且运行在具有指定标签(即
cache-node=true
)的节点之上。GooseFS Fuse 的数量为2,运行在所有的子节点上。检查 GooseFSRuntime 状态
$ kubectl get goosefsruntime hbase -o wideNAME READY MASTERS DESIRED MASTERS MASTER PHASE READY WORKERS DESIRED WORKERS WORKER PHASE READY FUSES DESIRED FUSES FUSE PHASE AGEhbase 1 1 Ready 1 1 Ready 2 2 Ready 12m
这里可以看到 GooseFS Worker 的数量为1,而 GooseFS Fuse 的数量为2。
删除 GooseFSRuntime
kubectl delete goosefsruntime hbase
示例2:设置 global 为 true,并且设置 fuse 的 nodeSelector
下面,我们希望通过配置 node selector 配置 Fuse 客户端,将其指定到集群中某个节点上。在本例子中,既然我们已经选择节点 192.168.1.146 作为缓存节点,为了形成对比,这里选择节点 192.168.1.147 运行 GooseFS Fuse。
apiVersion: data.fluid.io/v1alpha1kind: GooseFSRuntimemetadata:name: hbasespec:replicas: 1tieredstore:levels:- mediumtype: SSDpath: /mnt/disk1/quota: 2Ghigh: "0.8"low: "0.7"fuse:global: truenodeSelector:kubernetes.io/hostname: 192.168.1.147
该配置文件片段中,和之前 runtime.yaml 相比,在 Fuse 包含
global: true
的前提下, 还增加了 nodeSelector 并且指向了节点192.168.1.147。创建 GooseFSRuntime 资源并查看状态
$ kubectl create -f runtime-node-selector.yamlgoosefsruntime.data.fluid.io/hbase created$ kubectl get po -owideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATEShbase-fuse-xzbww 1/1 Running 0 1h 192.168.1.147 192.168.1.147 <none> <none>hbase-master-0 2/2 Running 0 1h 192.168.1.147 192.168.1.147 <none> <none>hbase-worker-vdxd5 2/2 Running 0 1h 192.168.1.146 192.168.1.146 <none> <none>
在此处可以看到,有一个 GooseFS Worker 成功启动,并且运行在具有指定标签(即
cache-node=true
)的结点之上。GooseFS Fuse 的数量为1,运行在节点192.168.1.147上。检查 GooseFSRuntime 状态
$ kubectl get goosefsruntimes.data.fluid.io -owideNAME READY MASTERS DESIRED MASTERS MASTER PHASE READY WORKERS DESIRED WORKERS WORKER PHASE READY FUSES DESIRED FUSES FUSE PHASE AGEhbase 1 1 Ready 1 1 Ready 1 1 Ready 1h
这里可以看到 GooseFS Worker 的数量为1,而 GooseFS Fuse 的数量也为1,这是因为 GooseFSRuntime 指定了 nodeSelector,并且满足条件的节点只有一个。
可见,Fluid 支持 Fuse 客户端单独的调度策略,这些调度策略为用户提供了更加灵活的 Fuse 客户端调度策略。
环境清理
$ kubectl delete -f .$ kubectl label node 192.168.1.146 cache-node-