RRSA または AccessKey による ossfs 2.0 静的 OSS 永続ボリュームプロビジョニング - ACK

Object Storage Service (OSS) バケットを、静的にプロビジョニングされた永続ボリューム (PV) としてマウントすることで、Pod に POSIX ファイルシステムインターフェイスを備えた永続的かつ共有可能なストレージを提供します。ossfs 2.0 は順次読み取りおよび高帯域幅ワークロード向けに最適化されており、AI トレーニング、ビッグデータ分析、静的コンテンツ配信などのユースケースに適しています。

パフォーマンスベンチマークについては、「ossfs 2.0 クライアントのパフォーマンスベンチマーク」をご参照ください。

仕組み

Container Service for Kubernetes (ACK) クラスター内で OSS バケットを静的にプロビジョニングされたボリュームとしてマウントするには、以下の 4 つのステップが必要です。

認証方式を選択します。 本番環境では、RAM Roles for Service Accounts (RRSA) を使用してください。これは一時的かつ自動ローテーションされる認証情報を提供し、Pod レベルでの権限隔離を実現します。テスト目的のみに AccessKey を使用してください。AccessKey は長期的な静的キーに依存するため、セキュリティリスクが高くなります。
PV を作成します。 既存の OSS バケットをクラスターに登録する PV を定義し、バケット名、エンドポイント、サブディレクトリ、および認証情報などを指定します。
PVC を作成します。 上記で定義した PV にバインドされる永続ボリューム要求 (PVC) を作成します。
アプリケーションをデプロイします。 ワークロードのマニフェスト内で PVC を参照し、OSS バケットをコンテナ内にマウントします。

注意事項

サポート対象のワークロード： ossfs 2.0 は読み取り専用および順次追加書き込みワークロードをサポートします。ランダム書き込みまたは同時書き込みの場合、データ整合性は保証されません。その場合は代わりに「ossfs 1.0」をご利用ください。
データ安全性: マウントポイントで行われたファイルの変更（Pod 内部からでもホストノード上からでも）は、即座に OSS バケットに同期されます。誤って削除されるのを防ぐために、バケットでバージョン管理を有効化します。
ヘルスチェック： OSS ボリュームを使用する Pod には liveness プローブを設定し、マウントポイントの可用性を確認してください。プローブが失敗した場合、Kubernetes は自動的に Pod を再起動し、再マウントをトリガーします。
フラグメントアップロード: ossfs は、10 MB を超えるファイルに対して自動的にフラグメントアップロードを使用します。アップロードが中断された場合、未完了のパートがバケット内に残ります。これらのパートを手動で削除するまたはライフサイクルルールを設定することで、自動的にクリーンアップできます。

方法 1：RRSA を使用した認証（推奨）

RRSA は、OpenID Connect (OIDC) およびセキュリティトークンサービス (STS) を使用して、一時的かつ自動ローテーションされる認証情報を用いて Pod を認証し、PV レベルの権限隔離をサポートします。背景については、「RRSA を使用して、異なる Pod が異なるクラウドサービスにアクセスできるように承認する」をご参照ください。

前提条件

開始する前に、以下の条件を満たしていることを確認してください。

Kubernetes 1.26 以降を実行している ACK クラスター。必要に応じて「クラスターのアップグレード」を行ってください。
CSI プラグインのバージョンが 1.33.1 以降であること。アップグレード方法については、「csi-plugin および csi-provisioner の更新」をご参照ください。

CSI のバージョンが 1.30.4 より前で、RRSA の使用を計画している場合は、続行する前に [製品の変更] CSI における ossfs のバージョンスペックアップとマウントプロセスの最適化を参照し、RAM ロールの権限付与を設定してください。
OSS バケットが、クラスターと同じ Alibaba Cloud アカウント内にあること。

アカウント間で OSS バケットをマウントする場合は、RRSA 認証方式をご利用ください。「ossfs 2.0 ボリュームに関する FAQ」をご参照ください。

手順 1：RAM ロールの作成

すでに RRSA を使用してクラスター内に OSS ボリュームをマウント済みの場合は、この手順はスキップしてください。

RRSA 機能を有効化するを ACK コンソールで有効化します。

OIDC ID プロバイダー用の RAM ロールを作成する。以下の表には、サンプルのロール demo-role-for-rrsa の主要なパラメーターが一覧表示されています。

パラメーター	値
ID プロバイダーの種類	OIDC を選択します。
ID プロバイダー	クラスターに関連付けられたプロバイダー（例： `ack-rrsa-<cluster_id>`）を選択します。
oidc:iss	デフォルト値のままにしてください。
oidc:aud	デフォルト値のままにしてください。
oidc:sub	条件を追加します：キー = `oidc:sub`、演算子 = `StringEquals`、値 = `system:serviceaccount:ack-csi-fuse:csi-fuse-ossfs`。`ack-csi-fuse` は ossfs クライアントが実行される名前空間であり、変更できません。`csi-fuse-ossfs` は ServiceAccount 名であり、カスタマイズ可能です。
ロール名	`demo-role-for-rrsa`

