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

Container Compute Service:静的にプロビジョニングされた OSS ボリュームのマウント

最終更新日:Nov 20, 2025

アプリケーションで画像、音声ファイル、動画ファイルなどの非構造化データを保存する必要がある場合は、Object Storage Service (OSS) ボリュームを永続ボリューム (PV) としてアプリケーションにマウントできます。このトピックでは、静的にプロビジョニングされた OSS ボリュームをアプリケーションにマウントする方法と、OSS ボリュームを使用してデータを共有および永続化できることを確認する方法について説明します。

背景情報

OSS は、Alibaba Cloud が提供する、安全でコスト効率が高く、大容量で信頼性の高いクラウドストレージサービスです。OSS は、画像、音声ファイル、動画ファイルなど、頻繁に変更されない非構造化データの保存に適しています。詳細については、「ストレージの概要」をご参照ください。

OSS ボリュームクライアント

OSS ボリュームは、Filesystem in Userspace (FUSE) に基づくクライアントを使用して、ファイルシステムとしてローカルにマウントできます。従来のローカル記憶域やブロックストレージと比較して、FUSE ベースのクライアントには POSIX 互換性の点でいくつかの制限があります。ACS は、次の OSS ボリュームクライアントをサポートしています。

シナリオ

クライアント

タイプ

説明

読み取り/書き込み操作やユーザー権限設定が必要なシナリオなど、ほとんどのシナリオ。

ossfs 1.0

FUSE

追加書き込み、ランダム書き込み、ユーザー権限設定など、ほとんどの POSIX 操作をサポートします。

AI トレーニング、推論、ビッグデータ処理、自動運転などの読み取り専用またはシーケンシャルな追加専用書き込みシナリオ。

ossfs 2.0

FUSE

完全な読み取りとシーケンシャルな追加書き込みをサポートします。AI トレーニング、推論、ビッグデータ処理、自動運転などの読み取り集中型のシナリオに適しており、データ読み取りパフォーマンスを大幅に向上させることができます。

ossfs 2.0 は現在、GPU 計算能力のみをサポートしています。CPU 計算能力を使用するには、チケットを送信して申請してください。
  • アプリケーションの読み取りおよび書き込みモデルが不明な場合は、ossfs 1.0 を使用してください。ossfs 1.0 は、より優れた POSIX 互換性を提供し、安定したアプリケーション操作を保証します。

  • 読み取り操作と書き込み操作が同時に実行されない、または異なるファイルに対して実行される (たとえば、ブレークポイントの保存や永続的なログの保存など) など、読み取り操作と書き込み操作を分離できるシナリオでは、異なるボリュームを使用できます。たとえば、ossfs 2.0 ボリュームを使用して読み取り専用パスをマウントし、ossfs 1.0 ボリュームを使用して書き込みパスをマウントできます。

POSIX API サポート

次の表に、ossfs 1.0 と ossfs 2.0 が提供する一般的な POSIX API のサポートについて説明します。

POSIX API サポート

カテゴリ

操作/機能

ossfs 1.0

ossfs 2.0

基本的なファイル操作

open

サポートされています

サポート

flush

サポートされています

サポートされています

close

サポートされています

サポートされています

ファイルの読み取り/書き込み

read

サポート

サポート

write

ランダム書き込みをサポート (ディスクキャッシュ設定が必要)

シーケンシャル書き込みのみをサポート (ディスクキャッシュは不要)

truncate

サポートされています (ファイルサイズを調整可能)

ファイルコンテンツのクリアのみをサポート

ファイルメタデータ操作

create

サポートされています

サポートされています

unlink

サポートされています

サポートされています

rename

サポートされています

サポート

ディレクトリ操作

mkdir

サポートされています

サポートされています

readdir

サポート

サポートされています

rmdir

サポートされています

サポートされています

権限とプロパティ

getattr

サポートされています

サポートされています

chmod

サポートされています

サポートされています (操作はエラーを報告しませんが、設定は効果がありません)

chown

サポートされています

サポートされています (操作はエラーを報告しませんが、設定は効果がありません)

utimes

サポートされています

サポートされています

拡張機能

setxattr

サポートされています

サポートされていません

symlink

サポートされています

サポートされていません

lock

サポートされていません

サポートされていません

パフォーマンスベンチマーク

