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

OSS ボリュームのマウント時間が長くなる

現象

OSS ボリュームのマウント時間が増加します。

原因

次の条件が満たされると、kubelet はボリュームのマウントプロセス中に chmod または chown 操作を実行します。これにより、マウント時間が増加します。

• PV および PVC の AccessModes が ReadWriteOnce に設定されている。

• アプリケーションテンプレートで securityContext.fsgroup が構成されている。

解決策

• ossfs マウントツールを使用すると、パラメーターを使用してマウントポイント内のファイルの UID、GID、およびモードを変更できます。

  パラメーター	説明
  uid	マウントディレクトリ内のサブディレクトリとファイルを所有するユーザーの UID を指定します。
  gid	マウントディレクトリ内のサブディレクトリとファイルを所有するユーザーの GID を指定します。
  umask	マウントディレクトリ内のサブディレクトリとファイルの権限マスクを設定します。このパラメーターは mp_umask と同様の方法で使用されますが、allow_other 設定項目には依存しません。

  構成が完了したら、fsgroup から securityContext パラメーターを削除します。

• バージョン 1.20 以降の Kubernetes クラスターでは、上記のソリューションに加えて、fsGroupChangePolicy を OnRootMismatch に構成することもできます。これにより、chmod または chown 操作は最初の起動時にのみ実行され、その後のマウント時間は通常に戻ります。fsGroupChangePolicy の詳細については、「Pod またはコンテナのセキュリティコンテキストの設定」をご参照ください。

OSS ボリュームのマウント権限の問題

次のシナリオで操作を実行すると、Permission Denied または Operation not permitted エラーが表示されることがあります。

OSS ボリュームのマウント失敗

現象

OSS ボリュームのマウントに失敗し、Pod が起動できず、イベントに FailedMount が表示されます。

原因