ServiceAccount 名を変更するには、「ossfs 2.0 ボリュームに関するよくある質問」をご参照ください。

手順 2：RAM ロールへの権限付与

OSS アクセスを許可するカスタムポリシーを作成します。詳細については、「カスタムポリシーの作成」をご参照ください。 mybucket を実際のバケット名に置き換えてください。

読み取り専用ポリシー

{
    "Statement": [
        {
            "Action": [
                "oss:Get*",
                "oss:List*"
            ],
            "Effect": "Allow",
            "Resource": [
                "acs:oss:*:*:mybucket",
                "acs:oss:*:*:mybucket/*"
            ]
        }
    ],
    "Version": "1"
}

読み書き可能ポリシー

{
    "Statement": [
        {
            "Action": "oss:*",
            "Effect": "Allow",
            "Resource": [
                "acs:oss:*:*:mybucket",
                "acs:oss:*:*:mybucket/*"
            ]
        }
    ],
    "Version": "1"
}

(任意) バケット内のオブジェクトが Key Management Service (KMS) のカスタマーマスターキー (CMK) で暗号化されている場合、KMS のアクセス権限を付与します。詳細については、「暗号化」をご参照ください。
このポリシーを demo-role-for-rrsa ロールにアタッチします。 RAM ロールへの権限付与をご参照ください。

既に OSS アクセス権限を持つ既存の RAM ロールを使用するには、代わりにその信頼ポリシーを変更します。詳しくは、「既存の RAM ロールの使用」をご参照ください。

手順 3：PV の作成

以下の内容で ossfs2-pv.yaml を作成します。

以下の PV は、OSS バケット cnfs-oss-test を 20 GiB の読み取り専用ファイルシステムとしてマウントします。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-ossfs2                          # PV 名
spec:
  capacity:
    storage: 20Gi                          # PVC マッチングのみに使用；OSS 容量を制限しません
  accessModes:
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: ossplugin.csi.alibabacloud.com
    volumeHandle: pv-ossfs2                # metadata.name と完全に一致させる必要があります
    volumeAttributes:
      fuseType: ossfs2                     # 必須：ossfs 2.0 クライアントを指定
      bucket: cnfs-oss-test                # OSS バケット名
      path: /subpath                       # マウントするサブディレクトリ；空欄の場合はルートをマウント
      url: oss-cn-hangzhou-internal.aliyuncs.com  # 内部エンドポイント（同一リージョン）；クロスリージョンアクセスにはパブリックエンドポイントを使用
      otherOpts: "-o close_to_open=false"  # false（デフォルト）：小規模ファイルの読み取り性能向上のためメタデータをキャッシュ
                                           # true：各ファイルオープン時に最新のメタデータをフェッチ（遅延が大きくなるが、他のシステムが頻繁にオブジェクトを更新する場合に有用）
      authType: "rrsa"                     # 認証方式
      roleName: "demo-role-for-rrsa"       # 手順 1 で作成した RAM ロール

volumeAttributes の主なパラメーター：

パラメーター	必須	説明
`fuseType`	はい	ossfs 2.0 クライアントを使用するには、必ず `ossfs2` を指定する必要があります。
`bucket`	はい	マウントする OSS バケットの名前。
`path`	いいえ	バケット内のサブディレクトリ。空欄の場合はルートがデフォルトになります。
`url`	はい	OSS エンドポイント。クラスターとバケットが同一リージョンにある場合（または Virtual Private Cloud (VPC) 経由で接続されている場合）、内部エンドポイントを使用します。クロスリージョンアクセスにはパブリックエンドポイントを使用します。内部フォーマット：`http(s)://oss-{region}-internal.aliyuncs.com`。パブリックフォーマット：`http(s)://oss-{region}.aliyuncs.com`。`vpc100-oss-{region}.aliyuncs.com` の内部エンドポイントフォーマットは非推奨です。新しいフォーマットに切り替えてください。
`otherOpts`	いいえ	追加のマウントオプション（`-o <option> -o <option>` 形式）。利用可能なすべてのオプションについては、「ossfs 2.0 のマウントオプション」をご参照ください。
`authType`	はい	`rrsa` を指定します。
`roleName`	はい	RAM ロールの名前。異なる PV に異なる権限を割り当てる場合は、それぞれの PV ごとに個別の RAM ロールを作成し、ここで参照してください。

