Container Service for Kubernetes:ossfs 2.0 永続ボリュームに関するよくある質問

OSS 永続ボリュームのマウントに失敗しました

現象

ossfs 2.0 を使用すると、OSS 永続ボリューム (PV) のマウントに失敗します。Pod の起動に失敗し、FailedMount イベントが報告されます。

原因

• 原因 1: AccessKey の権限が不十分です。

• 原因 2: イベントにメッセージ failed to get secret secrets "xxx" is forbidden: User "serverless-xxx" cannot get resource "secrets" in API group "" in the namespace "xxx" が含まれています。仮想ノード (ACS Pod) で実行されるアプリケーションの場合、PersistentVolumeClaim (PVC) が nodePublishSecretRef フィールドを使用して権限付与情報を指定する場合、Secret は PVC と同じ名前空間にある必要があります。

• 原因 3: イベントにメッセージ FailedMount /run/fuse.ossfs/xxxxxx/mounter.sock: connect: no such file or directory が含まれています。これは、ossfs 2.0 が実行される Pod が起動していないか、予期せず削除されたためです。

• 原因 4: OSS バケットがミラーリングベースのオリジンフェッチで設定されており、マウントディレクトリがソースサイトから同期されていません。

• 原因 5: OSS バケットが静的 Web サイトホスティング用に設定されています。ossfs 2.0 が OSS のマウントディレクトリをチェックすると、リクエストは index.html などのファイルに転送されます。

解決策

• 原因 1 の解決策

  • Resource Access Management (RAM) ユーザーのアクセスポリシーが要件を満たしていることを確認します。詳細については、「静的にプロビジョニングされた ossfs 2.0 ボリュームを使用する」をご参照ください。

  • マウントに使用される AccessKey が無効になっていないか、またはローテーションされていないことを確認します。

    重要

    PV の nodePublishSecretRef フィールドで指定された Secret 内の AccessKey への変更はすぐには有効になりません。ossfs 2.0 クライアント Pod を再起動する必要があります。ossfs 2.0 クライアントの再起動方法については、「ossfs 2.0 プロセスを再起動するにはどうすればよいですか？」をご参照ください。

• 原因 2 の解決策:

  必要な Secret を PVC と同じ名前空間に作成します。新しい PV を作成するときは、nodePublishSecretRef フィールドをこの Secret に設定します。詳細については、「方法 2: RAM ユーザーの AccessKey を使用してボリュームをマウントし、権限を付与する」をご参照ください。

• 原因 3 の解決策

  1. ossfs 2.0 が実行される Pod が存在することを確認します。

     コマンドで、<PV_NAME> はマウントされた OSS PV の名前で、<NODE_NAME> はボリュームを必要とするアプリケーション Pod が配置されているノードの名前です。

     kubectl -n ack-csi-fuse get pod -l csi.alibabacloud.com/volume-id=<PV_NAME> -owide | grep <NODE_NAME>

     • Pod が存在するが異常な状態にある場合は、Pod のトラブルシューティングを行って問題の原因を特定します。Pod が Running 状態であることを確認したら、アプリケーション Pod を再起動して再マウントをトリガーします。

     • Pod が存在しない場合は、次の手順に進みます。

  2. (オプション) 監査ログをクエリして、Pod が予期せず削除されたかどうかを判断します。

     予期せぬ削除の一般的な理由には、アプリケーションスクリプトによるクリーンアップ、ノードのドレイン、ノードの自動修復などがあります。問題が再発しないように、必要に応じて調整を行ってください。

  3. VolumeAttachment リソースが残っていないか確認します。

     kubectl get volumeattachment | grep <PV_NAME> | grep <NODE_NAME>

  4. アプリケーション Pod を再起動して再マウントをトリガーし、ossfs 2.0 Pod が期待どおりに作成されることを確認します。

• 原因 4 の解決策

  ボリュームをマウントする前に、ソースサイトからデータを同期する必要があります。詳細については、「オリジンフェッチの概要」をご参照ください。

• 原因 5 の解決策

  ボリュームをマウントする前に、静的 Web サイトホスティングの設定を無効にするか調整する必要があります。詳細については、「静的 Web サイトホスティングの概要」をご参照ください。

OSS 永続ボリュームを使用して OSS から特定のファイルのみをマウントするにはどうすればよいですか？

ossfs 2.0 は、OSS から Pod へのパスをファイルシステムとしてマウントできます。ただし、ossfs 2.0 は単一ファイルのマウントを直接サポートしていません。Pod が OSS 内の特定のファイルにのみアクセスするようにしたい場合は、サブパスを指定できます。

