アプリケーションで画像、音声ファイル、動画ファイルなどの非構造化データを保存する必要がある場合は、Object Storage Service (OSS) ボリュームを永続ボリューム (PV) としてアプリケーションにマウントできます。このトピックでは、静的にプロビジョニングされた OSS ボリュームをアプリケーションにマウントする方法と、OSS ボリュームを使用してデータを共有および永続化できることを確認する方法について説明します。
背景情報
OSS は、Alibaba Cloud が提供する、安全でコスト効率が高く、大容量で信頼性の高いクラウドストレージサービスです。OSS は、画像、音声ファイル、動画ファイルなど、頻繁に変更されない非構造化データの保存に適しています。詳細については、「ストレージの概要」をご参照ください。
OSS ボリュームクライアント
OSS ボリュームは、Filesystem in Userspace (FUSE) に基づくクライアントを使用して、ファイルシステムとしてローカルにマウントできます。従来のローカル記憶域やブロックストレージと比較して、FUSE ベースのクライアントには POSIX 互換性の点でいくつかの制限があります。ACS は、次の OSS ボリュームクライアントをサポートしています。
シナリオ | クライアント | タイプ | 説明 |
読み取り/書き込み操作やユーザー権限設定が必要なシナリオなど、ほとんどのシナリオ。 | FUSE | 追加書き込み、ランダム書き込み、ユーザー権限設定など、ほとんどの POSIX 操作をサポートします。 | |
AI トレーニング、推論、ビッグデータ処理、自動運転などの読み取り専用またはシーケンシャルな追加専用書き込みシナリオ。 | 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 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 バケットの作成とバケット情報の取得
OSS バケットを作成します。
OSS コンソールにログインします。左側のナビゲーションウィンドウで、[バケット] をクリックします。
[バケットの作成] をクリックします。
表示されるパネルで、OSS バケットのパラメーターを設定し、[作成] をクリックします。
次の表に、主要なパラメーターを示します。詳細については、「バケットの作成」をご参照ください。
パラメーター
説明
バケット名
カスタム名を入力します。名前は OSS 内でグローバルに一意である必要があり、バケットの作成後は変更できません。フォーマット要件の詳細については、画面の指示をご参照ください。
リージョン
[リージョン固有] を選択し、ACS クラスターが存在するリージョンを選択します。これにより、ACS クラスター内の Pod が内部ネットワーク経由で OSS バケットにアクセスできるようになります。
(オプション) OSS バケットのサブディレクトリをマウントするには、サブディレクトリを作成します。
[バケット] ページで、宛先バケットの名前をクリックします。
バケット詳細ページの左側のナビゲーションウィンドウで、 を選択します。
[ディレクトリの作成] をクリックして、OSS バケットに必要なディレクトリを作成します。
OSS バケットのエンドポイントを取得します。
[バケット] ページで、宛先バケットの名前をクリックします。
バケット詳細ページで、[概要] タブをクリックします。[ポート] セクションで、エンドポイントをコピーします。
OSS バケットと ACS クラスターが同じリージョンにある場合は、VPC エンドポイントをコピーします。
バケットがリージョンに依存しないか、ACS クラスターとは異なるリージョンにある場合は、パブリックエンドポイントをコピーします。
OSS へのアクセスを承認するための AccessKey ID と AccessKey Secret を取得します。詳細については、「AccessKey ペアの取得」をご参照ください。
説明別の Alibaba Cloud アカウントに属する OSS バケットをマウントするには、そのアカウントから AccessKey ペアを取得する必要があります。
OSS ボリュームのマウント
ossfs 1.0 ボリューム
kubectl
ステップ 1: PV の作成
次の 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-pvnamePV のラベル。PVC をバインドするために使用されます。
storageClassNameこの設定は PVC をバインドするためにのみ使用されます。実際の StorageClass を関連付ける必要はありません。
storageOSS ボリュームのストレージ容量。
説明静的にプロビジョニングされた OSS ボリュームの容量は宣言のみを目的としています。実際の容量は制限されません。利用可能な容量は、OSS コンソールに表示される量に従います。
accessModesアクセスモード。
persistentVolumeReclaimPolicy再利用ポリシー。
driverドライバーのタイプ。ここでは、
ossplugin.csi.alibabacloud.comに設定されており、Alibaba Cloud OSS CSI プラグインが使用されることを示します。volumeHandlePV の一意の識別子。
metadata.nameと一致する必要があります。nodePublishSecretRef指定されたシークレットから AccessKey ペアを取得して権限付与を行います。
bucketOSS バケットの名前。
bucketの値を実際の OSS バケット名に置き換えてください。urlOSS バケットのエンドポイント。
urlの値を実際の OSS バケットのエンドポイントに置き換えてください。OSS バケットと ACS クラスターが同じリージョンにある場合は、VPC エンドポイントを使用します。例:
oss-cn-shanghai-internal.aliyuncs.com。バケットがリージョンに依存しないか、ACS クラスターとは異なるリージョンにある場合は、パブリックエンドポイントを使用します。例:
oss-cn-shanghai.aliyuncs.com。
otherOptsOSS ボリュームのカスタムパラメーターを
-o *** -o ***の形式で入力します (例:-o umask=022 -o max_stat_cache_size=100000 -o allow_other)。次のコマンドを実行して、シークレットと PV を作成します。
kubectl create -f oss-pv.yamlPV のステータスを確認します。
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 の作成
次の 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アクセスモード。
storagePod に割り当てられるストレージ容量。OSS ボリュームの容量を超えることはできません。
alicloud-pvnameバインドする PV のラベル。PV の
metadata.labels.alicloud-pvnameと一致する必要があります。PVC を作成できます。
kubectl create -f oss-pvc.yamlPVC を確認できます。
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 ボリュームのマウント
次の 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次のコマンドを実行して、デプロイメントを作成し、OSS ボリュームをマウントします。
kubectl create -f oss-test.yamlデプロイメント内の 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マウントパスを表示します。
次のコマンドは一例です。デフォルトでは、ディレクトリは空であり、出力は返されません。
kubectl exec oss-test-****-***a -- ls /data
コンソール
ステップ 1: PV の作成
ACS コンソールにログインします。
[クラスター] で、クラスターの名前をクリックしてクラスター管理ページに移動します。
クラスター管理ページの左側のナビゲーションウィンドウで、 を選択します。
[永続ボリューム] ページで、[作成] をクリックします。
[永続ボリュームの作成] ダイアログボックスで、パラメーターを設定し、[作成] をクリックします。
パラメーター
説明
例
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 の作成
クラスター管理ページの左側のナビゲーションウィンドウで、 を選択します。
[Persistent Volume Claim] ページで、[作成] をクリックします。
[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 ボリュームのマウント
クラスター管理ページの左側のナビゲーションウィンドウで、 を選択します。
[ステートレス] ページで、[イメージから作成] をクリックします。
デプロイメントのパラメーターを設定し、[作成] をクリックします。
次の表に、主要なパラメーターを示します。他のパラメーターはデフォルト値のままにします。詳細については、「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
アプリケーションのデプロイメントのステータスを確認します。
[ステートレス] ページで、アプリケーション名をクリックします。
[Pod] タブで、Pod が実行中状態であることを確認します。
ossfs 2.0 ボリューム
静的にプロビジョニングされた ossfs 2.0 ボリュームは、kubectl を使用してのみマウントできます。この操作は ACS コンソールではサポートされていません。
ステップ 1: PV の作成
次の 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-pvnamePV のラベル。PVC をバインドするために使用されます。
storageClassNameこの設定は PVC をバインドするためにのみ使用されます。実際の StorageClass を関連付ける必要はありません。
storageOSS ボリュームのストレージ容量。
説明静的にプロビジョニングされた OSS ボリュームの容量は宣言のみを目的としています。実際の容量は制限されません。利用可能な容量は、OSS コンソールに表示される量に従います。
accessModesアクセスモード。
persistentVolumeReclaimPolicy再利用ポリシー。
driverドライバーのタイプ。ここでは、
ossplugin.csi.alibabacloud.comに設定されており、Alibaba Cloud OSS CSI プラグインが使用されることを示します。volumeHandlePV の一意の識別子。
metadata.nameと一致する必要があります。nodePublishSecretRef指定されたシークレットから AccessKey ペアを取得して権限付与を行います。
fuseTypeマウントに使用するクライアントを指定します。ossfs 2.0 クライアントを使用するには、
ossfs2に設定する必要があります。bucketOSS バケットの名前。
bucketの値を実際の OSS バケット名に置き換えてください。urlOSS バケットのエンドポイント。
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 マウントオプション」をご参照ください。
次のコマンドを実行して、シークレットと PV を作成します。
kubectl create -f oss-pv.yamlPV のステータスを確認します。
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 の作成
次の 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アクセスモード。
storagePod に割り当てられるストレージ容量。OSS ボリュームの容量を超えることはできません。
alicloud-pvnameバインドする PV のラベル。PV の
metadata.labels.alicloud-pvnameと一致する必要があります。PVC を作成できます。
kubectl create -f oss-pvc.yamlPVC のステータスを確認します。
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 ボリュームのマウント
次の 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次のコマンドを実行して、デプロイメントを作成し、OSS ボリュームをマウントします。
kubectl create -f oss-test.yamlデプロイメント内の 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マウントパスを表示します。
次のコマンドは一例です。デフォルトでは、ディレクトリは空であり、出力は返されません。
kubectl exec oss-test-****-***a -- ls /data
OSS ボリュームがデータを共有および永続化できることの確認
作成したデプロイメントは 2 つの Pod をプロビジョニングします。同じ OSS バケットが両方の Pod にマウントされます。次の方法を使用して、OSS ボリュームがデータを共有および永続化できることを確認できます。
1 つの Pod にファイルを作成し、そのファイルが他の Pod からアクセスできるかどうかを確認します。ファイルにアクセスできる場合は、データ共有が有効になっています。
デプロイメントを再作成します。新しい Pod から OSS ボリュームにアクセスして、元のデータがまだ OSS バケットに存在するかどうかを確認します。データがまだ存在する場合は、データの永続性が有効になっています。
Pod 情報を表示します。
kubectl get pod | grep oss-test出力例:
oss-test-****-***a 1/1 Running 0 40s oss-test-****-***b 1/1 Running 0 40s共有ストレージを確認します。
いずれかの Pod にファイルを作成します。
この例では、
oss-test-****-***aという名前の Pod が使用されます。kubectl exec oss-test-****-***a -- touch /data/test.txt他の Pod からファイルを表示します。
この例では、
oss-test-****-***bという名前の Pod が使用されます。kubectl exec oss-test-****-***b -- ls /data次の出力は、新しいファイル
test.txtが共有されていることを示しています。test.txt
Pod の再作成後にデータが永続化されることを確認します。
デプロイメントを削除してから再作成します。
kubectl rollout restart deploy oss-testPod を表示し、新しい Pod が作成されるのを待ちます。
kubectl get pod | grep oss-test出力例:
oss-test-****-***c 1/1 Running 0 67s oss-test-****-***d 1/1 Running 0 49s新しい Pod から、ファイルシステム内のデータがまだ存在するかどうかを確認します。
この例では、
oss-test-c***という名前の Pod が使用されます。kubectl exec oss-test-****-***c -- ls /data次の出力は、OSS バケット内のデータがまだ存在し、新しい Pod のマウントディレクトリから取得できることを示しています。
test.txt