创建JindoRuntime和Dataset实现Master组件状态持久化存储 - 容器服务 Kubernetes 版 ACK

为避免运行Master组件的容器重启造成缓存系统元数据丢失，Fluid支持通过配置JindoRuntime，持久化存储JindoFS Master组件的元数据，从而提升JindoFS分布式缓存集群的可用性。

功能介绍

JindoFS来源于阿里云EMR团队，是基于C++实现的支撑Dataset数据管理和数据缓存的执行引擎，同时支持对OSS、OSS-HDFS和PVC等多种数据源提供数据缓存服务。更多信息，请参见JindoData概述。

JindoFS采用Master-Worker架构，Master组件和Worker组件均容器化运行于集群中，其中Master组件负责记录缓存数据元信息和挂载点信息等，Worker组件负责维护缓存数据信息。当运行Master组件的容器重启或重新调度时，Master组件缓存的数据元信息和挂载点信息可能会丢失，从而导致JindoFS分布式缓存集群不可用。您可以通过配置Fluid JindoRuntime，使JindoFS Master组件将元信息持久化存储于Kubernetes存储卷中，提高JindoFS分布式缓存集群的可用性。

前提条件

已创建ACK集群Pro版，且集群版本为1.18及以上。具体操作，请参见创建ACK Pro版集群。
已安装云原生AI套件并部署ack-fluid组件，且ack-fluid版本为1.0.5及以上。具体操作，请参见安装云原生AI套件。
重要
若您已安装开源Fluid，请卸载后再部署ack-fluid组件。
已通过kubectl连接Kubernetes集群。具体操作，请参见获取集群KubeConfig并通过kubectl工具连接集群。
已创建OSS存储空间（Bucket）并上传文件，且为RAM用户授予访问该Bucket的权限。具体操作，请参见创建存储空间和添加Bucket Policy。

步骤一：准备云盘存储卷

创建pvc.yaml文件，配置云盘存储卷PVC。

说明

如果您需要为云盘存储卷PVC配置更多参数，请参见通过kubectl命令行使用云盘动态存储卷。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: demo-jindo-master-meta
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: alicloud-disk-topology-alltype
  resources:
    requests:
      storage: 30Gi

执行以下命令，创建PVC资源。

kubectl create -f pvc.yaml

预期输出：

persistentvolumeclaim/demo-jindo-master-meta created

步骤二：创建Dataset和JindoRuntime

创建secret.yaml文件，保存用于RAM访问OSS Bucket的AccessKeyId（AK）和AccessKeySecret（SK）。

apiVersion: v1
kind: Secret
metadata:
  name: access-key
stringData:
  fs.oss.accessKeyId: ****** # 请输入AccessKeyId。
  fs.oss.accessKeySecret: ****** # 请输入AccessKeySecret。

执行以下命令，创建Secret资源。
```
kubectl create -f secret.yaml
```
预期输出：
```
secret/access-key created
```

创建dataset.yaml文件，配置Fluid Dataset资源和Fluid JindoRuntime资源的参数信息。

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo
spec:
  mounts: 
    - mountPoint: oss://<OSS_BUCKET>/<BUCKET_DIR>
      name: demo
      path: /
      options:
        fs.oss.endpoint: <OSS_BUCKET_ENDPOINT>
      encryptOptions:
        - name: fs.oss.accessKeyId
          valueFrom:
            secretKeyRef:
              name: access-key
              key: fs.oss.accessKeyId
        - name: fs.oss.accessKeySecret
          valueFrom:
            secretKeyRef:
              name: access-key
              key: fs.oss.accessKeySecret
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: demo
spec:
  replicas: 2
  volumes:
    - name: meta-vol
      persistentVolumeClaim:
        claimName: demo-jindo-master-meta
  master:
    volumeMounts:
      - name: meta-vol
        mountPath: /root/jindofsx-meta
    properties:
      namespace.meta-dir: "/root/jindofsx-meta"
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        volumeType: emptyDir
        quota: 12Gi
        high: "0.99"
        low: "0.99"

与本功能相关的关键参数说明如下：