指定された Amazon リソースネーム (ARN) またはカスタム ServiceAccount を RRSA で使用する方法については、「指定された ARN または ServiceAccount を RRSA 認証方式で使用するにはどうすればよいですか？

マニフェストを適用します。
```
kubectl create -f ossfs2-pv.yaml
```

PV が利用可能であることを確認します。

kubectl get pv pv-ossfs2

期待される出力：

NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
pv-ossfs2   20Gi       ROX            Retain           Available                          <unset>                          15s

手順 4：PVC の作成

以下の内容で ossfs2-pvc-static.yaml を作成します。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-ossfs2       # PVC 名
  namespace: default
spec:
  accessModes:
    - ReadOnlyMany        # PV と一致させる必要があります
  resources:
    requests:
      storage: 20Gi       # PV と一致させる必要があります
  volumeName: pv-ossfs2   # この特定の PV にバインド

PVC を作成します。

kubectl create -f ossfs2-pvc-static.yaml

PVC がバインドされていることを確認します。

kubectl get pvc pvc-ossfs2

期待される出力：

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

手順 5：アプリケーションのデプロイ

ossfs2-test.yaml を作成し、PVC を /data にマウントする StatefulSet を定義します。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: ossfs2-test
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ossfs2-test
  template:
    metadata:
      labels:
        app: ossfs2-test
    spec:
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        ports:
        - containerPort: 80
        volumeMounts:
        - name: pvc-ossfs2
          mountPath: /data
      volumes:
        - name: pvc-ossfs2
          persistentVolumeClaim:
            claimName: pvc-ossfs2

アプリケーションをデプロイします。
```
kubectl create -f ossfs2-test.yaml
```

Pod が実行中になるまで待ちます。

kubectl get pod -l app=ossfs2-test

期待される出力：

NAME            READY   STATUS    RESTARTS   AGE
ossfs2-test-0   1/1     Running   0          12m

OSS バケットがマウントされていることを確認します。
```
kubectl exec -it ossfs2-test-0 -- ls /data
```
出力には、OSS マウントパス内のデータが表示されます。

方法 2：AccessKey を使用した認証

AccessKey ペアを Kubernetes シークレットに格納し、PV から参照します。この方法は設定が簡単ですが、長期的な静的キーを使用します。

重要

AccessKey が取り消された場合やその権限が変更された場合、ボリュームを使用するすべての Pod は即座にアクセスを失います。アクセスを復元するには、シークレットを新しい認証情報で更新し、影響を受ける Pod を再起動する必要があります。これにより一時的なサービス中断が発生します。本番環境では、このような運用上のオーバーヘッドを回避するために、「方法 1：RRSA を使用した認証」をご利用ください。

前提条件

開始する前に、以下の条件を満たしていることを確認してください。

CSI プラグインのバージョンが 1.33.1 以降である ACK クラスター。アップグレード方法については、「csi-plugin および csi-provisioner の更新」をご参照ください。
OSS バケットが、クラスターと同じ Alibaba Cloud アカウント内にあること。

アカウント間で OSS バケットをマウントする場合は、RRSA を使用してください。「ossfs 2.0 ボリュームに関する FAQ」をご参照ください。

手順 1：RAM ユーザーの作成および AccessKey の格納

RAM ユーザーを作成します。すでに存在する場合は、この手順をスキップしてください。「RAM ユーザーの作成」をご参照ください。

カスタムポリシーを作成して、OSS へのアクセスを付与します。詳細については、「カスタムポリシーの作成」をご参照ください。 mybucket を実際のバケット名に置き換えます。

読み取り専用ポリシー

{
    "Statement": [
        {
            "Action": [
                "oss:Get*",
                "oss:List*"
            ],
            "Effect": "Allow",
            "Resource": [
                "acs:oss:*:*:mybucket",
                "acs:oss:*:*:mybucket/*"
            ]
        }
    ],
    "Version": "1"
}

読み書き可能ポリシー

{
    "Statement": [
        {
            "Action": "oss:*",
            "Effect": "Allow",
            "Resource": [
                "acs:oss:*:*:mybucket",
                "acs:oss:*:*:mybucket/*"
            ]
        }
    ],
    "Version": "1"
}

（オプション）バケット内のオブジェクトが KMS の CMK で暗号化されている場合は、KMS アクセス権を付与します。詳細については、「暗号化」をご参照ください。
ポリシーを RAM ユーザーにアタッチします。詳細については、「RAM ユーザーへの権限付与」をご参照ください。
RAM ユーザー用の AccessKey ペアを作成します。「AccessKey ペアの作成」をご参照ください。
AccessKey ペアを Kubernetes シークレットとして格納します。xxxxxx を実際の値に置き換えてください。
```
kubectl create -n default secret generic oss-secret \
  --from-literal='akId=xxxxxx' \
  --from-literal='akSecret=xxxxxx'
```