• 原因 1: 以前のバージョンの ossfs は、バケット内に存在しないディレクトリへのマウントをサポートしていません。指定されたマウントディレクトリが存在しないため、マウントに失敗します。

  重要

  OSS コンソールで表示されるサブディレクトリは、実際にはサーバー上に存在しない場合があります。ossutil または OSS API によって返される結果が優先されます。たとえば、/a/b/c/ ディレクトリを直接作成した場合、/a/b/c/ は個別のディレクトリ オブジェクトですが、/a/ および /a/b/ ディレクトリ オブジェクトは実際には存在しません。同様に、/a/* にファイルをアップロードした場合、/a/b と /a/c は個別のファイル オブジェクトですが、/a/ ディレクトリ オブジェクトは存在しません。

• 原因 2: RRSA で使用される AccessKey またはロール情報が正しくないか、権限が不十分なため、マウントに失敗します。

• 原因 3: アプリケーションのランタイム環境からのアクセスが OSS バケットポリシーによってブロックされています。

• 原因 4: イベントに failed to get secret secrets "xxx" is forbidden: User "serverless-xxx" cannot get resource "secrets" in API group "" in the namespace "xxx" が含まれています。仮想ノード (ACS Pod) 上に作成されたアプリケーションの場合、PVC が nodePublishSecretRef フィールドを介して認証情報を指定する必要がある場合、Secret は PVC と同じ名前空間にある必要があります。

• 原因 5: CSI バージョンが 1.30.4 以降の場合、ossfs が配置されている Pod は ack-csi-fuse 名前空間で実行されます。マウント中、CSI はまず ossfs が配置されている Pod を起動し、次に RPC リクエストを送信して Pod 内の ossfs プロセスを起動します。イベントに FailedMount /run/fuse.ossfs/xxxxxx/mounter.sock: connect: no such file or directory が含まれている場合、原因は ossfs Pod の起動に失敗したか、予期せず削除されたことです。

• 原因 6: イベントに Failed to find executable /usr/local/bin/ossfs: No such file or directory が含まれています。原因は、ノードへの ossfs のインストールに失敗したことです。

• 原因 7: イベントに error while loading shared libraries: xxxxx: cannot open shared object file: No such file or directory が含まれています。現在の CSI バージョンの ossfs はノード上で直接実行され、オペレーティングシステムに ossfs の実行に必要な一部の動的ライブラリが不足しているため、マウントに失敗します。次の状況がこのエラーを引き起こす可能性があります:

  • ノードに別のバージョンの ossfs ツールを手動でインストールし、そのツールが現在のノードのオペレーティングシステムと互換性がない。

  • ノードのオペレーティングシステムのアップグレード (例: Alibaba Cloud Linux 2 から Alibaba Cloud Linux 3 へ) により、OpenSSL のデフォルトバージョンが変更された。

  • ossfs がノードで実行される場合、CentOS、Alibaba Cloud Linux、ContainerOS、Anolis OS 以外のオペレーティングシステムはサポートされていません。

  • オペレーティングシステムの要件を満たすノードで、FUSE、cURL、xml2 などの ossfs の実行に必要なデフォルトの動的ライブラリを削除したか、OpenSSL のデフォルトバージョンを変更した。

• 原因 8: OSS バケットのサブディレクトリをマウントするときに、RRSA で使用される AccessKey またはロールにサブディレクトリに対する権限のみが付与されています。これにより、マウントに失敗します。ossfs Pod のログには 403 AccessDenied と 404 NoSuchKey の両方のエラーが含まれています。

  ossfs の起動時、OSS バケットに対する権限検証と接続性チェックが自動的に実行されます。マウントポイントが OSS サブディレクトリの場合、1.91.5 より前のバージョンの ossfs はまずバケットのルートディレクトリへのアクセスを試みます。アクセスに失敗した場合、サブディレクトリへのアクセスを再試行します。バケットに対する完全な読み取り専用権限があれば、新しいバージョンの ossfs では OSS バケットに存在しないサブディレクトリへのマウントが可能です。

  したがって、RRSA で使用される AccessKey またはロールにサブディレクトリに対する権限のみが付与されている場合、初期検証中に 403 AccessDenied エラーが報告されます。サブディレクトリが存在しない場合、404 NoSuchKey エラーが報告され、プロセスが異常終了するため、マウントに失敗します。

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

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

解決策

• 原因 1 の解決策:

  サブディレクトリが OSS サーバーに存在するかどうかを確認します。

  PV のマウントパスが sub/path/ であると仮定します。stat (バケットとオブジェクト情報の表示) コマンドを使用して objectname が sub/path/ であるオブジェクトをクエリするか、HeadObject OpenAPI 操作を使用して key が sub/path/ であるオブジェクトをクエリできます。404 応答は、サブディレクトリがサーバーに存在しないことを確認します。

  • ossutil、SDK、OSS コンソールなどのツールを使用して、不足しているバケットまたはサブディレクトリを手動で作成し、再マウントできます。

  • ossfs 1.91 以降のバージョンでは、マウントディレクトリが存在する必要はありません。ossfs のバージョンをアップグレードすることでもこの問題を解決できます。詳細については、「ossfs 1.0 の新機能とパフォーマンスストレステスト」をご参照ください。アップグレード後もマウントに失敗する場合は、このトピックの「原因 6」をご参照ください。

• 原因 2 の解決策:

  • マウントに使用される RAM ユーザーまたは RAM ロールのポリシーに、「ステップ 2: demo-role-for-rrsa ロールに権限を付与する」に記載されている権限が含まれていることを確認してください。

  • ルートマウントパスとサブパスのファイルシステム権限を確認します。詳細については、「OSS ボリュームのマウント権限の問題」のシナリオ 2 と 7 をご参照ください。

  • RAM ユーザーの AccessKey 認証を使用してマウントされたボリュームの場合、マウントに使用された AccessKey が無効化またはローテーションされていないか確認します。詳細については、「OSS ボリュームのマウント権限の問題」のシナリオ 5 をご参照ください。

  • RRSA 認証を使用してマウントされたボリュームの場合、RAM ロールに正しい信頼ポリシーが構成されているか確認します。信頼ポリシーの構成方法については、「ステップ 1: RAM ロールを作成する」をご参照ください。デフォルトでは、信頼できる ServiceAccount は ack-csi-fuse 名前空間の csi-fuse-ossfs であり、アプリケーションが使用する ServiceAccount ではありません。

    重要

    RRSA 認証を使用したボリュームのマウントは、Kubernetes 1.26 以降を実行し、CSI コンポーネントのバージョンが 1.30.4 以降のクラスターでのみサポートされます。1.30.4 より前のバージョンで RRSA 機能を使用していた場合は、「[製品変更] CSI ossfs バージョンのアップグレードとマウントプロセスの最適化」を参照して、必要な RAM ロールの権限付与構成を追加してください。

• 原因 3 の解決策:

  OSS バケットポリシーを確認して修正します。詳細については、「OSS ボリュームのマウント権限の問題」のシナリオ 1 をご参照ください。

• 原因 4 の解決策:

  PVC と同じ名前空間に必要な Secret を作成します。新しい PV を作成するときに、nodePublishSecretRef をこの Secret にポイントします。詳細については、「RAM ユーザーの AccessKey 認証を使用してボリュームをマウントする」をご参照ください。

• 原因 5 の解決策:

  1. 次のコマンドを実行して、ossfs 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 が存在し、そのステータスが `Running` でない場合は、異常の原因をトラブルシューティングします。Pod が正常に実行されていることを確認してから、アプリケーション Pod を再起動して再マウントをトリガーします。Pod が存在しない場合は、次のステップに進んでトラブルシューティングを続行します。

  2. (オプション) 監査ログまたは他の方法で、Pod が予期せず削除されたかどうかを確認します。予期せぬ削除の一般的な理由には、アプリケーションスクリプトのクリーンアップ、ノードのドレイン、ノードの自己修復などがあります。問題の再発を防ぐために、関連する調整を行うことをお勧めします。

  3. CSI プロビジョナーと CSI プラグインの両方が 1.30.4 以降にアップグレードされていることを確認した後:

     1. 次の手順を実行して、残りの VolumeAttachment リソースを確認します。

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

        存在する場合は、VolumeAttachment リソースを削除します。

     2. アプリケーション Pod を再起動して再マウントをトリガーし、ossfs Pod の作成プロセスが正常であることを確認します。

• 原因 6 の解決策:

  1. csi-plugin をバージョン v1.26.2 以降にアップグレードすることをお勧めします。このバージョンでは、新しくスケールアウトされたノードの初期化中に ossfs のインストールが失敗する問題が修正されています。

  2. 次のコマンドを実行して、対応するノードで csi-plugin を再起動し、Pod が正常に起動できるか確認します。

     次のコードでは、csi-plugin-**** はノード上の csi-plugin の Pod 名です。

     kubectl -n kube-system delete pod csi-plugin-****

  3. コンポーネントをアップグレードまたは再起動しても問題が解決しない場合は、ノードにログインして次のコマンドを実行します。

     ls /etc/csi-tool

     部分的な期待される出力:

     ... ossfs_<ossfsVer>_<ossfsArch>_x86_64.rpm ...

     • 出力に ossfs RPM Package Manager (RPM) パッケージが含まれている場合は、次のコマンドを実行して Pod が正常に起動するか確認します。

       rpm -i /etc/csi-tool/ossfs_<ossfsVer>_<ossfsArch>_x86_64.rpm

     • 出力に ossfs RPM パッケージが含まれていない場合は、「ossfs 1.0 のインストール」を参照して最新バージョンをダウンロードしてください。

• 原因 7 の解決策:

  • ossfs ツールを手動でインストールした場合は、ツールがノードのオペレーティングシステムと互換性があるか確認してください。

  • ノードのオペレーティングシステムをアップグレードした場合は、次のコマンドを実行して csi-plugin を再起動し、ossfs のバージョンを更新してから、再度マウントを試みることができます。

    kubectl -n kube-system delete pod -l app=csi-plugin

  • CSI をバージョン 1.28 以降にアップグレードすることをお勧めします。OSS ボリュームをマウントすると、ossfs はクラスター内のコンテナとして実行され、ノードのオペレーティングシステムに依存しません。

  • クラスターを新しい CSI バージョンにアップグレードできない場合は、互換性のある OS に切り替えるか、不足している動的ライブラリを手動でインストールできます。Ubuntu ノードを例にとります:

    • which コマンドを使用して、ossfs の現在のインストール場所をクエリします。デフォルトのインストールパスは /usr/local/bin/ossfs です。

      which ossfs

    • ldd コマンドを使用して、ossfs に不足している動的ライブラリファイルをクエリします。

      ldd /usr/local/bin/ossfs

    • apt-file コマンドを使用して、不足している動的ライブラリファイル (libcrypto.so.10 など) が属するパッケージをクエリします。

      apt-get install apt-file
      apt-file update
      apt-file search libcrypto.so.10

    • apt-get コマンドを使用して、対応するパッケージ (libssl.1.0.0 など) をインストールします。

      apt-get install libssl1.0.0

• 原因 8 の解決策:

  • 推奨される解決策: CSI バージョンを v1.32.1-35c87ee-aliyun 以降にアップグレードします。

  • 代替解決策 1: このトピックの「原因 1」を参照して、サブディレクトリが存在するかどうかを確認します。

  • 代替解決策 2: サブディレクトリを長期間マウントする場合は、権限範囲をバケット全体に拡大することをお勧めします。

• 原因 9 の解決策:

  ボリュームをマウントする前に、オリジンからデータを同期する必要があります。詳細については、「back-to-origin 設定の概要」をご参照ください。

• 原因 10 の解決策:

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

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

OSS ボリュームは ossfs ツールを使用して OSS 内のパスを Pod にファイルシステムとしてマウントします。ossfs 自体はファイルのマウントをサポートしていません。OSS から特定のファイルのみを Pod で表示したい場合は、subPath メソッドを使用できます:

OSS の bucket:/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"

対応する PVC を作成した後、Pod の VolumeMounts を次のように構成します:

  volumeMounts:
    - mountPath: /path/to/file/a.txt # 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 にアクセスします。

OSS ボリュームの使用に関する基本的な手順については、「静的にプロビジョニングされた ossfs 1.0 ボリュームを使用する」をご参照ください。

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

OSS ボリュームの認証に RRSA を使用する場合、サードパーティの OIDC IdP やデフォルト以外の ServiceAccount の使用など、デフォルトの構成では満たせない要件が発生することがあります。

デフォルトでは、PV の roleName 構成項目を使用して RAM ロール名を指定するだけで済みます。CSI ストレージプラグインは、デフォルトのロール ARN と OIDC プロバイダー ARN を取得します。カスタム RRSA 認証を実装するには、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 # PV 名と同じでなければなりません。
    volumeAttributes:
      bucket: "oss"
      url: "oss-cn-hangzhou.aliyuncs.com"
      otherOpts: "-o umask=022 -o max_stat_cache_size=0 -o allow_other"
      authType: "rrsa"
      oidcProviderArn: "<oidc-provider-arn>"
      roleArn: "<role-arn>"
      #roleName: "<role-name>" # roleArn と oidcProviderArn を構成すると、roleName は無効になります。
      serviceAccountName: "csi-fuse-<service-account-name>" 

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

RRSA 認証を使用して、アカウント間で OSS バケットをマウントできます。

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

次の手順では、アカウント A にアカウント B が所有するバケットをマウントする方法について説明します。アカウント A はクラスターが配置されている場所です。アカウント B は OSS バケットが配置されている場所です。RRSA 認証を使用するボリュームを作成する前に、RAM 権限付与の準備を完了する必要があります。

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

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

   2. マウントする必要がある OSS バケットに対する権限を roleB に付与します。

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

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

   1. アプリケーションが RRSA 認証に使用する roleA という名前の RAM ロールを作成します。信頼できるエンティティタイプは OIDC IdP です。

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

      roleA に OSS 関連の権限ポリシーを付与する必要はありませんが、sts:AssumeRole API 操作を含む権限ポリシー (システムポリシー AliyunSTSAssumeRoleAccess など) を付与する必要があります。

3. クラスターでボリュームを構成します:

   ボリュームを作成するときに、assumeRoleArn パラメーターを roleB の ARN に設定します:

   • 静的にプロビジョニングされたボリューム (PV): volumeAttributes に、次を追加します:

     assumeRoleArn: <ARN of roleB>

   • 動的プロビジョニングされたボリューム (StorageClass): parameters に、次を追加します:

     assumeRoleArn: <ARN of roleB>

ossfs がコンテナ化された後、排他的マウントモードを有効にするにはどうすればよいですか?

現象

同じノード上の複数の Pod が同じ OSS ボリュームをマウントすると、マウントポイントを共有します。

原因

ossfs がコンテナ化される前は、デフォルトで排他的マウントモードを使用していました。これは、OSS ボリュームをマウントする各 Pod に対して、そのボリュームに対応する ossfs プロセスが対応するノードで開始されることを意味します。異なる ossfs プロセスに対応するマウントポイントは完全に独立しているため、同じ OSS ボリュームをマウントする異なる Pod は互いの読み取り/書き込み操作に影響を与えません。

ossfs がコンテナ化された後、ossfs プロセスは Pod 内のコンテナとして実行されます。具体的には、kube-system または ack-csi-fuse 名前空間の csi-fuse-ossfs-* という名前の Pod です。マルチマウントシナリオでは、排他的マウントモードはクラスター内に多数の Pod を開始し、ENI の不足などの問題を引き起こします。そのため、コンテナ化後は、デフォルトで共有マウントモードが使用されます。これは、同じノード上の複数の Pod が同じ OSS ボリュームをマウントすると、マウントポイントを共有し、すべてが同じ csi-fuse-ossfs-* Pod に対応し、マウントは実際には同じ ossfs プロセスによって処理されることを意味します。

解決策

コンテナ化前に使用されていた排他的マウントモードを復元したい場合は、OSS ボリュームを作成するときに useSharedPath 構成項目を追加し、"false" に設定します。次のコードは例を示しています:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: oss-pv
spec:
  accessModes:
  - ReadOnlyMany
  capacity:
    storage: 5Gi
  csi:
    driver: ossplugin.csi.alibabacloud.com
    nodePublishSecretRef:
      name: oss-secret
      namespace: default
    volumeAttributes:
      bucket: bucket-name
      otherOpts: -o max_stat_cache_size=0 -o allow_other
      url: oss-cn-zhangjiakou.aliyuncs.com
      useSharedPath: "false" 
    volumeHandle: oss-pv
  persistentVolumeReclaimPolicy: Delete
  volumeMode: Filesystem

subpath または subpathExpr を使用して OSS ボリュームをマウントすると例外が発生する

現象

subpath または subpathExpr を使用して OSS ボリュームをマウントすると、次の例外が発生します:

• マウントの失敗: OSS ボリュームをマウントする Pod が作成された後、CreateContainerConfigError 状態のままになり、次のようなイベントが表示されます。

  Warning  Failed          10s (x8 over 97s)  kubelet            Error: failed to create subPath directory for volumeMount "pvc-oss" of container "nginx"

• 読み取り/書き込みの例外: マウントされた OSS ボリュームに対して読み取りおよび書き込み操作を実行すると、Operation not permitted や Permission denied などの権限エラーメッセージが報告されます。

• アンマウントの失敗: OSS ボリュームがマウントされている Pod を削除すると、Pod は Terminating 状態のままになります。

原因

原因と解決策を説明するために、PV が次のように構成されていると仮定します:

...
    volumeAttributes:
      bucket: bucket-name
      path: /path
      ...

Pod は次のように構成されています:

...
       volumeMounts:
      - mountPath: /path/in/container
        name: oss-pvc
        subPath: subpath/in/oss
      ...

この場合、OSS サーバー上の subpath マウントディレクトリはバケット内の /path/subpath/in/oss/ です。

• マウント失敗の原因:

  • 原因 1: マウントディレクトリ /path/subpath/in/oss/ が OSS サーバーに存在せず、OSS ボリュームが使用するユーザーまたはロールに PutObject 権限が付与されていません。たとえば、読み取り専用シナリオでは、OSS ReadOnly 権限のみが構成されています。

    kubelet は、権限が不十分なため、OSS サーバー上に /path/subpath/in/oss/ ディレクトリを作成できません。

  • 原因 2: OSS サーバー上のマウントディレクトリ /path/subpath/in/oss/ の特定のレベルのディレクトリ オブジェクト (「/」で終わるキー、path/ や path/subpath/ など) がファイルシステムによってファイルとして解析されます。これにより、Kubelet は subpath のステータスを正しく判断できなくなります。

• 読み取り/書き込み例外の原因: 非 root ユーザーとして実行されるアプリケーションコンテナには、/path/subpath/in/oss/ ディレクトリ内のファイルに対する権限がありません。デフォルトの権限は 640 です。subpath を使用して OSS ボリュームをマウントする場合、ossfs によって OSS サーバーに実際にマウントされるディレクトリは PV で定義された path ディレクトリであり、上記の例では /path であり、/path/subpath/in/oss/ ではありません。allow_other または mp_umask マウントオプションは /path ディレクトリにのみ有効です。サブディレクトリとしての /path/subpath/in/oss/ ディレクトリは、引き続きデフォルトの権限 640 を持ちます。

• アンマウント失敗の原因: OSS サーバー上の /path/subpath/in/oss/ マウントディレクトリが削除され、kubelet が subpath を回収できなくなり、アンマウントに失敗します。

解決策

• マウント失敗の解決策:

  • 原因 1:

    1. OSS サーバー上に /path/subpath/in/oss/ ディレクトリを事前に作成して、kubelet のマウントパスを提供します。

    2. 多くのディレクトリを作成する必要がある場合 (たとえば、subpathExpr を使用して OSS ボリュームをマウントする場合) で、すべてを事前に作成できない場合は、OSS ボリュームが使用するユーザーまたはロールに putObject 権限を付与できます。

  • 原因 2:

    1. 「マウント後にディレクトリがファイルオブジェクトとして表示される」の原因 1 の解決策を参照して、各ディレクトリ オブジェクトが OSS サーバーに存在するかどうかを確認し (path/ や path/subpath/ などのキーを先頭のスラッシュなしでクエリする)、content-type と content-length フィールドを確認します。次の条件が満たされる場合、ディレクトリ オブジェクトはファイルシステムで異常にファイルとして識別されます:

       ディレクトリ オブジェクトが存在し (20X API リターンコードを想定、そうでなければ content-type と content-length フィールドは意味をなさないため)、その content-type が plain、octet-stream、または x-directory (json や tar など) ではなく、その content-length が 0 ではない。

    2. 上記の条件が満たされる場合は、「マウント後にディレクトリがファイルオブジェクトとして表示される」の原因 1 の解決策を参照して、異常なディレクトリ オブジェクトをクリアします。

• 読み取り/書き込み例外の解決策: umask 設定項目を使用して、サブディレクトリのデフォルト権限を変更します。たとえば、-o umask=000 はデフォルトの権限を 777 に変更します。

• アンマウント失敗の解決策: 「静的にプロビジョニングされた OSS ボリュームのアンマウントに失敗し、Pod が Terminating 状態のままになる」の原因 2 の解決策をご参照ください。

OSS ボリュームを介した OSS バケットへのアクセスが遅い

現象

OSS ボリュームを介した OSS バケットへのアクセスが遅いです。

原因

• 原因 1: OSS 自体にはファイル数の制限はありませんが、ファイル数が大きい場合、FUSE による OSS メタデータへのアクセスが過剰になり、バケットへのアクセスが遅くなります。

• 原因 2: OSS でバージョン管理が有効になっていると、バケット内に多数の削除マーカーが存在する場合、listObjectsV1 のパフォーマンスが低下します。

• 原因 3: OSS サーバー上のストレージタイプが標準以外に設定されています。他のストレージタイプは、データアクセスパフォーマンスをさまざまな程度で低下させます。

解決策

• 原因 1 の解決策: OSS バケットに読み取り専用モードでアクセスすることをお勧めします。多数の小さなオブジェクトを持つバケットの場合は、OSS SDK や CLI などのファイルシステム以外のマウント方法を使用してバケットデータにアクセスします。詳細については、「SDK サンプルコード一覧」をご参照ください。

• 原因 2 の解決策:

  1. CSI プラグインコンポーネントを v1.26.6 にアップグレードします。ossfs は listObjectsV2 を介したバケットへのアクセスをサポートします。

  2. 静的にプロビジョニングされた OSS ボリューム PV の otherOpts フィールドに -o listobjectsv2 を追加して問題を解決します。

• 原因 3 の解決策: ストレージタイプを変更するか、ファイルを解凍します。

OSS コンソールでファイルサイズが 0 になる

現象

コンテナに OSS ボリュームがマウントされ、ファイルにデータが書き込まれると、OSS コンソールではファイルサイズが 0 になります。

原因

コンテナは FUSE ベースの ossfs を使用して OSS をマウントします。ファイルの内容は、ファイルが閉じられるかフラッシュされたときにのみ OSS サーバーにアップロードされます。

解決策

`lsof + ファイル名` コマンドを使用して、ファイルが別のプロセスによって占有されているかどうかを確認します。対応するプロセスを閉じて、ファイル記述子 (fd) を解放します。詳細については、「lsof」をご参照ください。

アプリケーションがマウントポイントにアクセスすると「Transport endpoint is not connected」エラーが報告される

現象

コンテナに OSS ボリュームがマウントされた後、マウントポイントへのアクセスが突然失敗し、「Transport endpoint is not connected」というエラーが報告されます。

原因

コンテナは ossfs を使用して OSS をマウントします。OSS へのデータアクセス中に ossfs プロセスが予期せず終了し、マウントポイントが切断されます。

ossfs プロセスが予期せず終了する主な理由は次のとおりです:

• OOM Killed などのリソース不足による終了。

• データアクセス中のセグメンテーション違反による ossfs の終了。

解決策

1. ossfs プロセスが予期せず終了した理由を確認します。

   重要

   オンラインサービスがマウントポイントの切断の影響を受け、これが時折発生する問題である場合は、まずアプリケーションコンテナを再デプロイして OSS ボリュームを再マウントすることで修正できます。

   OSS ボリュームを再マウントすると、以下のトラブルシューティング手順に必要な情報の一部が失われます。関連する手順には注記があります。

   1. リソース不足で終了したかどうかを確認します。

      1. Pod レベルのリソース不足: CSI バージョンが 1.28 以降の場合、ossfs が配置されている Pod が再起動されたかどうか、および最後の予期せぬ終了の理由が OOM Killed などであったかどうかを確認します。ossfs が配置されている Pod を取得する方法については、「ossfs 1.0 の例外のトラブルシューティング」をご参照ください。

      2. ノードレベルのリソース不足: 再マウントにより異常な Pod が削除された場合、または CSI バージョンが 1.28 より前の場合、ACK または ECS の監視ダッシュボードで、ボリュームマウント中にノードのリソース使用率が高かったかどうかを確認できます。

   2. セグメンテーション違反で終了したかどうかを確認します。

      1. CSI バージョンが 1.28 より前の場合、ossfs はノード上のプロセスとして実行されます。ノードにログインしてシステムログをクエリする必要があります。セグメンテーション違反による終了に関連する情報を確認します。

         journalctl -u ossfs | grep segfault

      2. CSI バージョンが 1.28 以降の場合、ossfs が配置されている Pod のログを直接クエリします。"signal: segmentation fault" など、セグメンテーション違反による終了に関連する情報を確認します。

         説明

         次の状況では、関連するログを取得できない場合があります。ossfs プロセスがリソース不足で終了しなかったことが確認されている場合は、セグメンテーション違反のトラブルシューティングに進むことをお勧めします。

         • セグメンテーション違反がかなり前に発生した場合、ノードまたは Pod のログはローテーションにより失われている可能性があります。

         • アプリケーションコンテナが再マウントされた場合、Pod が削除されたためログは失われます。

2. ossfs がリソース不足で終了した場合は、ossfs が配置されている Pod のリソース制限を調整するか、OSS ボリュームをマウントするアプリケーション Pod をリソースが豊富なノードにスケジュールします。

   ossfs 自体が大量のメモリを消費していることが確認された場合、原因はアプリケーションまたはサードパーティのスキャンソフトウェアがマウントポイントに対して readdir 操作を行い、ossfs が多数の HeadObject リクエストを OSS サーバーに送信している可能性があります。readdir 最適化機能を有効にすることを検討できます。詳細については、「readdir 最適化機能の追加」をご参照ください。

3. 古い ossfs バージョンのセグメンテーション違反の問題のほとんどは、バージョン 1.91 以降で修正されています。ossfs がセグメンテーション違反で終了する場合は、まず ossfs のバージョンを 1.91 以降にアップグレードすることを検討してください。これは、CSI のバージョンを 1.30.4 以降にアップグレードすることを意味します。ossfs のバージョンの詳細については、「ossfs 1.0 バージョンガイド」をご参照ください。

   CSI のバージョンがすでに要件を満たしている場合は、以下の手順に従ってセグメンテーション違反の coredump ファイルをさらに収集し、チケットを送信してください。

   • ノードのオペレーティングシステムが Alibaba Cloud Linux 3 の場合、ノードにはデフォルトのコアダンプパラメーターが構成されています。ossfs のセグメンテーション違反が発生した後、ノードにログインし、/var/lib/systemd/coredump/ パスにあるパッケージ化された coredump ファイル core.ossfs.xxx.lz4 を見つけることができます。

   • Alibaba Cloud Linux 3 以外のオペレーティングシステムを持つノードの場合、ノードがプロセスの coredump ファイル生成を許可していることを確認する必要があります。たとえば、Alibaba Cloud Linux 2 ノードの場合、ノードにログインして次の操作を実行できます:

     echo "|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e" > /proc/sys/kernel/core_pattern

     構成後、Alibaba Cloud Linux 3 と同様に、ossfs のセグメンテーション違反が発生した場合、ノードにログインし、/var/lib/systemd/coredump/ パスにあるパッケージ化された coredump ファイル core.ossfs.xxx.xz を見つけることができます。

アプリケーションがマウントポイントにアクセスすると「Input/output error」エラーが報告される

現象

アプリケーションがマウントポイントにアクセスすると「Input/output error」エラーが報告されます。

原因

• 原因 1: OSS マウントパス下のオブジェクト名に特殊文字が含まれており、サーバーの応答が解析できません。

• 原因 2: FUSE ファイルシステムは、ルートマウントポイントに対する chmod や chown などの操作をサポートしていません。

• 原因 3: RAM 権限付与ポリシーの Resource が単一のバケットまたはその中のディレクトリである場合、権限付与が不完全です。

解決策

• 原因 1 の解決策:

  「ossfs 1.0 の例外のトラブルシューティング」を参照して ossfs クライアントログを取得します。ログには次のようなエラーログが含まれています:

  parser error : xmlParseCharRef: invalid xmlChar value 16
      <Prefix>xxx&#16;xxxx/</Prefix>

  ここで、 は解析不可能な Unicode 文字を表します。xxxxxxx/ はオブジェクトの完全名 (この例ではディレクトリ オブジェクト) を表します。API、コンソール、またはその他の方法を使用して、オブジェクトが OSS サーバーに存在することを確認します。この文字は OSS コンソールではスペースとして表示される場合があります。

  「オブジェクトの名前変更」を参照して、OSS サーバー上のオブジェクトの名前を変更します。オブジェクトがディレクトリの場合は、「一般的な操作」を参照し、ossbrowser 2.0 を使用してディレクトリ全体を名前変更することをお勧めします。

• 原因 2 の解決策:

  -o allow_other と -o mp_umask マウントパラメーターを使用して、マウントパスに対する chmod と同様の効果を実現します:

  パラメーター	説明
  allow_other	マウントディレクトリの権限を 777 に設定します。
  mp_umask	マウントディレクトリの権限マスクを設定します。このオプションは、allow_other オプションが設定されている場合にのみ有効になります。デフォルト値は 000 です。例: マウントディレクトリの権限を 770 に設定するには、-o allow_other -o mp_umask=007 を追加します。 マウントディレクトリの権限を 700 に設定するには、-o allow_other -o mp_umask=077 を追加します。

  -o gid と -o uid マウントパラメーターを使用して、マウントパスに対する chown と同様の効果を実現します:

  パラメーター	説明
  uid	マウントディレクトリ内のサブディレクトリとファイルを所有するユーザーの UID を指定します。
  gid	マウントディレクトリ内のサブディレクトリとファイルを所有するユーザーの GID を指定します。

• 原因 3 の解決策:

  特定のバケットまたはバケット内のパスにのみ権限を付与するには、「ステップ 2: demo-role-for-rrsa ロールに権限を付与する」の権限付与ポリシーをご参照ください。mybucket と mybucket/* (バケットを承認するため)、または mybucket/subpath と mybucket/subpath/* (パスを承認するため) の両方に権限を付与する必要があります。

マウント後にディレクトリがファイルオブジェクトとして表示される

現象

コンテナに OSS ボリュームがマウントされると、マウント後にディレクトリがファイルオブジェクトとして表示されます。

原因

• 原因 1: OSS サーバー上のディレクトリ オブジェクトの content-type がデフォルトの application/octet-stream タイプではなく (text/html や image/jpeg など)、またはディレクトリ オブジェクトのサイズが 0 ではありません。ossfs はそのメタデータに基づいてファイルオブジェクトとして扱います。

• 原因 2: 問題が原因 1 の理由によるものではなく、ディレクトリ オブジェクトに x-oss-meta-mode メタデータがありません。

解決策

• 原因 1 の解決策:

  HeadObject または stat (バケットとオブジェクト情報の表示) を使用して、ディレクトリ オブジェクトのメタデータを取得します。ディレクトリ オブジェクトはフォワードスラッシュ (/) で終わる必要があります (例: a/b/)。次のコードは API 応答の例を示しています。

  {
    "server": "AliyunOSS",
    "date": "Wed, 06 Mar 2024 02:48:16 GMT",
    "content-type": "application/octet-stream",
    "content-length": "0",
    "connection": "keep-alive",
    "x-oss-request-id": "65E7D970946A0030334xxxxx",
    "accept-ranges": "bytes",
    "etag": "\"D41D8CD98F00B204E9800998ECFxxxxx\"",
    "last-modified": "Wed, 06 Mar 2024 02:39:19 GMT",
    "x-oss-object-type": "Normal",
    "x-oss-hash-crc6xxxxx": "0",
    "x-oss-storage-class": "Standard",
    "content-md5": "1B2M2Y8AsgTpgAmY7Phxxxxx",
    "x-oss-server-time": "17"
  }

  上記の応答例では:

  • content-type: は application/octet-stream であり、ディレクトリ オブジェクトが application/octet-stream タイプであることを意味します。

  • content-length: は 0 であり、ディレクトリ オブジェクトのサイズが 0 であることを意味します。

  これらの条件が満たされない場合は、次のように修正できます:

  1. GetObject または ossutil クイックスタート を使用してオブジェクトを取得し、データが有用かどうかを確認します。データが有用であるか、不明な場合は、バックアップすることをお勧めします。たとえば、オブジェクトの名前を変更し (ディレクトリ オブジェクト xx/ の場合、新しい名前として xx を使用しないでください)、OSS にアップロードします。

  2. DeleteObject または rm (削除) を使用して問題のあるディレクトリ オブジェクトを削除し、ossfs がディレクトリを正常に表示するかどうかを確認します。

• 原因 2 の解決策:

  原因 1 の解決策で問題が解決しない場合は、コンテナに OSS ボリュームをマウントするときに、静的にプロビジョニングされた OSS ボリューム PV の otherOpts フィールドに -o complement_stat を追加できます。

  説明

  CSI プラグインコンポーネントのバージョン v1.26.6 以降では、この構成項目はデフォルトで有効になっています。ストレージコンポーネントを v1.26.6 以降にアップグレードし、アプリケーション Pod を再起動して、静的にプロビジョニングされた OSS ボリュームを再マウントすることで問題を解決できます。

OSS サーバーで多くの異常なリクエストが監視される

現象

コンテナに OSS ボリュームがマウントされると、OSS サーバーで監視されるリクエストの数が予想よりもはるかに多くなります。

原因

ossfs が OSS をマウントすると、ノード上にマウントパスが作成されます。ECS インスタンス上の他のプロセスによるこのマウントパスのスキャンも OSS へのリクエストに変換されます。多数のリクエストはコストを発生させる可能性があります。

解決策

監査を通じてリクエスト元のプロセスを追跡し、対処します。ノードで次の操作を実行できます。

1. auditd をインストールして起動します。

   sudo yum install auditd
   sudo service auditd start

2. ossfs マウントパスを監視対象ディレクトリとして設定します。

   • すべてのマウントパスを追加するには、次のコマンドを実行します。

     for i in $(mount | grep -i ossfs | awk '{print $3}');do auditctl -w ${i};done

   • 特定の PV のマウントパスを追加するには、次のコマンドを実行します。

     <pv-name> は指定された PV の名前です。

     for i in $(mount | grep -i ossfs | grep -i <pv-name> | awk '{print $3}');do auditctl -w ${i};done

3. 監査ログで、どのプロセスが OSS バケットのパスにアクセスしたかを確認します。

   ausearch -i 

   次のコードは監査ログ分析の例を示しています。この例では、--- 区切り文字間の監査ログがグループを形成し、監視対象のマウントポイントに対する単一の操作を記録します。この例は、updatedb プロセスがマウントポイント内のサブディレクトリに対して open 操作を実行したことを示しています。プロセス PID は 1636611 です。

   ---
   type=PROCTITLE msg=audit (September 22, 2023 15:09:26.244:291) : proctitle=updatedb
   type=PATH msg=audit (September 22, 2023 15:09:26.244:291) : item=0 name=. inode=14 dev=00:153 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
   type=CWD msg=audit (September 22, 2023 15:09:26.244:291) : cwd=/subdir1/subdir2
   type=SYSCALL msg=audit (September 22, 2023 15:09:26.244:291) : arch=x86_64 syscall=open success=yes exit=9 a0=0x55f9f59da74e a1=O_RDONLY | O_DIRECTORY | O_NOATIME a2=0x7fff78c34f40 a3=0x0 items=1 ppid=1581119 pid=1636611 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=1355 comm=updatedb exe=/usr/bin/updatedb key=(null)
   ---

4. ログを使用して、アプリケーション以外のプロセス呼び出しがあるかどうかをさらに確認し、修正します。

   たとえば、監査ログに updatedb がマウントされたディレクトリをスキャンしたことが示されている場合、/etc/updatedb.conf を変更してディレクトリをスキップさせることができます。次の操作を実行します。

   1. RUNEFS = の後に fuse.ossfs を追加します。

   2. PRUNEPATHS = の後にマウントされたディレクトリを追加します。

OSS ボリュームを介して書き込まれたファイルオブジェクトの Content-Type メタデータが常に application/octet-stream になる

現象

OSS ボリュームを介して書き込まれたファイルオブジェクトの Content-Type メタデータが常に application/octet-stream になり、ブラウザや他のクライアントがこれらのファイルを正しく識別して処理できなくなります。

原因

• Content-Type が指定されていない場合、ossfs はデフォルトでファイルオブジェクトをバイナリストリームファイルとして扱います。

• /etc/mime.types 構成ファイルを介して Content-Type が指定されましたが、有効になりませんでした。

解決策

1. CSI コンポーネントのバージョンを確認します。バージョン 1.26.6 と 1.28.1 には Content-Type 構成との互換性の問題があります。これらのバージョンを使用している場合は、CSI を最新バージョンにアップグレードしてください。詳細については、「[コンポーネントのお知らせ] csi-plugin および csi-provisioner バージョン 1.26.6 および 1.28.1 との互換性の問題」をご参照ください。

2. ノード上で mailcap または mime-support を使用して /etc/mime.types を生成して Content-Type をすでに指定している場合は、CSI バージョンをアップグレードしてから、対応する OSS ボリュームを再マウントします。

3. Content-Type を指定していない場合は、次の 2 つの方法のいずれかで指定できます:

   • ノードレベルの構成: ノード上に /etc/mime.types 構成ファイルを生成します。これは、そのノードにマウントされるすべての新しい OSS ボリュームに有効になります。詳細については、「よくある質問」をご参照ください。

   • クラスターレベルの構成: この方法は、クラスターにマウントされるすべての新しい OSS ボリュームに有効になります。/etc/mime.types の内容は、デフォルトで mailcap によって生成される内容と一致します。

     1. csi-plugin 構成ファイルが存在するかどうかを確認します。

        kubectl -n kube-system get cm csi-plugin

        存在しない場合は、次の内容で csi-plugin と同じ名前の ConfigMap を作成します。存在する場合は、元の ConfigMap の data.fuse-ossfs に mime-support="true" の内容を追加する必要があります。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: csi-plugin
          namespace: kube-system
        data:
          fuse-ossfs: |
            mime-support=true

     2. 構成を有効にするために csi-plugin を再起動します。

        csi-plugin を再起動しても、現在マウントされているボリュームの使用には影響しません。

        kubectl -n kube-system delete pod -l app=csi-plugin

4. 対応する OSS ボリュームを再マウントします。

ハードリンクを作成すると「Operation not supported」または「Operation not permitted」エラーが返される

現象

ハードリンクを作成すると、Operation not supported または Operation not permitted エラーが返されます。

原因

OSS ボリュームはハードリンク操作をサポートしておらず、Operation not supported エラーを返します。CSI の以前のバージョンでは、ハードリンク操作に対して返されるエラーは Operation not permitted でした。

解決策

OSS ボリュームを使用する場合は、ハードリンク操作を避けるようにアプリケーションを変更してください。アプリケーションでハードリンク操作を使用する必要がある場合は、別のストレージタイプに切り替えることをお勧めします。

OSS ボリュームを介した OSS へのアクセスレコードを表示するにはどうすればよいですか?

OSS コンソールで OSS の操作レコードを表示できます。リアルタイムログクエリを有効にしていることを確認してください。

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

2. 左側のナビゲーションウィンドウで、バケット をクリックします。バケットページで、目的のバケットを見つけてクリックします。

3. 左側のナビゲーションウィンドウで、ログ > リアルタイムクエリ を選択します。

4. リアルタイムクエリ タブで、クエリ構文と分析構文に基づいてクエリ文を入力し、OSS ログを分析します。user_agent および client_ip フィールドを使用して、ログが ACK からのものであるかどうかを判断できます。

   1. ACK から送信された OSS 操作リクエストを特定するには、user_agent フィールドを選択する必要があります。展開すると、user_agent に ossfs が含まれる任意のエントリを選択できます。

      重要

      • user-agent フィールドの値は ossfs のバージョンによって異なります。異なる ossfs バージョンでは user-agent フィールドの値が異なりますが、すべて aliyun-sdk-http/1.0()/ossfs で始まります。

      • ECS インスタンス上でも ossfs を介してマウントしている場合、関連するログはここに結合されます。

   2. 特定の ECS インスタンスまたはクラスターを特定するには、client_ip フィールドを選択し、対応する IP アドレスを選択します。

   これら 2 つのフィールドの選択を組み合わせることで、クエリされたログの例は次の図のようになります。

   一部のログクエリフィールドの説明

   フィールド	説明
   operation	OSS に対する操作のタイプ。例: GetObject、GetBucketStat。詳細については、「API 概要」をご参照ください。
   object	オブジェクト名。OSS 内のディレクトリまたはファイルです。
   request_id	リクエストの一意の識別子。リクエスト ID がある場合は、特定のリクエストに対して term クエリを実行できます。
   http_status, error_code	リクエスト結果のクエリ用。詳細については、「HTTP ステータスコード」をご参照ください。

共有マウントモードで ossfs プロセスを再起動するにはどうすればよいですか?

現象

認証情報や ossfs のバージョンを変更した後、すでに実行中の ossfs プロセスが自動的に更新されません。

原因

• ossfs が実行された後、認証情報などの構成は変更できません。構成を変更するには、ossfs プロセス (コンテナ化後は kube-system または ack-csi-fuse 名前空間の csi-fuse-ossfs-* Pod) と対応するアプリケーション Pod を再起動する必要があり、サービスの中断が発生します。そのため、デフォルトでは、CSI はすでに実行中の ossfs プロセスを変更しません。

• 通常の使用フローでは、ossfs のデプロイと削除は両方とも CSI によって処理されます。ossfs プロセスが配置されている Pod を手動で削除しても、CSI のデプロイプロセスはトリガーされません。

解決策

非コンテナ化バージョンの CSI を使用している場合、または排他的マウントを有効にしている場合は、対応するアプリケーション Pod を直接再起動できます。コンテナ化後は、デフォルトで共有マウントモードが使用されます。これは、同じノード上のすべてのアプリケーション Pod が同じ OSS ボリュームをマウントする場合、マウント用の ossfs プロセスを共有することを意味します。

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

   1. 次のコマンドを実行して、変更する必要がある csi-fuse-ossfs-* Pod を確認します。

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

      CSI バージョンが 1.30.4 より前の場合、次の操作を実行します:

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

      CSI バージョンが 1.30.4 以降の場合、次の操作を実行します:

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

      期待される出力:

      csi-fuse-ossfs-xxxx   1/1     Running   0          10d     192.168.128.244   cn-beijing.192.168.XX.XX   <none>           <none>

   2. 次のコマンドを実行して、現在 OSS ボリュームをマウントしているすべての Pod を確認します。

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

   3. 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****

   4. 次のコマンドを実行して、csi-fuse-ossfs-xxxx によってマウントされた Pod を取得します。これらは csi-fuse-ossfs-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.100.11   cn-beijing.192.168.100.3     <none>           <none>
      oss-static-94849f647-6****   1/1     Running   0          7m36s   192.168.100.18   cn-beijing.192.168.100.3     <none>           <none>

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

   kubectl scale などの方法を使用して、アプリケーション Pod (上記の例では oss-static-94849f647-4**** と oss-static-94849f647-6****) を同時に削除します。マウントされているアプリケーション Pod がなくなると、csi-fuse-ossfs-xxxx Pod は自動的に回収されます。レプリカ数が復元されると、新しい PV 構成で再マウントされ、CSI は新しい csi-fuse-ossfs-yyyy Pod を作成します。

   これらの Pod を同時に削除できない場合 (たとえば、Deployment、StatefulSet、または DaemonSet によって管理されている Pod を削除するとすぐに再起動がトリガーされる場合)、または Pod が OSS の読み取り/書き込みの失敗を許容できる場合:

   • CSI バージョンが 1.30.4 より前の場合、csi-fuse-ossfs-xxxx Pod を直接削除できます。この時点で、アプリケーション Pod 内での OSS への読み書きは disconnected error を返します。

   • CSI バージョンが 1.30.4 以降の場合、次の操作を実行できます:

     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-ossfs-yyyy Pod を介して OSS の読み書き操作を再開します。

OSS ボリュームのマウントに使用される ossfs のバージョンを確認するにはどうすればよいですか?

ossfs のバージョンは CSI のバージョンに対応しています。ACK で使用される ossfs のバージョンは、公開されている OSS バージョン (例: 1.91.1.ack.1) に基づいています。詳細については、「バージョンガイド」をご参照ください。公開バージョンをクエリするには、「ossfs 1.0 のインストール」および「ossfs 2.0 のインストール」をご参照ください。

• OSS ボリュームのマウントに使用されるデフォルトの ossfs バージョンは、Container Storage Interface (CSI) コンポーネントのバージョンに依存します。csi-provisioner をクエリして、使用されている特定のバージョンを見つけることができます。

  説明

  1.28 より前で 1.26.6 ではない CSI バージョンの場合、システムはノードにインストールされている ossfs バージョンを使用します。次の方法を使用して ossfs のバージョンをクエリする必要があります。

• すでにマウントされているボリュームの ossfs バージョンを確認するには、「ossfs のバージョンを表示する」をご参照ください。

CSI コンポーネントのバージョンによって、デフォルトの ossfs のバージョンが決まります。ACK で使用される ossfs のバージョンは、コミュニティのバージョン番号に .ack.x サフィックスを追加します (例: 1.91.1.ack.1)。詳細については、「バージョンガイド」をご参照ください。

公開コミュニティのバージョンについては、「ossfs 1.0 のインストール」および「ossfs 2.0 のインストール」をご参照ください。

次の方法でバージョン情報をクエリできます:

• バージョンの対応: 異なる CSI バージョンに対応する ossfs のバージョンを理解するには、「csi-provisioner」をご参照ください。

  古い CSI バージョン (v1.28 より前で v1.26.6 ではない) の場合、ossfs 1.0 はノード上で直接実行されます。そのバージョンはノードにインストールされているバージョンによって決まり、CSI によって制御されません。実際のバージョンを直接クエリしてください。

• 実際のバージョンの確認: マウントされたボリュームで現在実行されている正確な ossfs のバージョンを確認するには、「ossfs のバージョンを表示する」をご参照ください。

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

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

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

静的にプロビジョニングされた OSS ボリュームのアンマウントに失敗し、Pod が Terminating 状態のままになる

現象

静的にプロビジョニングされた OSS ボリュームのアンマウントに失敗し、Pod が Terminating 状態のままになります。

原因

Pod が削除中に Terminating 状態でスタックする理由は多数あります。まず kubelet のログを調べて原因を特定できます。OSS ボリュームのアンマウント失敗の一般的な理由は次のとおりです:

• 原因 1: ノード上の対応するマウントポイントが占有されています。CSI プラグインはマウントポイントをアンマウントできません。

• 原因 2: PV で指定された OSS バケットまたはディレクトリ (パス) が削除されました。現在のマウントポイントのステータスを判断できません。

解決策

• 原因 1 の解決策

  1. クラスターで次のコマンドを実行して、Pod の UID を取得します。

     <ns-name> と <pod-name> を実際の値に置き換えます。

     kubectl -n <ns-name> get pod <pod-name> -ogo-template --template='{{.metadata.uid}}'

     期待される出力:

     5fe0408b-e34a-497f-a302-f77049****

  2. Terminating 状態の Pod があるノードにログインします。

  3. ノードで次のコマンドを実行して、現在マウントポイントを占有しているプロセスがあるかどうかを確認します。

     lsof /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount/

     出力がある場合は、関連するプロセスを確認してクリーンアップします。

• 原因 2 の解決策

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

  2. バケットまたはディレクトリが削除されたかどうかを確認します。subpath を使用して OSS ボリュームをマウントした場合は、subpath マウントディレクトリが削除されたかどうかも確認する必要があります。

  3. アンマウントの失敗がディレクトリの削除によるものである場合は、次の操作を実行します。

     1. クラスターで次のコマンドを実行して、Pod の UID を取得します。

        <ns-name> と <pod-name> を実際の値に置き換えます。

        kubectl -n <ns-name> get pod <pod-name> -ogo-template --template='{{.metadata.uid}}'

        期待される出力:

        5fe0408b-e34a-497f-a302-f77049****

     2. Terminating 状態の Pod があるノードにログインします。ノードで次のコマンドを実行して、Pod に関連するマウントポイントをクエリします。

        mount | grep <pod-uid> | grep fuse.ossfs

        期待される出力:

        ossfs on /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount type fuse.ossfs (ro,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
        ossfs on /var/lib/kubelet/pods/<pod-uid>/volume-subpaths/<pv-name>/<container-name>/0 type fuse.ossfs (ro,relatime,user_id=0,group_id=0,allow_other)

        ossfs on と type の間のパスは、ノード上の実際のマウントポイントです。

     3. マウントポイントを手動でアンマウントします。

        umount /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount
        umount /var/lib/kubelet/pods/<pod-uid>/volume-subpaths/<pv-name>/<container-name>/0

     4. kubelet がリトライ時に正常に回収するのを待つか、--force を使用して Pod を直接削除します。