ossfs 2.0 は、シーケンシャルな読み取りと書き込み、および小さなファイルの同時読み取りにおいて、ossfs 1.0 よりも大幅なパフォーマンス向上を提供します。

  • シーケンシャル書き込みパフォーマンス: 単一スレッドでの大きなファイルのシーケンシャル書き込みの場合、ossfs 2.0 は ossfs 1.0 の約 18 倍の帯域幅を提供します。

  • シーケンシャル読み取りパフォーマンス

    • 単一スレッドでの大きなファイルのシーケンシャル読み取りの場合、ossfs 2.0 は ossfs 1.0 の約 8.5 倍の帯域幅を提供します。

    • マルチスレッド (4 スレッド) での大きなファイルのシーケンシャル読み取りの場合、ossfs 2.0 は ossfs 1.0 の 5 倍以上の帯域幅を提供します。

  • 小さなファイルの同時読み取りパフォーマンス: 高い同時実行性 (128 スレッド) での小さなファイルの読み取りの場合、ossfs 2.0 は ossfs 1.0 の 280 倍以上の帯域幅を提供します。

レイテンシーやスループットなどの読み取り/書き込みパフォーマンスが要件を満たさない場合は、「OSS ボリュームのパフォーマンスを最適化するためのベストプラクティス」をご参照ください。

前提条件

ACS クラスターに managed-csiprovisioner コンポーネントがインストールされていること。

説明

ACS コンソールの ACS クラスター管理ページに移動します。クラスター管理ページの左側のナビゲーションウィンドウで、[運用] > [アドオン] を選択します。[ストレージ] タブで、managed-csiprovisioner がインストールされているかどうかを確認できます。

使用上の注意

説明

以下の注意点は、主に一般的な読み取り/書き込みシナリオ (ossfs 1.0) に適用されます。ossfs 2.0 クライアントは一部の POSIX 操作 (主に読み取り操作) のみをサポートするため、通常は適用されません。

  • ACS は、静的にプロビジョニングされた OSS ボリュームのみをサポートします。動的にプロビジョニングされた OSS ボリュームはサポートされていません。

  • ランダム書き込みまたは追加書き込みでは、ローカルに新しいファイルを作成し、OSS サーバーに再アップロードする必要があります。OSS のストレージ特性のため、次の点に注意してください。

    • ファイルとフォルダの名前変更操作はアトミックではありません。

    • 同時書き込みや、マウントパスで直接圧縮や展開などの操作を実行することは避けてください。

      重要

      マルチ書き込みシナリオでは、各クライアントの動作を調整する必要があります。ACS は、書き込み操作によって引き起こされるメタデータまたはデータの問題について、データ整合性を保証しません。

さらに、次の制限事項に注意してください。

  • ハードリンクはサポートされていません。

  • ストレージクラスがアーカイブストレージ、コールドアーカイブ、またはディープコールドアーカイブのバケットはマウントできません。

  • ossfs 1.0 ボリュームの場合、readdir 操作はデフォルトで多数の headObject リクエストを送信し、パス内のすべてのオブジェクトの拡張情報を取得します。宛先パスに多数のファイルが含まれている場合、ossfs の全体的なパフォーマンスが影響を受ける可能性があります。読み取り/書き込みシナリオでファイル権限やその他のプロパティが重要でない場合は、-o readdir_optimize パラメーターを有効にしてパフォーマンスを最適化できます。詳細については、「新しい readdir 最適化機能」をご参照ください。

OSS バケットの作成とバケット情報の取得

  1. OSS バケットを作成します。

    1. OSS コンソールにログインします。左側のナビゲーションウィンドウで、[バケット] をクリックします。

    2. [バケットの作成] をクリックします。

    3. 表示されるパネルで、OSS バケットのパラメーターを設定し、[作成] をクリックします。

      次の表に、主要なパラメーターを示します。詳細については、「バケットの作成」をご参照ください。

      パラメーター

      説明

      バケット名

      カスタム名を入力します。名前は OSS 内でグローバルに一意である必要があり、バケットの作成後は変更できません。フォーマット要件の詳細については、画面の指示をご参照ください。

      リージョン

      [リージョン固有] を選択し、ACS クラスターが存在するリージョンを選択します。これにより、ACS クラスター内の Pod が内部ネットワーク経由で OSS バケットにアクセスできるようになります。

  2. (オプション) OSS バケットのサブディレクトリをマウントするには、サブディレクトリを作成します。

    1. [バケット] ページで、宛先バケットの名前をクリックします。

    2. バケット詳細ページの左側のナビゲーションウィンドウで、[ファイル] > [オブジェクト] を選択します。

    3. [ディレクトリの作成] をクリックして、OSS バケットに必要なディレクトリを作成します。

  3. OSS バケットのエンドポイントを取得します。

    1. [バケット] ページで、宛先バケットの名前をクリックします。

    2. バケット詳細ページで、[概要] タブをクリックします。[ポート] セクションで、エンドポイントをコピーします。

      • OSS バケットと ACS クラスターが同じリージョンにある場合は、VPC エンドポイントをコピーします。

      • バケットがリージョンに依存しないか、ACS クラスターとは異なるリージョンにある場合は、パブリックエンドポイントをコピーします。

  4. OSS へのアクセスを承認するための AccessKey ID と AccessKey Secret を取得します。詳細については、「AccessKey ペアの取得」をご参照ください。

    説明

    別の Alibaba Cloud アカウントに属する OSS バケットをマウントするには、そのアカウントから AccessKey ペアを取得する必要があります。

