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	マウントポイント内のファイルとフォルダーの権限マスクを設定します。 システム上のすべてのユーザーがマウントポイントディレクトリにアクセスできるようにします。これはマウントポイント自体にのみ影響し、その中のファイルには影響しないことに注意してください。ファイルの権限は別途管理する必要があります (たとえば、umask オプションや chmod を介して)。このオプションは値を取らず、単に -oallow_other として指定されます。デフォルトでは、root ユーザーのみが使用できます。 説明 バージョン 1.91.*：ファイルのデフォルト権限は 0640、フォルダーのデフォルト権限は 0750 です。 バージョン 1.80.*：ファイルとフォルダーの両方のデフォルト権限は 0777 です。

  これらのパラメーターを設定した後、securityContext から fsgroup パラメーターを削除します。

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

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

次のシナリオでは、Permission Denied または Operation not permitted エラーが発生する可能性があります。

OSS ボリュームのマウント失敗とアプリケーション Pod イベント：FailedMount

現象

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：AccessKey または RRSA ロール情報が正しくないか、関連する権限が不十分です。

• 原因 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 フィールドを使用して認証情報を指定する場合、シークレットは 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 バージョンをノードにインストールした。

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

  • ossfs がノードで実行される場合、CentOS、Alibaba Cloud Linux、ContainerOS、および Anolis OS のみをサポートします。

  • 互換性のあるオペレーティングシステムを持つノードで、FUSE、cURL、または xml2 などの ossfs が必要とするデフォルトの動的ライブラリを削除したか、デフォルトの OpenSSL バージョンを変更した。

• 原因 8：OSS サブディレクトリをマウントする際、AccessKey または RRSA ロールがそのサブディレクトリのみの権限しか持たない場合、マウントは失敗します。ossfs Pod のログには 403 AccessDenied と 404 NoSuchKey の両方のエラーが含まれます。

  ossfs が起動すると、OSS バケットの権限と接続性を自動的にチェックします。マウントターゲットが OSS サブディレクトリの場合、1.91.5 より前のバージョンの ossfs は、まずバケットのルートディレクトリにアクセスしようとします。アクセスに失敗すると、サブディレクトリへのアクセスを再試行します。バケットに対する完全な読み取り専用権限を持つ新しいバージョンの ossfs は、OSS バケットに存在しないサブディレクトリをマウントできます。

  したがって、AccessKey または RRSA で使用されるロールがサブディレクトリのみの権限しか持たない場合、最初の検証中に 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 の新機能と性能テスト をご参照ください。アップグレード後もマウントが失敗する場合は、この問題の 原因 8 をご参照ください。

• 原因 2 の解決策：

  • マウントに使用される RAM ユーザーまたは RAM ロールのポリシーに、2. RAM ロールの作成と権限付与 に記載されている権限が含まれていることを確認します。

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

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

  • RRSA 認証を使用してマウントされたボリュームの場合、RAM ロールに正しい信頼ポリシーが構成されていることを確認します。信頼ポリシーの構成方法については、1. クラスターの RRSA を有効にする をご参照ください。デフォルトでは、信頼される ServiceAccount は、アプリケーションで使用される ServiceAccount ではなく、ack-csi-fuse 名前空間の csi-fuse-ossfs です。

    重要

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

• 原因 3 の解決策：

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

• 原因 4 の解決策：

  PVC と同じ名前空間にシークレットを作成します。次に、新しい PV を作成するときに、その nodePublishSecretRef フィールドをこのシークレットにポイントします。詳細については、OSS 読み取り専用権限ポリシー をご参照ください。

• 原因 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 が存在するが異常な状態にある場合は、異常の原因を調査します。Pod が Running 状態であることを確認してから、アプリケーション 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 パッケージが含まれている場合は、次のコマンドを実行し、Pod が正常に起動できるかどうかを確認します：

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

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

• 原因 7 の解決策：

  • ossfs ツールを手動でインストールした場合は、その OS 互換性がノードの OS と一致するかどうかを確認してください。

  • ノードのオペレーティングシステムをアップグレードした場合は、次のコマンドを実行して 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 コマンドを使用して、対応するパッケージ (libssl1.0.0 など) をインストールします。

      apt-get install libssl1.0.0

• 原因 8 の解決策：

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

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

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

• 原因 9 の解決策：

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

• 原因 10 の解決策：

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

OSS ボリュームのマウント失敗：アプリケーション Pod がイベントを報告：FailedAttachVolume

現象

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

原因

イベントにメッセージ AttachVolume.Attach failed for volume "xxxxx" : attaching volumes from the kubelet is not supported が含まれています。このエラーは、ノードの kubelet で enable-controller-attach-detach 構成が有効になっていないことを示します。

