JindoRuntime とデータセットを作成して JindoFS マスターのストレージを永続化する - Container Service for Kubernetes

JindoFS マスターの再起動によってメタデータが失われるのを防ぐため、Fluid では JindoRuntime を使用して JindoFS マスターによって管理されているメタデータを永続化できます。これにより、分散キャッシュシナリオにおける JindoFS クラスタの可用性が向上します。

機能説明

JindoFS は、Alibaba Cloud E-MapReduce (EMR) チームが C++ をベースに開発した、データセット管理とキャッシュのための実行エンジンです。 JindoFS を使用すると、Object Storage Service (OSS)、OSS-Hadoop 分散ファイルシステム (HDFS)、永続ボリューム要求 (PVC) など、さまざまなソースのデータをキャッシュできます。詳細については、「JindoData の概要」をご参照ください。

JindoFS はマスターワーカーアーキテクチャを使用します。マスターはキャッシュデータのメタデータとマウントポイントを管理し、ワーカーはキャッシュデータを管理します。 JindoFS マスターとワーカーは Kubernetes クラスタにコンテナー化できます。 JindoFS マスターが実行されているコンテナーが再起動または再スケジュールされると、メタデータとマウントポイントが失われる可能性があります。その結果、JindoFS クラスタが使用できなくなる可能性があります。 JindoFS クラスタの可用性を高めるために、Fluid JindoRuntime を使用して JindoFS マスターのメタデータを Kubernetes 永続ボリューム (PV) に永続化できます。

前提条件

Kubernetes 1.18 以降を実行する ACK Pro マネージドクラスターが作成されていること。詳細については、「ACK マネージドクラスターの作成」をご参照ください。
クラウドネイティブ AI スイートと ack-fluid 1.0.5 以降がクラスターにデプロイされていること。詳細については、「クラウドネイティブ AI スイートをデプロイする」をご参照ください。
重要
オープンソースの Fluid を既にインストールしている場合は、Fluid をアンインストールし、ack-fluid コンポーネントをデプロイしてください。
kubectl クライアントがクラスターに接続されていること。詳細については、「クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続する」をご参照ください。
OSS バケットが作成され、ファイルがバケットにアップロードされていること。使用する Resource Access Management (RAM) ユーザーは、OSS バケットにアクセスする権限を持っている必要があります。詳細については、「バケットを作成する」および「バケットポリシーを追加する」をご参照ください。

ステップ 1: ディスクボリュームを準備する

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
```

ステップ 2: データセットと JindoRuntime を作成する

secret.yaml という名前のファイルを作成します。このファイルは、RAM ユーザーが OSS バケットにアクセスするために使用する AccessKey ID と AccessKey シークレットを保存するために使用されます。
```
apiVersion: v1
kind: Secret
metadata:
  name: access-key
stringData:
  fs.oss.accessKeyId: ****** # AccessKey ID を指定します。
  fs.oss.accessKeySecret: ****** # AccessKey シークレットを指定します。
```
次のコマンドを実行してシークレットを作成します。
```
kubectl create -f secret.yaml
```
予期される出力:
```
secret/access-key created
```

dataset.yaml という名前のファイルを作成します。このファイルは、データセットと 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 のコンポーネントにマウントされるボリュームを指定します。ステップ 1: ディスクボリュームを準備するで作成した PVC を指定します。
	`master.volumeMounts`	このパラメーターは、JindoRuntime マスターにマウントされるボリュームの名前とボリュームのマウントパスを指定します。
	`master.properties`	このパラメーターは、JindoRuntime マスターの詳細を指定します。 JindoRuntime マスターによって管理されているメタデータを永続化するには、`namespace.meta-dir: <path>` を指定する必要があります。 `<path>` は、`master.volumeMounts` パラメーターで指定した `マウントパス` に置き換えます。

次のコマンドを実行して、データセットと JindoRuntime を作成します。
```
kubectl create -f dataset.yaml
```
予期される出力:
```
dataset.data.fluid.io/demo created
jindoruntime.data.fluid.io/demo created
```
次のコマンドを実行して、データセットが作成されたかどうかを確認します。
```
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 と表示されている場合、データセットと JindoRuntime が作成されています。データセットが Bound 状態になると、Fluid はデータセットにちなんで名付けられた PVC を自動的に作成します。 PVC をアプリケーションポッドにマウントして、ポッドがデータセットのマウントポイント (Dataset.spec.mountPoint) で指定されたデータソースにアクセスできるようにすることができます。