OSS ボリュームのマウント

ossfs 1.0 ボリューム

kubectl

ステップ 1: PV の作成

  1. 次の YAML コンテンツを oss-pv.yaml として保存します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: oss-secret
      namespace: default
    stringData:
      akId: <お使いの AccessKey ID>
      akSecret: <お使いの AccessKey Secret>
    ---
    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: oss-pv
      labels:
        alicloud-pvname: oss-pv
    spec:
      storageClassName: test 
      capacity:
        storage: 20Gi
      accessModes:
        - ReadWriteMany
      persistentVolumeReclaimPolicy: Retain
      csi:
        driver: ossplugin.csi.alibabacloud.com
        volumeHandle: oss-pv
        nodePublishSecretRef:
          name: oss-secret
          namespace: default
        volumeAttributes:
          bucket: "<お使いの OSS バケット名>"
          url: "<お使いの OSS バケットのエンドポイント>"
          otherOpts: "-o umask=022 -o allow_other"
    説明

    上記の YAML は、シークレットと PV を作成します。シークレットには、PV が安全に使用するための AccessKey ペアが格納されます。akId の値を AccessKey ID に、akSecret の値を AccessKey Secret に置き換えてください。

    次の表に、PV パラメーターを示します。

    パラメーター

    説明

    alicloud-pvname

    PV のラベル。PVC をバインドするために使用されます。

    storageClassName

    この設定は PVC をバインドするためにのみ使用されます。実際の StorageClass を関連付ける必要はありません。

    storage

    OSS ボリュームのストレージ容量。

    説明

    静的にプロビジョニングされた OSS ボリュームの容量は宣言のみを目的としています。実際の容量は制限されません。利用可能な容量は、OSS コンソールに表示される量に従います。

    accessModes

    アクセスモード。

    persistentVolumeReclaimPolicy

    再利用ポリシー。

    driver

    ドライバーのタイプ。ここでは、ossplugin.csi.alibabacloud.com に設定されており、Alibaba Cloud OSS CSI プラグインが使用されることを示します。

    volumeHandle

    PV の一意の識別子。metadata.name と一致する必要があります。

    nodePublishSecretRef

    指定されたシークレットから AccessKey ペアを取得して権限付与を行います。

    bucket

    OSS バケットの名前。bucket の値を実際の OSS バケット名に置き換えてください。

    url

    OSS バケットのエンドポイント。url の値を実際の OSS バケットのエンドポイントに置き換えてください。

    • OSS バケットと ACS クラスターが同じリージョンにある場合は、VPC エンドポイントを使用します。例: oss-cn-shanghai-internal.aliyuncs.com

    • バケットがリージョンに依存しないか、ACS クラスターとは異なるリージョンにある場合は、パブリックエンドポイントを使用します。例: oss-cn-shanghai.aliyuncs.com

    otherOpts

    OSS ボリュームのカスタムパラメーターを -o *** -o *** の形式で入力します (例: -o umask=022 -o max_stat_cache_size=100000 -o allow_other)。

    説明の表示

    • umask: ossfs ファイルの読み取り権限を変更します。

      たとえば、umask=022 は ossfs ファイルの権限を 755 に変更します。これにより、SDK や OSS コンソールなど、他の方法でアップロードされたファイルの権限問題が解決されます。これらのファイルのデフォルト権限は 640 です。読み取り/書き込み分離またはマルチユーザーアクセスの場合、このパラメーターを設定することをお勧めします。

    • max_stat_cache_size: メタデータキャッシュエントリの上限を設定します (例: 100000)。オブジェクトのメタデータをメモリにキャッシュして、lsstat などの操作のパフォーマンスを向上させます。

      ただし、このキャッシュは、OSS コンソール、SDK、または ossutil を介して行われたファイルの変更を迅速に検出できません。これにより、アプリケーションが不整合なデータを読み取る可能性があります。厳密なデータ整合性要件がある場合は、このパラメーターを 0 (キャッシュを無効にする) に設定するか、stat_cache_expire パラメーターでキャッシュの有効期限を短くします。これにより、読み取りパフォーマンスが低下します。

    • allow_other: マウントユーザー以外のユーザーがマウントポイント内のファイルやディレクトリにアクセスできるようにします。これは、マウントユーザー以外のユーザーもデータにアクセスする必要があるマルチユーザー共有環境に適しています。

    その他のオプションパラメーターについては、「マウントオプション」および「ossfs 1.0 設定のベストプラクティス」をご参照ください。

  2. 次のコマンドを実行して、シークレットと PV を作成します。

    kubectl create -f oss-pv.yaml
  3. PV のステータスを確認します。

    kubectl get pv

    期待される出力:

    NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
    oss-pv   20Gi       RWX            Retain           Available           test           <unset>                          9s