これは通常、FlexVolume から CSI に移行する際に発生します。CSI バージョン 1.30.4 以降は、AttachVolume 操作を実行するためにこのパラメーターに依存しますが、移行中にノードの kubelet 構成が正しく更新されませんでした。

ソリューション

1. ノードの kubelet 構成を確認する

   ノードにログインし、kubelet の enable-controller-attach-detach パラメーターを確認します。

   コマンドで、/etc/systemd/system/kubelet.service.d/10-kubeadm.conf は kubelet のデフォルトの構成ファイルパスです。クラスターの実際のパスに置き換えてください。

   cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf | grep enable-controller-attach-detach

   期待される出力は true です。

   …… --enable-controller-attach-detach=true ……

2. ノード構成を更新する

   kubelet で enable-controller-attach-detach 構成が有効になっていない場合は、まずクラスター内のすべての FlexVolume ボリュームが移行されていることを確認します。次に、永続ストレージのないクラスターの FlexVolume を CSI に移行する を参照し、ステップ 3：クラスター内のすべてのノードプールの構成を変更する と ステップ 4：既存のノードの構成を変更する の指示に従って、ノードプールと既存のノードの構成を更新します。

OSS ボリュームから単一ファイルをマウントする

OSS ボリュームは ossfs を使用して OSS パスを Pod 内のファイルシステムとしてマウントします。ossfs は単一ファイルのマウントをサポートしていません。Pod が OSS から特定の 1 つのファイルのみを表示するようにしたい場合は、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 ID プロバイダーやデフォルト以外の 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 認証の要件を満たしていることを確認してください。

RRSA 認証でマウントされたボリュームを作成する前に、必要な RAM 認可を完了する必要があります。次の例は、アカウント A (クラスターがある場所) にアカウント B (OSS バケットがある場所) のバケットをマウントする方法を示しています。

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 ID プロバイダーに設定します。

   2. roleB を偽装する権限を roleA に付与します。詳細については、1. クラスターの RRSA を有効にする (静的ボリュームの場合) または 動的にプロビジョニングされた ossfs 1.0 ボリュームを使用する (動的ボリュームの場合) をご参照ください。

      roleA は OSS 関連の権限ポリシーを必要としませんが、sts:AssumeRole API を含む権限ポリシー (システムポリシー AliyunSTSAssumeRoleAccess など) が必要です。

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

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

   • 静的ボリューム (PV)：spec.csi.volumeAttributes フィールドに assumeRoleArn を追加します。

     assumeRoleArn: <ARN of roleB>

   • 動的ボリューム (StorageClass)：parameters フィールドに assumeRoleArn を追加します。

     assumeRoleArn: <ARN of roleB>

CoreDNS を使用して OSS アクセスエンドポイントを解決する

OSS エンドポイントを内部クラスタードメインにポイントするには、ossfs が実行される Pod に特定の DNS ポリシーを構成できます。これにより、マウント中にクラスターの CoreDNS を優先的に使用するよう強制されます。

この機能は、CSI コンポーネントバージョン v1.34.2 以降でのみサポートされています。アップグレードするには、CSI コンポーネントのアップグレード をご参照ください。

• 静的ボリューム (PV)：spec.csi.volumeAttributes フィールドに dnsPolicy を追加します。

  dnsPolicy: ClusterFirstWithHostNet

• 動的ボリューム (StorageClass)：StorageClass の parameters フィールドに dnsPolicy を追加します。

  dnsPolicy: ClusterFirstWithHostNet

コンテナ化された ossfs の排他マウントモードを有効にする

現象

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

原因

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

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

ソリューション

CSI バージョン 1.30.4 より前の場合、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 マウントでのエラー

現象

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 に存在せず、ボリュームのユーザーまたはロールに PutObject 権限が付与されていません。たとえば、読み取り専用シナリオでは、OSS ReadOnly 権限のみが構成されています。

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

  • 原因 2：OSS サーバー上のマウントディレクトリ /path/subpath/in/oss/ のいずれかのレベルのディレクトリオブジェクト (キーが / で終わるもの、たとえば path/ や path/subpath/) がファイルシステムでファイルとして解析され、Kubelet が subpath の状態を正しく判断できなくなります。

• 読み書きエラーの原因：非 root アプリケーションコンテナは、デフォルトで 640 の権限を持つ /path/subpath/in/oss/ ディレクトリ内のファイルに対する権限がありません。subpath メソッドを使用して OSS ボリュームをマウントする場合、ossfs は実際には PV で定義された path ディレクトリ (この例では /path) をマウントし、/path/subpath/in/oss/ ではありません。allow_other マウントオプションは /path ディレクトリにのみ有効です。サブディレクトリ /path/subpath/in/oss/ は依然としてデフォルトの 640 の権限を持ちます。

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