手順 2：PV の作成

以下の内容で ossfs2-pv-ak.yaml を作成します。

以下の PV は、OSS バケット cnfs-oss-test を 20 GiB の読み取り専用ファイルシステムとしてマウントします。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-ossfs2                          # PV 名
spec:
  capacity:
    storage: 20Gi                          # PVC マッチングのみに使用
  accessModes:
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: ossplugin.csi.alibabacloud.com
    volumeHandle: pv-ossfs2                # metadata.name と完全に一致させる必要があります
    nodePublishSecretRef:
      name: oss-secret                     # 手順 1 で作成したシークレット
      namespace: default
    volumeAttributes:
      fuseType: ossfs2                     # 必須：ossfs 2.0 クライアントを指定
      bucket: cnfs-oss-test                # OSS バケット名
      path: /subpath                       # マウントするサブディレクトリ；空欄の場合はルートをマウント
      url: oss-cn-hangzhou-internal.aliyuncs.com  # 内部エンドポイント（同一リージョン）；クロスリージョンアクセスにはパブリックエンドポイントを使用
      otherOpts: "-o close_to_open=false"  # false（デフォルト）：小規模ファイルの読み取り性能向上のためメタデータをキャッシュ
                                           # true：各ファイルオープン時に最新のメタデータをフェッチ（遅延が大きくなる）

nodePublishSecretRef のパラメーター：

パラメーター	必須	説明
`name`	はい	AccessKey ペアを格納するシークレットの名前。
`namespace`	はい	シークレットが配置されている名前空間。

volumeAttributes のパラメーター：「方法 1、手順 3」と同一ですが、authType および roleName は使用しません。

マニフェストを適用します。
```
kubectl create -f ossfs2-pv-ak.yaml
```

PV が利用可能であることを確認します。

kubectl get pv pv-ossfs2

期待される出力：

NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
pv-ossfs2   20Gi       ROX            Retain           Available                          <unset>                          15s

手順 3：PVC の作成

ossfs2-pvc-static.yaml を作成します。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-ossfs2
  namespace: default
spec:
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 20Gi
  volumeName: pv-ossfs2

PVC を作成します。

kubectl create -f ossfs2-pvc-static.yaml

PVC がバインドされていることを確認します。

kubectl get pvc pvc-ossfs2

期待される出力：

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

手順 4：アプリケーションのデプロイ

「方法 1、手順 5」と同じ手順に従ってください。

本番環境に適用

カテゴリ	推奨事項
セキュリティ	すべての本番ワークロードには RRSA を使用してください。これは OIDC および STS を介して一時的かつ自動ローテーションされる認証情報を提供し、細かい粒度での Pod レベル権限隔離を実現します。
最小権限の原則	アプリケーションに必要な最低限の権限（読み取り専用または読み書き可能）のみを、特定のバケットに限定して付与してください。
エンドポイント	クラスターとバケットが同一リージョンにある場合は、パブリックデータ転送コストを回避し、レイテンシーを低減するために内部エンドポイントを使用してください。
マウントオプション	`-o close_to_open=false`（デフォルト）を使用してメタデータをキャッシュし、小規模ファイルの読み取り時のレイテンシーを低減してください。Pod が他の書き込み元からの更新を即座に認識する必要がある場合にのみ、`-o close_to_open=true` に切り替えてください。
ワークロード適合性	ossfs 2.0 は AI トレーニング、推論、ビッグデータ処理、自動運転などのワークロードに適しています。データベースや共同編集ツールなど、ランダム書き込みを必要とするワークロードには適していません。
不完全なアップロード	不要なストレージコストを回避するため、バケットにライフサイクルルールを設定して、不完全なマルチパートアップロードのパートを自動的に削除してください。
ヘルスチェック	マウントポイントの可用性を確認するため、各 Pod に liveness プローブを設定してください。マウントが失敗した場合、Kubernetes は Pod を再起動し、再マウントをトリガーします。
モニタリング	コンテナストレージのモニタリングを使用してボリュームのパフォーマンスを追跡し、問題を早期に検知できるようアラートを設定してください。

Container Service for Kubernetes:ACK クラスターで ossfs 2.0 を使用して静的 OSS 永続ボリュームをマウントする

仕組み

注意事項

方法 1：RRSA を使用した認証（推奨）

前提条件

手順 1：RAM ロールの作成

手順 2：RAM ロールへの権限付与

手順 3：PV の作成

手順 4：PVC の作成

手順 5：アプリケーションのデプロイ

方法 2：AccessKey を使用した認証

前提条件

手順 1：RAM ユーザーの作成および AccessKey の格納

手順 2：PV の作成

手順 3：PVC の作成

手順 4：アプリケーションのデプロイ

本番環境に適用

よくある質問

参考資料