ステップ 2: PVC の作成

  1. 次の YAML コンテンツを oss-pvc.yaml として保存します。

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: oss-pvc
    spec:
      storageClassName: test
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 20Gi
      selector:
        matchLabels:
          alicloud-pvname: oss-pv

    次の表に、パラメーターを示します。

    パラメーター

    説明

    storageClassName

    この設定は PVC をバインドするためにのみ使用されます。実際の StorageClass を関連付ける必要はありません。PV の spec.storageClassName と一致する必要があります。

    accessModes

    アクセスモード。

    storage

    Pod に割り当てられるストレージ容量。OSS ボリュームの容量を超えることはできません。

    alicloud-pvname

    バインドする PV のラベル。PV の metadata.labels.alicloud-pvname と一致する必要があります。

  2. PVC を作成できます。

    kubectl create -f oss-pvc.yaml
  3. PVC を確認できます。

    kubectl get pvc

    次の出力は、PVC がステップ 1 で作成した PV にバインドされていることを確認します。

    NAME      STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
    oss-pvc   Bound    oss-pv   20Gi       RWX            test           <unset>                 6s

ステップ 3: アプリケーションの作成と OSS ボリュームのマウント

  1. 次の YAML コンテンツを oss-test.yaml として保存します。

    次の YAML の例では、2 つの Pod を持つデプロイメントを作成します。両方の Pod は、oss-pvc という名前の PVC を使用してストレージリソースを要求します。両方のマウントパスは /data です。

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: oss-test
      labels:
        app: nginx
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginx:latest
            ports:
            - containerPort: 80
            volumeMounts:
              - name: pvc-oss
                mountPath: /data
          volumes:
            - name: pvc-oss
              persistentVolumeClaim:
                claimName: oss-pvc
  2. 次のコマンドを実行して、デプロイメントを作成し、OSS ボリュームをマウントします。

    kubectl create -f oss-test.yaml
  3. デプロイメント内の Pod のステータスを確認します。

    kubectl get pod | grep oss-test

    次の出力例は、2 つの Pod が作成されたことを示しています。

    oss-test-****-***a   1/1     Running   0          28s
    oss-test-****-***b   1/1     Running   0          28s
  4. マウントパスを表示します。

    次のコマンドは一例です。デフォルトでは、ディレクトリは空であり、出力は返されません。

    kubectl exec oss-test-****-***a -- ls /data

コンソール