ソリューション

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

  • 原因 1 の場合：

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

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

  • 原因 2 の場合：

    1. マウント後にディレクトリがファイルオブジェクトとして表示される の原因 1 の解決策を参照して、OSS サーバー上の各ディレクトリオブジェクトが存在するかどうか (キーが path/ や path/subpath/ のようなもの。クエリ時にキーを / で始めないでください) を確認し、その content-type と content-length フィールドを検査します。次の条件が満たされる場合、ディレクトリオブジェクトは誤ってファイルとして識別される可能性があります：

       ディレクトリオブジェクトが存在し (API は content-type と content-length フィールドが意味を持つためには 2XX コードを返す必要があります)、その 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 ボリュームを使用してバケットにアクセスするのが遅いです。

原因

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

• 原因 2：バケットの ストレージクラス が、OSS サーバーで標準以外のストレージクラスに設定されています。他のストレージクラスは、データアクセスパフォーマンスを低下させる可能性があります。

ソリューション

• 原因 1 の解決策：

  1. CSI プラグインを v1.26.6 以降にアップグレードします。このバージョンでは、ossfs が listObjectsV2 を使用してバケットにアクセスできるようになります。

  2. 静的 OSS PV の otherOpts フィールドに -o listobjectsv2 を追加して問題を解決します。

• 原因 2 の解決策：ストレージクラスを変更するか、オブジェクトを解凍します。

OSS コンソールでファイルサイズが 0 と表示される

現象

コンテナに OSS データボリュームをマウントし、ファイルにデータを書き込んだ後、OSS コンソールでファイルサイズが 0 と表示されます。

原因

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

ソリューション

lsof <file_name> コマンドを使用して、ファイルが別のプロセスで使用されているかどうかを確認します。使用されている場合は、プロセスを閉じてファイルディスクリプタ (fd) を解放します。詳細については、lsof をご参照ください。

「Transport endpoint is not connected」エラー

現象

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

原因

コンテナは ossfs を使用して OSS バケットをマウントします。アプリケーションが OSS バケット内のデータにアクセスしている間に ossfs プロセスが予期せず終了すると、マウントポイントが切断されます。

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

• リソース不足、たとえば、Out of Memory (OOM) エラーによるプロセスの強制終了。

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

ソリューション

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

   重要

   本番アプリケーションが切断されたマウントポイントの影響を受け、これが断続的な問題である場合は、アプリケーションコンテナを再デプロイして OSS ボリュームを再マウントすることで、応急処置として修正できます。

   OSS ボリュームを再マウントすると、次のトラブルシューティング手順に必要な情報の一部が失われることに注意してください。これは該当箇所で示されています。

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

      1. Pod レベルのリソース不足：CSI v1.28 以降を使用している場合は、ossfs Pod が再起動されたかどうか、および最後の終了が OOM エラーまたは同様の問題によって引き起こされたかどうかを確認します。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 は OSS サーバーに多数の HeadObject リクエストを送信します。この場合、readdir の最適化を有効にできます。詳細については、新機能：readdir の最適化 をご参照ください。

3. 以前のバージョンの ossfs で発生するほとんどのセグメンテーション違反の問題は、バージョン 1.91 以降で修正されています。ossfs プロセスがセグメンテーション違反で終了する場合は、ossfs を 1.91.8.ack.2 以降にアップグレードすることをお勧めします。これは、CSI バージョンを 1.34.4 以降にアップグレードすることを意味します。ossfs のバージョンに関する詳細については、ossfs 1.0 のバージョン をご参照ください。

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

   • ノードが Alibaba Cloud Linux 3 を実行している場合、その coredump パラメーターはデフォルトで構成されています。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 ポリシーが単一のバケットまたはバケット内のディレクトリに権限を付与する場合、権限付与が不完全です。

ソリューション

• 原因 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 umask マウントパラメーターを使用して、マウントパスで chmod と同様の効果を実現します：

  パラメーター	説明
  allow_other	マウントディレクトリの権限を 777 に設定します。

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

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

