すべてのプロダクト
Search
ドキュメントセンター

:名前空間間でデータセットを共有する

最終更新日:Oct 23, 2024

Fluidは、Kubernetesのリソースを名前空間で分離します。 Fluidを使用して、異なるコンピューティングジョブからのデータセットへのアクセスを調整し、異なるチームに属するデータを分離できます。 さらに、Fluidは名前空間間のデータアクセスとキャッシュ共有をサポートします。 Fluidでは、複数のチーム間でデータを共有する必要があるときに、データを1回だけキャッシュする必要があります。 これにより、データ利用効率とデータ管理の柔軟性が大幅に向上し、R&Dチーム間のコラボレーションが容易になります。 このトピックでは、Fluidを使用して名前空間間でデータセットを共有する方法について説明します。

仕組み

FluidはThinRuntimeをサポートしています。これにより、さまざまなストレージシステムに低コードでアクセスし、データオーケストレーションやランタイムプラットフォームを介したデータアクセスなど、Fluidの主要機能を再利用できます。 ThinRuntimeを使用すると、Fluidでは、名前空間のデータセットを別の名前空間のデータセットに関連付けることができます。 これにより、異なる名前空間のアプリケーション間で同じキャッシュランタイムを共有できます。

前提条件

  • 非containerOSを使用したContainer Service for Kubernetes (ACK) Proクラスターが作成され、クラスターのKubernetesバージョンが1.18以降になります。 詳細については、「ACK Proクラスターの作成」をご参照ください。

    重要

    ack − fluidコンポーネントは、現在、ContainerOS上でサポートされていない。

  • クラウドネイティブAIスイートがインストールされ、ack-fluidコンポーネントがデプロイされます。

    重要

    既にオープンソースFluidをインストールしている場合は、Fluidをアンインストールしてack-fluidコンポーネントをデプロイします。

    • クラウドネイティブAIスイートをインストールしていない場合は、スイートのインストール時にFluidアクセラレーションを有効にします。 詳細については、「Deploy the cloud-native AI suite」をご参照ください。

    • クラウドネイティブAIスイートを既にインストールしている場合は、ACKコンソールクラウドネイティブAIスイートページに移動し、ack-fluidコンポーネントをデプロイします。

  • kubectlクライアントがACK Proクラスターに接続されています。 詳細については、「kubectlを使用したクラスターへの接続」をご参照ください。

手順1: テストデータセットをOSSバケットにアップロードする

  1. サイズが2 GBのテストデータセットを作成します。 この例では、テストデータセットが使用されます。

  2. 作成したOSSバケットにテストデータセットをアップロードします。

    OSSが提供するossutilツールを使用して、データをアップロードできます。 詳細については、「ossutilのインストール」をご参照ください。

手順2: 共有データセットとランタイムオブジェクトの作成

JindoRuntime

  1. shareという名前の名前空間を作成します。 次の例では、共有データセットとランタイムオブジェクトがこの名前空間で作成されます。

    kubectl create ns share
  2. 次のコマンドを実行して、Object Storage Service (OSS) バケットへのアクセスに使用されるAccessKeyペアを保存するシークレットを作成します。

    kubectl apply -f-<<EOF                                            
    apiVersion: v1
    kind: Secret
    metadata:
      name: dataset-secret
      namespace: share
    stringData:
      fs.oss.accessKeyId: <YourAccessKey ID>
      fs.oss.accessKeySecret: <YourAccessKey Secret>
    EOF                                         

    上記のコードでは、fs.oss.accessKeyIdパラメーターはAccessKey IDを指定し、fs.oss.accessKeySecretパラメーターはAccessKey secretを指定します。 AccessKeyペアを取得する方法の詳細については、「AccessKeyペアの取得」をご参照ください。

  3. shared-dataset.yamlという名前のファイルを作成し、次の内容をファイルにコピーします。 このファイルは、データセットとJindoRuntimeを作成するために使用されます。 データセットとJindoRuntimeを設定する方法の詳細については、「Use JindoFS to accelerate access to OSS」をご参照ください。

    # Create a dataset that describes the dataset stored in the OSS bucket and the underlying file system (UFS). 
    apiVersion: data.fluid.io/v1alpha1
    kind: Dataset
    metadata:
      name: shared-dataset
      namespace: share
    spec:
      mounts:
      - mountPoint: oss://<oss_bucket>/<bucket_dir> # Replace the value with the path of the file that you want to share in the OSS bucket. 
        options:
          fs.oss.endpoint: <oss_endpoint> # Replace the value with the endpoint of the OSS bucket that you use. 
        name: hadoop
        path: "/"
        encryptOptions:
          - name: fs.oss.accessKeyId
            valueFrom:
              secretKeyRef:
                name: dataset-secret
                key: fs.oss.accessKeyId
          - name: fs.oss.accessKeySecret
            valueFrom:
              secretKeyRef:
                name: dataset-secret
                key: fs.oss.accessKeySecret
    
    ---
    # Create a JindoRuntime to enable JindoFS for data caching in the cluster. 
    apiVersion: data.fluid.io/v1alpha1
    kind: JindoRuntime
    metadata:
      name: shared-dataset
      namespace: share
    spec:
      replicas: 1
      tieredstore:
        levels:
          - mediumtype: MEM
            path: /dev/shm
            quota: 4Gi
            high: "0.95"
            low: "0.7"
  4. 次のコマンドを実行して、データセットとJindoRuntimeを作成します。

    kubectl apply -f shared-dataset.yaml

    期待される出力:

    dataset.data.fluid.io/shared-dataset created
    jindoruntime.data.fluid.io/shared-dataset created

    出力は、データセットとJindoRuntimeが作成されたことを示します。

  5. 数分待ってから次のコマンドを実行し、作成されたデータセットとJindoRuntimeを照会します。

    kubectl get dataset,jindoruntime -nshare

    期待される出力:

    NAME                                   UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
    dataset.data.fluid.io/shared-dataset   1.16GiB          0.00B    4.00GiB          0.0%                Bound   4m1s
    
    NAME                                        MASTER PHASE   WORKER PHASE   FUSE PHASE   AGE
    jindoruntime.data.fluid.io/shared-dataset   Ready          Ready          Ready        15m

    出力は、データセットがJindoRuntimeに関連付けられていることを示します。