ステップ 1: PV の作成

  1. ACS コンソールにログインします。

  2. [クラスター] で、クラスターの名前をクリックしてクラスター管理ページに移動します。

  3. クラスター管理ページの左側のナビゲーションウィンドウで、[ボリューム] > [永続ボリューム] を選択します。

  4. [永続ボリューム] ページで、[作成] をクリックします。

  5. [永続ボリュームの作成] ダイアログボックスで、パラメーターを設定し、[作成] をクリックします。

    パラメーター

    説明

    PV タイプ

    [OSS] を選択します。

    OSS

    名前

    PV のカスタム名を入力します。フォーマット要件の詳細については、画面の指示をご参照ください。

    oss-pv

    容量

    OSS ボリュームのストレージ容量。

    説明

    静的にプロビジョニングされた OSS ボリュームの容量は宣言のみを目的としています。実際の容量は制限されません。利用可能な容量は、OSS コンソールに表示される量に従います。

    20 Gi

    アクセスモード

    必要に応じて、次のいずれかのオプションを選択します。

    • ReadOnlyMany: ボリュームは、複数の Pod によって読み取り専用モードでマウントできます。

    • ReadWriteMany: ボリュームは、複数の Pod によって読み取り/書き込みモードでマウントできます。

    ReadWriteMany

    アクセス証明書

    セキュリティを確保するために、AccessKey 情報をシークレットに保存します。このトピックでは、[シークレットの作成] を例として使用します。

    • シークレットの作成

    • 名前空間: default

    • 名前: oss-secret

    • AccessKey ID: ********

    • AccessKey Secret: ********

    バケット ID

    OSS バケットを選択します。

    oss-acs-***

    OSS パス

    マウントするディレクトリ。デフォルトでは、ルートディレクトリ (/) がマウントされます。必要に応じて、サブディレクトリ (たとえば /dir) をマウントできます。サブディレクトリがすでに存在することを確認してください。

    /

    エンドポイント

    OSS バケットのエンドポイント。

    • OSS バケットと ACS クラスターが同じリージョンにある場合は、[内部エンドポイント] を選択します。

    • バケットがリージョンに依存しないか、ACS クラスターとは異なるリージョンにある場合は、[パブリックエンドポイント] を選択します。

    プライベートドメイン名

    PV が作成された後、[永続ボリューム] ページでその情報を表示できます。PV はまだ PVC にバインドされていません。

ステップ 2: PVC の作成

  1. クラスター管理ページの左側のナビゲーションウィンドウで、[ボリューム] > [Persistent Volume Claim] を選択します。

  2. [Persistent Volume Claim] ページで、[作成] をクリックします。

  3. [Persistent Volume Claim の作成] ダイアログボックスで、パラメーターを設定し、[作成] をクリックします。

    パラメーター

    説明

    PVC タイプ

    [OSS] を選択します。

    OSS

    名前

    PVC のカスタム名を入力します。フォーマット要件の詳細については、画面の指示をご参照ください。

    oss-pvc

    割り当てモード

    [既存ボリューム] を選択します。

    既存ボリューム

    既存ボリューム

    以前に作成した PV を選択します。

    oss-pv

    合計

    Pod に割り当てられるストレージ容量。OSS ボリュームの容量を超えることはできません。

    20 Gi

    PVC が作成された後、[Persistent Volume Claim] ページでその詳細を表示できます。PVC は対応する永続ボリューム (PV)、つまり OSS ボリュームにバインドされます。

ステップ 3: アプリケーションの作成と OSS ボリュームのマウント

  1. クラスター管理ページの左側のナビゲーションウィンドウで、[ワークロード] > [デプロイメント] を選択します。

  2. [ステートレス] ページで、[イメージから作成] をクリックします。

  3. デプロイメントのパラメーターを設定し、[作成] をクリックします。

    次の表に、主要なパラメーターを示します。他のパラメーターはデフォルト値のままにします。詳細については、「Deployment からステートレスアプリケーションを作成する」をご参照ください。

    設定ページ

    パラメーター

    説明

    基本情報

    アプリケーション名

    デプロイメントのカスタム名を入力します。フォーマット要件の詳細については、画面の指示をご参照ください。

    oss-test

    レプリカ数

    デプロイメントのレプリカ数を設定します。

    2

    コンテナー設定

    イメージ名

    アプリケーションのデプロイに使用するイメージのアドレスを入力します。

    registry.cn-hangzhou.aliyuncs.com/acs-sample/nginx:latest

    必須リソース

    必要な vCPU とメモリリソースを設定します。

    0.25 vCPU, 0.5 GiB

    ボリューム

    [クラウドストレージ要求の追加] をクリックし、パラメーターを設定します。

    • マウントソース: 以前に作成した PVC を選択します。

    • コンテナーパス: OSS バケットをマウントするコンテナーパスを入力します。

    • マウントソース: oss-pvc

    • コンテナーパス: /data

  4. アプリケーションのデプロイメントのステータスを確認します。

    1. [ステートレス] ページで、アプリケーション名をクリックします。

    2. [Pod] タブで、Pod が実行中状態であることを確認します。