• 原因 3 の解決策：

  特定のバケットまたはバケット内のパスにのみ権限を付与する必要がある場合は、バケットに対して mybucket と mybucket/* の両方に、またはパスに対して mybucket/subpath と mybucket/subpath/* の両方に権限を付与する必要があります。詳細については、2. RAM ロールを作成して権限を付与する をご参照ください。

ディレクトリがファイルとして表示される

現象

コンテナに 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 です。このタイプはディレクトリオブジェクトに使用されます。

  • 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 

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

   ---
   type=PROCTITLE msg=audit(2023.09.22 15:09:26.244:291) : proctitle=updatedb
   type=PATH msg=audit(2023.09.22 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(2023.09.22 15:09:26.244:291) : cwd=/subdir1/subdir2
   type=SYSCALL msg=audit(2023.09.22 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 = の後にマウントされたディレクトリを追加します。

ファイルの Content-Type が常に application/octet-stream になる

現象

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

原因

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

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

ソリューション

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

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

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

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

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

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

        kubectl -n kube-system get cm csi-plugin

        csi-plugin 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 エラーが返されます。

原因

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

ソリューション

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 のバージョンによって異なりますが、常に aliyun-sdk-http/1.0()/ossfs で始まります。

      • ECS インスタンスで ossfs を使用してボリュームをマウントする場合も、関連するログはここに含まれます。

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

   次の例は、これら 2 つのフィールドを使用してクエリされたログを示しています。

   * and __topic__: oss_access_log and bucket: cnfs-oss-csdr-test and client_ip : "192.168.xxx.xxx" and user_agent : "aliyun-sdk-go/v2.1.8 (Linux/5.10.134-15.al8.x86_64/x86_64;go1.17.13)"

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

   フィールド	説明
   operation	OSS で実行された操作のタイプ。例：GetObject および GetBucketStat。詳細については、操作 をご参照ください。
   object	オブジェクトの名前。OSS のディレクトリまたはファイルにすることができます。
   request_id	リクエストの一意の識別子。リクエスト ID を使用して特定のリクエストをクエリできます。
   http_status, error_code	リクエストの結果をクエリするために使用されます。詳細については、エラー応答 をご参照ください。

共有マウントの ossfs プロセスを再起動する

現象

認証情報や ossfs のバージョンを変更しても、実行中の ossfs プロセスは自動的に変更されません。

原因

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

• 通常の状態では、CSI は ossfs のデプロイと削除を処理します。ossfs プロセスを含む Pod を手動で削除しても、CSI が ossfs を再デプロイしたり、VolumeAttachment などの関連リソースを削除したりすることはありません。

ソリューション

非コンテナ化 CSI バージョンを使用している場合、または専用マウントを有効にしている場合は、対応するアプリケーション Pod を直接再起動できます。コンテナ化されたバージョンはデフォルトで共有マウントを使用します。つまり、同じ OSS ボリュームをマウントするノード上のすべてのアプリケーション Pod は、単一の 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 への読み書きアクセスを復元します。

ossfs のバージョンを確認する

ossfs のバージョンは CSI のバージョンとともに更新されます。ACK で使用される ossfs のバージョンは、ossfs の公開バージョンに基づいており、バージョン番号は 1.91.1.ack.1 のような形式です。詳細については、バージョン履歴 をご参照ください。公開バージョンに関する詳細については、ossfs 1.0 のインストール および ossfs 2.0 のインストール をご参照ください。

• OSS ボリュームをマウントするために使用されるデフォルトの ossfs バージョンは、CSI コンポーネントのバージョンによって異なります。詳細については、csi-provisioner をご参照ください。

  説明

  CSI バージョン 1.28 より前 (v1.26.6 を除く) の場合、ossfs 1.0 はノード上で実行され、使用されるバージョンは実際にノードにインストールされているものです。次の方法で ossfs のバージョンをクエリする必要があります。

• すでにマウントされている OSS ボリュームについては、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 静的ボリュームのアンマウント失敗

現象

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

原因

Pod が Terminating 状態で行き詰まる理由はいくつかあります。まず kubelet のログをチェックして問題を特定します。最も一般的な原因は次のとおりです：

• 原因 1：ノード上のボリュームのマウントポイントが使用中のため、CSI プラグインがアンマウントできません。

• 原因 2：PV で指定された OSS バケットまたはディレクトリが削除されたため、CSI プラグインがマウントポイントの状態を判断できません。

ソリューション

• 原因 1 の解決策

  1. 次のコマンドを実行して、Pod の UID を取得します。

     <ns-name> と <pod-name> を Pod の名前空間と名前に置き換えます。

     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 を使用してボリュームをマウントした場合は、subPath で指定されたサブディレクトリも削除されたかどうかを確認します。

  3. アンマウントの失敗がディレクトリの削除によるものであることを確認した場合は、次の手順を実行します：

     1. 次のコマンドを実行して、Pod の UID を取得します。

        <ns-name> と <pod-name> を Pod の名前空間と名前に置き換えます。

        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 を強制的に削除します。