JuiceFSRuntime

  1. shareという名前の名前空間を作成します。 次の例では、共有データセットとランタイムオブジェクトがこの名前空間で作成されます。

    kubectl create ns share
  2. 次のコマンドを実行して、OSSバケットへのアクセスに使用されるAccessKeyペアを保存するシークレットを作成します。

    kubectl apply -f-<<EOF
    apiVersion: v1
    kind: 秘密
    メタデータ:
      name: dataset-secret
      名前空間: 共有
    タイプ: 不透明
    stringData:
      token: <JUICEFS_VOLUME_TOKEN>
      access-key: <OSS_ACCESS_KEY>
      secret-key: <OSS_SECRET_KEY>
    EOF 

    上記のコードでは、access-keyパラメーターはAccessKey IDを指定し、secret-keyパラメーターはAccessKey secretを指定します。 AccessKeyペアを取得する方法の詳細については、「AccessKeyペアの取得」をご参照ください。

  3. shared-dataset.yamlという名前のファイルを作成し、次の内容をファイルにコピーします。 このファイルは、データセットとJuiceFSRuntimeを作成するために使用されます。

    # OSSバケットとUFSに保存されているデータセットを記述するデータセットを作成します。 
    apiVersion: data.fluid.io/v1alpha 1
    kind: データセット
    メタデータ:
      name: shared-dataset
      名前空間: 共有
    spec:
      accessModes: ["ReadOnlyMany"]
      sharedEncryptOptions:
      -name: アクセスキー
        valueFrom:
          secretKeyRef:
            name: dataset-secret
            キー: アクセスキー
      -name: secret-key
        valueFrom:
          secretKeyRef:
            name: dataset-secret
            key: secret-key
      -name: トークン
        valueFrom:
          secretKeyRef:
            name: dataset-secret
            キー: トークン
      mounts:
      -name: <JUICEFS_VOLUME_NAME>
        mountPoint: juicefs:///# ファイルシステムのマウントポイントはjuicefs:/// です。 
        options:
          bucket: https://<OSS_BUCKET_NAME>.oss-<REGION_ID>.aliyuncs.com# 値を使用するOSSバケットのエンドポイントに置き換えます。 例: https://mybucket.oss-cn-beijing-internal.aliyuncs.com 。
    ---
    # JuiceFSRuntimeを作成して、クラスターでのデータキャッシュ用にJuiceFSを有効にします。 
    apiVersion: data.fluid.io/v1alpha 1
    種類: JuiceFSRuntime
    メタデータ:
      name: shared-dataset
      名前空間: 共有
    spec:
      replicas: 1
      tieredstore:
        レベル:
        -mediumtype: MEM
          パス: /dev/shm
          クォータ: 1Gi
          high: "0.95"
          low: "0.7" 
  4. 次のコマンドを実行して、データセットとJuiceFSRuntimeを作成します。

    kubectl apply -f shared-dataset.yaml

    期待される出力:

    dataset.data.fluid.io/shared-dataset created
    juicefsruntime.data.fluid.io/shared-dataset created 

    出力は、データセットとJuiceFSRuntimeが作成されたことを示します。

  5. 数分待ってから次のコマンドを実行し、作成されたデータセットとJuiceFSRuntimeを照会します。

    kubectl getデータセット、juicefsruntime -nshare

    期待される出力:

    名UFS合計サイズキャッシュキャッシュ容量キャッシュパーセント位相年齢
    dataset.data.fluid.io/shared-dataset 2.32GiB 0.00B 4.00GiB 0.0% バインド3d16h
    
    名前労働者フェーズヒューズフェーズ年齢
    juicefsruntime.data.fluid.io/shared-dataset 3m50s
    