ossfs 2.0 ボリューム

静的にプロビジョニングされた ossfs 2.0 ボリュームは、kubectl を使用してのみマウントできます。この操作は ACS コンソールではサポートされていません。

ステップ 1: PV の作成

  1. 次の YAML コンテンツを oss-pv.yaml として保存します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: oss-secret
      namespace: default
    stringData:
      akId: <お使いの AccessKey ID>
      akSecret: <お使いの AccessKey Secret>
    ---
    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: oss-pv
      labels:
        alicloud-pvname: oss-pv
    spec:
      storageClassName: test 
      capacity:
        storage: 20Gi
      accessModes:
        - ReadWriteMany
      persistentVolumeReclaimPolicy: Retain
      csi:
        driver: ossplugin.csi.alibabacloud.com
        volumeHandle: oss-pv
        nodePublishSecretRef:
          name: oss-secret
          namespace: default
        volumeAttributes:
          fuseType: ossfs2 # ossfs 2.0 クライアントの使用を明示的に宣言します
          bucket: "<お使いの OSS バケット名>"
          url: "<お使いの OSS バケットのエンドポイント>"
          otherOpts: "-o close_to_open=false" # 注: サポートされているマウントパラメーターは、ossfs 1.0 クライアントと互換性がありません。
    説明

    上記の YAML は、シークレットと PV を作成します。シークレットには、PV が安全に使用するための AccessKey ペアが格納されます。akId の値を AccessKey ID に、akSecret の値を AccessKey Secret に置き換えてください。

    次の表に、PV パラメーターを示します。

    パラメーター

    説明

    alicloud-pvname

    PV のラベル。PVC をバインドするために使用されます。

    storageClassName

    この設定は PVC をバインドするためにのみ使用されます。実際の StorageClass を関連付ける必要はありません。

    storage

    OSS ボリュームのストレージ容量。

    説明

    静的にプロビジョニングされた OSS ボリュームの容量は宣言のみを目的としています。実際の容量は制限されません。利用可能な容量は、OSS コンソールに表示される量に従います。

    accessModes

    アクセスモード。

    persistentVolumeReclaimPolicy

    再利用ポリシー。

    driver

    ドライバーのタイプ。ここでは、ossplugin.csi.alibabacloud.com に設定されており、Alibaba Cloud OSS CSI プラグインが使用されることを示します。

    volumeHandle

    PV の一意の識別子。metadata.name と一致する必要があります。

    nodePublishSecretRef

    指定されたシークレットから AccessKey ペアを取得して権限付与を行います。

    fuseType

    マウントに使用するクライアントを指定します。ossfs 2.0 クライアントを使用するには、ossfs2 に設定する必要があります。

    bucket

    OSS バケットの名前。bucket の値を実際の OSS バケット名に置き換えてください。

    url

    OSS バケットのエンドポイント。url の値を実際の OSS バケットのエンドポイントに置き換えてください。

    • OSS バケットと ACS クラスターが同じリージョンにある場合は、VPC エンドポイントを使用します。例: oss-cn-shanghai-internal.aliyuncs.com

    • バケットがリージョンに依存しないか、ACS クラスターとは異なるリージョンにある場合は、パブリックエンドポイントを使用します。例: oss-cn-shanghai.aliyuncs.com

    otherOpts

    -o *** -o *** 形式で OSS ボリュームのカスタムパラメーターを入力します。例: -o close_to_open=false

    close_to_open: デフォルトで無効になっています。有効にすると、ファイルが開かれるたびにシステムが GetObjectMeta リクエストを OSS に送信し、OSS 内のファイルの最新のメタデータを取得します。これにより、リアルタイムのメタデータが保証されます。ただし、多くの小さなファイルを読み取る必要があるシナリオでは、頻繁なメタデータクエリによりアクセスレイテンシーが大幅に増加します。

    オプションパラメーターの詳細については、「ossfs 2.0 マウントオプション」をご参照ください。

  2. 次のコマンドを実行して、シークレットと PV を作成します。

    kubectl create -f oss-pv.yaml
  3. PV のステータスを確認します。

    kubectl get pv

    期待される出力:

    NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
    oss-pv   20Gi       RWX            Retain           Available           test           <unset>                          9s