OSS バケットの /subpath ディレクトリから a.txt と b.txt ファイルを 2 つの異なる Pod にマウントするとします。Pod 内のマウントパスは /path/to/file/ です。次の YAML テンプレートを使用して、対応する PV を作成できます。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-oss
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: ossplugin.csi.alibabacloud.com
    volumeHandle: pv-oss 
    volumeAttributes:
      bucket: bucket
      path: subpath # a.txt と b.txt の親パス
      url: "oss-cn-hangzhou.aliyuncs.com"
      fuseType: ossfs2

対応する PVC を作成した後、次のように Pod で PVC の VolumeMounts を設定します。

  volumeMounts:
    - mountPath: /path/to/file # bucket:/subpath に対応する Pod 内のマウントパス
      name: oss-pvc # Volumes の名前と同じである必要があります
      subPath: a.txt # または b.txt。これは bucket:/subpath 内のファイルの相対パスです

マウントが完了すると、Pod 内で a.txt にアクセスするための完全なパスは /path/to/file/a.txt になります。このパスは bucket:/subpath/a.txt に対応します。

詳細については、「静的にプロビジョニングされた ossfs 2.0 ボリュームを使用する」をご参照ください。

アカウント間で OSS バケットをマウントするにはどうすればよいですか？

RRSA ベースの権限付与を使用して、アカウント間で OSS バケットをマウントします。

クラスターと CSI コンポーネントのバージョンが RRSA ベースの権限付与の要件を満たしていることを確認してください。

次の手順では、Alibaba Cloud アカウント B のバケットを Alibaba Cloud アカウント A のクラスターにマウントする方法を示します。アカウント A にはクラスターが含まれ、アカウント B には OSS バケットが含まれています。RRSA ベースの権限付与を使用してマウントされる PV を作成する前に、必要な RAM 権限付与の準備を完了してください。

1. アカウント B で次の操作を実行します。

   1. アカウント B で、アカウント A が引き受けることができる roleB という名前の RAM ロールを作成します。詳細については、「信頼できる Alibaba Cloud アカウントの RAM ロールを作成する」をご参照ください。

   2. roleB に、マウントしたい OSS バケットにアクセスするための権限を付与します。

   3. [RAM コンソール] で、roleB の詳細ページに移動し、その ARN (例: acs:ram::130xxxxxxxx:role/roleB) をコピーします。

2. アカウント A で次の操作を実行します。

   1. アプリケーションが RRSA ベースの権限付与に使用するための roleA という名前の RAM ロールを作成します。信頼できるエンティティを OIDC IdP に設定します。

   2. roleA に roleB を引き受ける権限を付与します。詳細については、「RRSA ベースの権限付与を使用してボリュームをマウントする」(静的プロビジョニングボリューム) または「RRSA ベースの権限付与を使用してボリュームをマウントする」(動的プロビジョニングボリューム) をご参照ください。

      roleA に OSS 関連のアクセスポリシーを付与する必要はありません。ただし、sts:AssumeRole API 操作を含むアクセスポリシー (例: AliyunSTSAssumeRoleAccess システムポリシー) を付与する必要があります。

3. クラスターで PV を設定します。

   永続ボリューム (PV) を作成するときは、assumeRoleArn パラメーターを roleB の ARN に設定します。

   • 静的プロビジョニングボリューム (PV): 次の内容を volumeAttributes に追加します。

     assumeRoleArn: <roleB の ARN>

   • 動的プロビジョニングボリューム (StorageClass): 次の内容を parameters に追加します。

     assumeRoleArn: <roleB の ARN>

RRSA 認証で指定された ARN または ServiceAccount を使用するにはどうすればよいですか？

OSS PV の権限付与に RRSA を使用する場合、サードパーティの OIDC IdP またはデフォルト以外の ServiceAccount を使用する必要がある場合がありますが、これらはデフォルト設定ではサポートされていないシナリオです。

この場合、roleName 設定項目を使用して PV で RAM ロール名を指定できます。CSI プラグインは、デフォルトのロール ARN と OIDC プロバイダー ARN を取得できます。カスタム RRSA ベースの権限付与を実装するには、次のように PV 設定を変更する必要があります。

roleArn と oidcProviderArn パラメーターは一緒に設定する必要があります。これらのパラメーターを設定する場合、roleName を設定する必要はありません。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-oss
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: ossplugin.csi.alibabacloud.com
    volumeHandle: pv-oss # PV 名と同じである必要があります。
    volumeAttributes:
      bucket: "oss"
      url: "oss-cn-hangzhou.aliyuncs.com"
      authType: "rrsa"
      fuseType: "ossfs2"
      oidcProviderArn: "<oidc-provider-arn>"
      roleArn: "<role-arn>"
      #roleName: "<role-name>" # roleArn と oidcProviderArn を設定すると、roleName は無効になります。
      serviceAccountName: "csi-fuse-<service-account-name>" 

