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 パラメーターを削除します。

• Kubernetes クラスターのバージョン 1.20 以降では、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 フィールドを使用して認証情報を指定する場合、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 バージョンをノードにインストールしました。

  • ノードのオペレーティングシステムのアップグレードにより、デフォルトの 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 は ack-csi-fuse 名前空間の csi-fuse-ossfs であり、アプリケーションが使用する ServiceAccount ではありません。

    重要

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

• 原因 3 のソリューション：

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

• 原因 4 のソリューション：

  PVC と同じ名前空間に Secret を作成します。その後、新しい PV を作成する際に、その nodePublishSecretRef フィールドをこの Secret にポイントします。詳細については、「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 内の PVC の volumeMounts を次のように構成します：

  volumeMounts:
    - mountPath: /path/to/file/a.txt # Pod 内のマウントパスで、bucket:/subpath に対応します。
      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: <roleB の ARN>

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

     assumeRoleArn: <roleB の ARN>

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 プロセスのマウントポイントは完全に独立しているため、異なる Pod による同じ OSS ボリュームへの読み書き操作は互いに影響しません。

コンテナ化後、ossfs プロセスは Pod 内のコンテナとして実行されます。具体的には、kube-system または ack-csi-fuse 名前空間の csi-fuse-ossfs-* という名前の Pod です。マルチマウントシナリオでは、排他マウントモードはクラスター内に多数の Pod を開始し、弾性ネットワークインターフェースの不足などの問題を引き起こす可能性があります。そのため、コンテナ化後はデフォルトで共有マウントモードが使用されます。このモードでは、同じノード上の複数の 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 サーバー上のサブパスマウントディレクトリは、バケット内の /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 がサブパスの状態を正しく判断できなくなります。

• 読み書きエラーの原因：非 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 がサブパスを回収できず、アンマウントが失敗します。

ソリューション

• マウント失敗のソリューション：

  • 原因 1 の場合：

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

    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 バージョンがすでに最新の場合は、次の手順に従ってセグメンテーション違反のコアダンプファイルを収集し、チケットを送信してください。

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

   • Alibaba Cloud Linux 3 を実行していないノードの場合、ノードがプロセスにコアダンプファイルの生成を許可していることを確認してください。たとえば、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/ パスにあるパッケージ化されたコアダンプファイル 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 を使用してノード上で /etc/mime.types ファイルを生成して Content-Type を指定した場合、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 が存在しない場合は、次の内容で作成します。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 つのフィールドを使用してクエリされたログの例を示しています。

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

   フィールド	説明
   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 を強制的に削除します。