ステップ 3: JindoFS マスターの永続ストレージが有効になっているかどうかを確認する

このステップでは、JindoFS マスターが実行されているポッドを再スケジュールして、永続ストレージが有効になっているかどうかを確認します。

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

次のコマンドを実行して、クラスターに NGINX アプリケーションをデプロイします。
```
kubectl create -f pod.yaml
```
予期される出力:
```
pod/nginx created
```
次のコマンドを実行して、アプリケーションポッドからデータにアクセスします。
```
kubectl exec -it nginx -- ls /data
```
データセットのマウントポイント (Dataset.spec.mountPoint) で指定された OSS バケット内のデータが出力に返されることが予期されます。
次のコマンドを実行して、JindoFS マスターがデプロイされているノードをクエリします。
```
master_node=$(kubectl get pod -o wide | awk '/demo-jindofs-master-0/ {print $7}')
```
ステップ 4 で返されたノードに taint を追加して、新しいポッドがノードにスケジュールされないようにします。
```
kubectl taint node $master_node test-jindofs-master=reschedule:NoSchedule
```
予期される出力:
```
node/cn-beijing.192.168.xx.xx tainted
```
次のコマンドを実行して、JindoFS マスターが実行されているポッドを削除し、システムがポッドを再作成するのを待ちます。
```
kubectl delete pod demo-jindofs-master-0
```
予期される出力:
```
pod "demo-jindofs-master-0" deleted 
```
demo-jindofs-master-0 ポッドが再作成され、クラスター内の別のノードにスケジュールされます。ディスクボリュームがポッドにマウントされます。そのため、ポッドは再作成され、削除前の状態に復元されます。
説明
この目標を達成するには、再作成されたポッドを、ポッドがデプロイされている元のノードと同じゾーンにある新しいノードにスケジュールする必要があります。これは、ディスクをゾーン間でマウントできないためです。そのため、ポッドが最初にデプロイされたゾーンに少なくとも 2 つのノードが含まれていることを確認する必要があります。
次のコマンドを実行して、アプリケーションポッドを削除し、システムがポッドを再作成するのを待ちます。
```
kubectl delete -f pod.yaml && kubectl create -f pod.yaml
```
予期される出力:
```
pod "nginx" deleted
pod/nginx created
```
次のコマンドを実行して、再作成されたアプリケーションポッドからデータにアクセスします。
```
kubectl exec -it nginx -- ls /data
```
データセットのマウントポイント (Dataset.spec.mountPoint) で指定された OSS バケット内のデータが出力に返されることが予期されます。

ステップ 4: 環境をクリアする

次のコマンドを実行して、アプリケーションポッドを削除します。
```
kubectl delete -f pod.yaml
```
予期される出力:
```
pod "nginx" deleted
```
次のコマンドを実行して、ノードから taint を削除します。
```
kubectl taint node $master_node test-jindofs-master-
```
予期される出力:
```
node/cn-beijing.192.168.xx.xx untainted
```
(オプション) 次のコマンドを順番に実行して、ディスクボリュームに関連するリソースを削除します。
重要
- ディスクボリュームを作成すると、ボリューム用に作成されたディスクに対して課金されます。データアクセラレーションを使用する必要がなくなった場合は、環境をクリアしてください。ディスクボリュームによって発生する料金の詳細については、「ディスクボリューム」をご参照ください。
- リソースをクリアする前に、データセットを使用しているアプリケーションがなく、データセットで I/O 操作が実行されていないことを確認してください。
```
kubectl delete -f dataset.yaml
kubectl delete -f pvc.yaml
```