実際のストレージ容量がボリュームの設定を超えた場合、ボリュームをスケールアウトする必要がありますか？

OSS はバケットまたはサブディレクトリの容量を制限せず、容量クォータ機能も提供しません。したがって、PV の .spec.capacity フィールドと PVC の .spec.resources.requests.storage フィールドは無視され、有効になりません。バインドされた PV と PVC の容量設定値が一致していることだけを確認する必要があります。

実際のストレージ容量が設定を超えても、通常の使用には影響せず、ボリュームをスケールアウトする必要はありません。

ossfs 2.0 プロセスを再起動するにはどうすればよいですか？

現象

権限付与情報または ossfs 2.0 バージョンを変更した後、実行中の ossfs 2.0 プロセスは自動的に更新されません。

原因

• ossfs 2.0 の実行後、権限付与情報などの設定は、プロセスの実行中に変更することはできません。変更を適用するには、ossfs 2.0 プロセス (ack-csi-fuse 名前空間の csi-fuse-ossfs2-* という名前の Pod) と対応するアプリケーション Pod を再起動する必要があります。この再起動はビジネスの中断を引き起こします。したがって、デフォルトでは、CSI は実行中の ossfs 2.0 プロセスを更新しません。

• 通常の操作中、ossfs 2.0 PV の作成と削除は CSI によって完全に管理されます。ossfs 2.0 を実行する Pod を手動で停止した場合、CSI はマウントを自動的に回復または再作成しません。

解決策

1. 現在の FUSE Pod を使用しているアプリケーション Pod を特定します。

   1. 更新したい csi-fuse-ossfs2-* Pod を特定します。

      コマンドで、<pv-name> は PV 名、<node-name> はノード名です。

      kubectl -n ack-csi-fuse get pod -lcsi.alibabacloud.com/volume-id=<pv-name> -owide | grep <node-name>

   2. OSS PV をマウントしているすべての Pod を特定します。

      コマンドで、<ns> は名前空間名、<pvc-name> は PVC 名です。

      kubectl -n <ns> describe pvc <pvc-name>

      期待される出力 (Used By を含む):

      Used By:       oss-static-94849f647-4****
                     oss-static-94849f647-6****
                     oss-static-94849f647-h****
                     oss-static-94849f647-v****
                     oss-static-94849f647-x****

   3. csi-fuse-ossfs2-xxxx によって提供されるマウントを使用する Pod を見つけます。これらは csi-fuse-ossfs2-xxxx と同じノードで実行される Pod です。

      kubectl -n <ns> get pod -owide | grep cn-beijing.192.168.XX.XX

      期待される出力:

      NAME                         READY   STATUS    RESTARTS   AGE     IP               NODE                         NOMINATED NODE   READINESS GATES
      oss-static-94849f647-4****   1/1     Running   0          10d     192.168.xx.xx    cn-beijing.192.168.xx.xx     <none>           <none>
      oss-static-94849f647-6****   1/1     Running   0          7m36s   192.168.xx.xx    cn-beijing.192.168.xx.xx     <none>           <none>

2. アプリケーションと ossfs 2.0 プロセスを再起動します。

   コマンド (例: kubectl scale) を使用して、アプリケーション Pod (oss-static-94849f647-4**** と前述の例の oss-static-94849f647-6****) を同時に削除します。マウントされているアプリケーション Pod がない場合、csi-fuse-ossfs2-xxxx Pod は自動的に回収されます。レプリカ数が復元されると、ボリュームは新しい PV 設定で再マウントされ、CSI は新しい csi-fuse-ossfs2-yyyy Pod を作成します。

   これらの Pod を同時に削除できない場合 (たとえば、Deployment、StatefulSet、または DaemonSet によって管理されている Pod を削除するとすぐに再起動がトリガーされる場合)、または Pod が OSS の読み取りおよび書き込みの失敗を許容できる場合は、次のコマンドを実行して PV の volumeattachment リソースを見つけます。

   kubectl get volumeattachment | grep <pv-name> | grep cn-beijing.192.168.XX.XX

   期待される出力:

   csi-bd463c719189f858c2394608da7feb5af8f181704b77a46bbc219b**********   ossplugin.csi.alibabacloud.com    <pv-name>                   cn-beijing.192.168.XX.XX    true       12m

   VolumeAttachment を直接削除すると、アプリケーション Pod からの OSS への読み取りおよび書き込み操作は disconnected error を返します。

   その後、アプリケーション Pod を 1 つずつ再起動できます。Pod は、CSI によって作成された新しい csi-fuse-ossfs2-yyyy Pod を介して OSS での読み取りおよび書き込み操作を再開します。