ステップ3: 参照データセットとポッドを作成する

  1. refという名前の名前空間を作成します。 次の例では、この名前空間にref-datasetデータセットが作成されます。

    kubectl create ns ref
  2. ref-dataset.yamlという名前のファイルを作成し、次の内容をファイルにコピーします。 このファイルは、ref名前空間にref-datasetという名前のデータセットを作成するために使用されます。 データセットを使用して、別の異なる名前空間 (この例では共有名前空間) のデータセットにアクセス (参照) できます。

    重要

    Fluidでは、データセットを一意のパスにマウントする必要があります。 さらに、データセットのmountPointパラメーターの値は、dataset:// 形式である必要があります。 他の形式でmountPointの値を指定した場合、データセットは作成できず、specセクションのフィールドは有効になりません。

    apiVersion: data.fluid.io/v1alpha1
    kind: Dataset
    metadata:
      name: ref-dataset
      namespace: ref
    spec:
      mounts:
      - mountPoint: dataset://share/shared-dataset

    次のリストに、mountPointパラメーターの値を示します。

    • dataset://: プロトコルプレフィックス。データセットが参照されていることを示します。

    • share: 参照されるデータセットが属する名前空間。この例ではshareです。

    • shared-dataset: 参照されるデータセットの名前。

  3. 次のコマンドを実行して、ref-dataset.yamlファイルで定義されているリソースをクラスターにデプロイします。

    kubectl apply -f ref-dataset.yaml        
  4. app.yamlという名前のファイルを作成し、次の内容をファイルにコピーします。 ファイルはref名前空間にポッドを作成するために使用され、ポッドはref-datasetデータセットを使用します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx
      namespace: ref
    spec:
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        command:
        - "bash"
        - "-c"
        - "sleep inf"
        volumeMounts:
        - mountPath: /data
          name: ref-data
      volumes:
      - name: ref-data
        persistentVolumeClaim:
          claimName: ref-dataset
  5. 次のコマンドを実行して、app.yamlファイルで定義されているリソースをクラスターにデプロイします。

    kubectl apply -f app.yaml
  6. 次のコマンドを実行して、ref名前空間のポッドを照会します。

    kubectl get pods -n ref -o wide

    出力のポッドが [実行中] 状態の場合、ポッドが作成されます。

ステップ3: テストデータ共有とキャッシュ

  1. 次のコマンドを実行して、shareおよびref名前空間のポッドを照会します。

    kubectl get pods -n share
    kubectl get pods -n ref

    期待される出力:

    # The following list shows the pods in the share namespace. 
    NAME                                READY   STATUS    RESTARTS   AGE
    shared-dataset-jindofs-fuse-ftkb5   1/1     Running   0          44s
    shared-dataset-jindofs-master-0     1/1     Running   0          9m13s
    shared-dataset-jindofs-worker-0     1/1     Running   0          9m13s
    # The following list shows the pods in the ref namespace. 
    NAME    READY   STATUS    RESTARTS   AGE
    nginx   1/1     Running   0          118s

    出力は、3つのデータセット関連ポッドがshare名前空間で実行されていることを示しています。 ref名前空間では、nginxという名前のポッドが1つだけ実行されます。 ref名前空間では、データセット関連のポッドは実行されません。

  2. データ共有とキャッシュをテストします。

    1. 次のコマンドを実行して、nginxポッドにログインします。

      kubectl exec nginx -n ref -it -- sh
    2. テストデータ共有。

      次のコマンドを実行して、/dataディレクトリ内のファイルを照会します。the ref-dataset dataset is located in the /data path of the ref namespace.

      du -sh /data/wwm_uncased_L-24_H-1024_A-16.zip

      期待される出力:

      1.3G	/data/wwm_uncased_L-24_H-1024_A-16.zip

      出力は、ref名前空間のnginxポッドが、share名前空間に属するconfig.jsonファイルにアクセスできることを示しています。

    3. データキャッシュのテスト

      説明

      次のテスト結果は参照だけのためです。 実際の読み取りレイテンシは、実際の条件に基づいて異なります。

      # The read latency when the file is read for the first time. 
      sh-4.4# time cat /data/wwm_uncased_L-24_H-1024_A-16.zip > /dev/null
      real	0m1.166s
      user	0m0.007s
      sys	0m1.154s
      
      # Read the file again to test whether the read latency is reduced after the file is cached.
      sh-4.4# time cat /data/wwm_uncased_L-24_H-1024_A-16.zip > /dev/null
      real	0m0.289s
      user	0m0.011s
      sys	0m0.274s

      出力は、最初にファイルを読み取るために1.166秒が必要であり、2番目にファイルを読み取るために必要な時間が0.289秒に短縮されることを示しています。 これは、ファイルがキャッシュされていることを示します。