ステップ 2: PVC の作成

  1. 次の YAML コンテンツを oss-pvc.yaml として保存します。

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: oss-pvc
    spec:
      storageClassName: test
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 20Gi
      selector:
        matchLabels:
          alicloud-pvname: oss-pv

    パラメーターは次の表で説明されています。

    パラメーター

    説明

    storageClassName

    この設定は PVC をバインドするためにのみ使用されます。実際の StorageClass を関連付ける必要はありません。PV の spec.storageClassName と一致する必要があります。

    accessModes

    アクセスモード。

    storage

    Pod に割り当てられるストレージ容量。OSS ボリュームの容量を超えることはできません。

    alicloud-pvname

    バインドする PV のラベル。PV の metadata.labels.alicloud-pvname と一致する必要があります。

  2. PVC を作成できます。

    kubectl create -f oss-pvc.yaml
  3. PVC のステータスを確認します。

    kubectl get pvc

    次の出力は、PVC がステップ 1 で作成した PV にバインドされていることを示しています。

    NAME      STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
    oss-pvc   Bound    oss-pv   20Gi       RWX            test           <unset>                 6s

ステップ 3: アプリケーションの作成と OSS ボリュームのマウント

  1. 次の YAML コンテンツを oss-test.yaml として保存します。

    次の YAML の例では、2 つの Pod を持つデプロイメントを作成します。両方の Pod は、oss-pvc という名前の PVC を使用してストレージリソースを要求します。両方のマウントパスは /data です。

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: oss-test
      labels:
        app: nginx
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginx:latest
            ports:
            - containerPort: 80
            volumeMounts:
              - name: pvc-oss
                mountPath: /data
          volumes:
            - name: pvc-oss
              persistentVolumeClaim:
                claimName: oss-pvc
  2. 次のコマンドを実行して、デプロイメントを作成し、OSS ボリュームをマウントします。

    kubectl create -f oss-test.yaml
  3. デプロイメント内の Pod のステータスを確認します。

    kubectl get pod | grep oss-test

    次の出力例は、2 つの Pod が作成されたことを示しています。

    oss-test-****-***a   1/1     Running   0          28s
    oss-test-****-***b   1/1     Running   0          28s
  4. マウントパスを表示します。

    次のコマンドは一例です。デフォルトでは、ディレクトリは空であり、出力は返されません。

    kubectl exec oss-test-****-***a -- ls /data

OSS ボリュームがデータを共有および永続化できることの確認

作成したデプロイメントは 2 つの Pod をプロビジョニングします。同じ OSS バケットが両方の Pod にマウントされます。次の方法を使用して、OSS ボリュームがデータを共有および永続化できることを確認できます。

  • 1 つの Pod にファイルを作成し、そのファイルが他の Pod からアクセスできるかどうかを確認します。ファイルにアクセスできる場合は、データ共有が有効になっています。

  • デプロイメントを再作成します。新しい Pod から OSS ボリュームにアクセスして、元のデータがまだ OSS バケットに存在するかどうかを確認します。データがまだ存在する場合は、データの永続性が有効になっています。

  1. Pod 情報を表示します。

    kubectl get pod | grep oss-test

    出力例:

    oss-test-****-***a   1/1     Running   0          40s
    oss-test-****-***b   1/1     Running   0          40s
  2. 共有ストレージを確認します。

    1. いずれかの Pod にファイルを作成します。

      この例では、oss-test-****-***a という名前の Pod が使用されます。

      kubectl exec oss-test-****-***a -- touch /data/test.txt
    2. 他の Pod からファイルを表示します。

      この例では、oss-test-****-***b という名前の Pod が使用されます。

      kubectl exec oss-test-****-***b -- ls /data

      次の出力は、新しいファイル test.txt が共有されていることを示しています。

      test.txt
  3. Pod の再作成後にデータが永続化されることを確認します。

    1. デプロイメントを削除してから再作成します。

      kubectl rollout restart deploy oss-test
    2. Pod を表示し、新しい Pod が作成されるのを待ちます。

      kubectl get pod | grep oss-test

      出力例:

      oss-test-****-***c   1/1     Running   0          67s
      oss-test-****-***d   1/1     Running   0          49s
    3. 新しい Pod から、ファイルシステム内のデータがまだ存在するかどうかを確認します。

      この例では、oss-test-c*** という名前の Pod が使用されます。

      kubectl exec oss-test-****-***c -- ls /data

      次の出力は、OSS バケット内のデータがまだ存在し、新しい Pod のマウントディレクトリから取得できることを示しています。

      test.txt