参数		说明
JindoRuntime	`volumes`	配置JindoRuntime各组件可挂载的存储卷信息。您需要选择步骤一：准备云盘存储卷中创建的云盘存储卷PVC。
	`master.volumeMounts`	配置运行JindoRuntime Master组件的容器所挂载的存储卷和挂载路径。
	`master.properties`	配置JindoRuntime Master组件的详细参数信息。为启用Master组件的元信息持久化存储能力，需指定`namespace.meta-dir: <path>`，其中`<path>`为`master.volumeMounts`中指定的存储卷挂载路径（即`mountPath`参数值）。

执行以下命令，创建JindoRuntime和Dataset。

kubectl create -f dataset.yaml

预期输出：

dataset.data.fluid.io/demo created
jindoruntime.data.fluid.io/demo created

执行以下命令，查看Dataset部署情况。
```
kubectl get dataset
```
预期输出：
```
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE
demo 531.89MiB      0.00B  24.00GiB       0.0%              Bound 5m35s
```
PHASE字段变为Bound状态，表明Dataset和JindoRuntime已部署成功。Fluid将自动为Bound状态的Dataset创建同名PVC，应用Pod可通过挂载该PVC，访问Dataset挂载点（Dataset.spec.mountPoint）中指定的数据。

步骤三：验证Master组件状态持久化存储功能

在本步骤中，通过对节点添加污点模拟运行Master组件的Pod重新调度的场景，以验证本功能是否正确配置并生效。

创建pod.yaml文件，用于挂载PVC。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: registry.openanolis.cn/openanolis/nginx:1.14.1-8.6
      volumeMounts:
        - mountPath: /data
          name: data-vol
  volumes:
    - name: data-vol
      persistentVolumeClaim:
        claimName: demo

执行以下命令，在Kubernetes集群中部署Nginx应用。
```
kubectl create -f pod.yaml
```
预期输出：
```
pod/nginx created
```
执行以下命令，从应用Pod中访问数据。
```
kubectl exec -it nginx -- ls /data
```
预期输出Dataset挂载点（Dataset.spec.mountPoint）中指定的OSS文件系统中的数据。

执行以下命令，获取运行JindoFS Master组件的Pod所在的节点。

master_node=$(kubectl get pod -o wide | awk '/demo-jindofs-master-0/ {print $7}')

执行以下命令，通过污点阻止新的Pod调度至步骤4中查询的节点。

kubectl taint node $master_node test-jindofs-master=reschedule:NoSchedule

预期输出：

node/cn-beijing.192.168.xx.xx tainted

执行以下命令，删除并自动重建JindoFS Master组件的Pod。
```
kubectl delete pod demo-jindofs-master-0
```
预期输出：
```
pod "demo-jindofs-master-0" deleted 
```
此时，重建的Pod（demo-jindofs-master-0）将会被调度到集群中的另一个节点上。但是由于运行JindoFS Master组件的Pod挂载了存储卷，因此Master组件可以通过存储卷恢复到Pod被重建前的状态。
说明
由于云盘存储卷不支持跨可用区挂载，因此在使用云盘作为持久化存储时，重建的Pod只能被调度到同可用区的其他节点上。请确保集群中至少包含另一个与重建前Pod同可用区的ECS节点。

执行以下命令，重建应用Pod。

kubectl delete -f pod.yaml && kubectl create -f pod.yaml

预期输出：

pod "nginx" deleted
pod/nginx created

执行以下命令，从重建后的应用Pod中再次访问数据。
```
kubectl exec -it nginx -- ls /data
```
预期输出Dataset挂载点（Dataset.spec.mountPoint）中指定的OSS文件系统中的数据。

步骤四：环境清理

执行以下命令，删除Pod。
```
kubectl delete -f pod.yaml
```
预期输出：
```
pod "nginx" deleted
```

执行以下命令，删除为节点添加的污点。

kubectl taint node $master_node test-jindofs-master-

预期输出：

node/cn-beijing.192.168.xx.xx untainted

（可选）依次执行以下命令，清理云盘存储卷资源。
重要
- 本示例中创建的云盘存储卷将持续产生费用。如果您不再需要使用该数据加速功能，请及时清理环境。关于云盘存储卷产生的费用，请参见云盘存储卷概述。
- 清理前，确保没有正在使用该数据集并进行I/O操作的应用Pod。
```
kubectl delete -f dataset.yaml
kubectl delete -f pvc.yaml
```