Container Service for Kubernetes:OSS ボリュームに関する FAQ

OSS ボリュームのマウントに時間がかかるのはなぜですか？

問題

Object Storage Service (OSS) ボリュームのマウントに時間がかかります。

原因

次の条件が満たされている場合、kubelet はボリュームのマウント時に chmod または chown 操作を実行するため、時間がかかります。

• AccessModes パラメーターが永続ボリューム (PV) および永続ボリューム要求 (PVC) テンプレートで ReadWriteOnce に設定されています。

• securityContext.fsgroup パラメーターがアプリケーションテンプレートに設定されています。

解決策

• パラメーターを使用して、マウントポイントの下にあるファイルのユーザー ID (UID)、グループ ID (GID)、およびファイルモードを ossfs で変更できます。

  パラメーター	説明
  uid	subPath およびマウントポイント内のファイルの所有者の UID。
  gid	subPath およびマウントポイント内のファイルの所有者の GID。
  umask	subPath およびマウントポイント内のファイルの umask。umask パラメーターは、mp_umask と同じ方法で設定できます。umask パラメーターは allow_other パラメーターに依存しません。

  構成後、fsgroup パラメーターを securityContext セクションから削除します。

• 上記のメソッドとは別に、Kubernetes 1.20 以降を実行するクラスターの場合、fsGroupChangePolicy パラメーターを OnRootMismatch に設定できます。こうすることで、chmod または chown 操作は、システムが初めてポッドを起動するときにのみ実行されます。最初の起動が完了すると、OSS ボリュームのマウントが高速化されます。fsGroupChangePolicy の詳細については、「ポッドまたはコンテナーのセキュリティコンテキストの構成」をご参照ください。

OSS ボリュームのマウントに関連する権限はどのように管理すればよいですか？

次のシナリオでは、権限が拒否されましたエラーが表示されます。

シナリオ 1： マウントポイントにアクセスすると、権限が拒否されましたエラーが発生する

原因

デフォルトでは、Linux の root ユーザーを使用して OSS ボリュームをマウントします。root ユーザーには 700 の権限があります。コンテナーのプロセスが root 以外のユーザーとして OSS ボリュームにアクセスすると、権限が不十分なため、システムはエラーをプロンプト表示します。

解決策

ルートパスの権限を変更するための構成を追加します。

シナリオ 2： ossutil、OSS コンソール、または SDK を使用してファイルをアップロードすると、権限が拒否されましたエラーが発生する

原因

デフォルトでは、ossfs は ossfs 以外の方法でアップロードされたファイルに対して 640 の権限を持っています。コンテナーのプロセスが root 以外のユーザーとして OSS ボリュームにアクセスすると、権限が不十分なため、システムはエラーをプロンプト表示します。

解決策

root ユーザーとして chmod コマンドを実行して、目的のファイルの権限を変更します。また、次の構成を追加して、subPath およびマウントポイント内のファイルの権限を変更することもできます。

umask パラメーターは、現在の ossfs プロセス内の既存のファイルの権限のみを定義します。再マウントされたファイルまたは他の ossfs プロセス内のファイルには有効になりません。例：

• -o umask=022 を設定した後、stat を使用して OSS コンソールからアップロードされたファイルの権限を表示します。ファイルの権限は 755 である必要があります。-o umask=022 設定を削除した後、ファイルを再マウントします。ファイルの権限は 640 である必要があります。

• 現在のコンテナーのプロセスで root ユーザーとして -o umask=133 を設定した後、chmod コマンドを実行してファイルの権限を 777 に設定します。stat ファイルを実行した後、ファイルの権限は 644 になります。-o umask=133 設定を削除した後、ファイルを再マウントします。ファイルの権限は 777 に変更されます。

シナリオ 3： 他のコンテナーのプロセスが ossfs で作成されたファイルを読み書きするときに、権限が不十分であるというプロンプトが表示される

原因

ossfs で作成された通常のファイルのデフォルトの権限は 644 です。securityContext の fsGroup フィールドを設定した後、またはファイルに対して chmod または chown コマンドを実行した後、ファイルの権限または所有者が変更される場合があります。別のユーザーがコンテナーのプロセスを介してファイルにアクセスすると、システムは権限が不十分であるというプロンプトを表示する場合があります。

解決策

ファイルの権限を stat します。権限が不十分であるというプロンプトが表示された場合は、chmod コマンドを実行して、root ユーザーとしてファイルの権限を変更します。

シナリオ 4：Secret に保存されている AccessKey ペアを使用して、nodePublishSecretRef フィールドを PV に設定して Secret を参照した後、OSS ボリューム内のファイルにアクセスできません。元の AccessKey ペアは、AccessKey ペアのローテーションにより取り消されます。Secret 内の更新された AccessKey ペアは有効になりません。nodePublishSecretRefSecret を参照する PV のフィールドで、AccessKey ペアのローテーションにより元の AccessKey ペアが取り消されます。Secret 内の更新された AccessKey ペアは有効になりません。

原因

OSS ボリュームは、ossfs を使用してマウントされた FUSE ファイルシステムです。OSS ボリュームのマウント後、OSS ボリュームの AccessKey ペアを更新することはできません。OSS ボリュームを使用するアプリケーションは、元の AccessKey ペアのみを使用して OSS サーバーにリクエストを送信します。

解決策

シークレット内の AccessKey ペアが更新された後、OSS ボリュームを再マウントする必要があります。コンテナー化されていない ossfs バージョン、または排他モードで OSS ボリュームをマウントするコンテナー化された ossfs バージョンでは、アプリケーションポッドを再起動して ossfs の再起動をトリガーします。詳細については、「OSS ボリュームが複数のポッドで共有されている場合、ossfs プロセスを再起動するにはどうすればよいですか？」をご参照ください。

シナリオ 5： ハードリンクを作成するときに操作は許可されていませんエラーが発生する

原因

OSS ボリュームはハードリンクをサポートしていません。以前の Container Storage Interface (CSI) バージョンでは、ハードリンクを作成すると、操作は許可されていませんエラーが返されます。

解決策

アプリケーションで OSS ボリュームを使用している場合は、ハードリンクを使用しないでください。ハードリンクが必須の場合は、ストレージサービスを変更することをお勧めします。

シナリオ 6： subPath または subPathExpr を使用して OSS ボリュームをマウントするときに、読み取りまたは書き込みの権限が不十分であるというプロンプトが表示される

原因

root 以外のユーザーとして実行されるコンテナーのプロセスは、/path/subpath/in/oss/ パスのファイルに対する権限を持っていません。デフォルトの権限は 640 です。subPath を使用して OSS ボリュームをマウントする場合、OSS サーバー上のマウントポイントは PV で定義されたパス（上記の例では /path）であり、/path/subpath/in/oss/ ではありません。allow_other または mp_umask 設定は、/path パスにのみ有効になります。/path/subpath/in/oss/ subPath のデフォルトの権限は引き続き 640 です。

解決策

umask パラメーターを使用して、subPath のデフォルトの権限を変更します。たとえば、-o umask=000 を追加して、デフォルトの権限を 777 に設定します。

OSS ボリュームのマウントに失敗した場合はどうすればよいですか？

問題

OSS ボリュームのマウントに失敗しました。ポッドを起動できず、FailedMount イベントが生成されます。

原因

• 原因 1：以前の ossfs バージョンでは、OSS バケットを存在しないパスにマウントすることはできません。マウントポイントが存在しない場合、マウントエラーが発生します。

  重要

  OSS コンソールに表示される subPaths は、OSS サーバー上に存在しない場合があります。 ossutil または OSS API を使用して subPaths を確認してください。たとえば、/a/b/c/ パスを作成した場合、/a/b/c/ パスオブジェクトは作成されますが、/a/ パスオブジェクトまたは /a/b/ パスオブジェクトは存在しません。 /a/* オブジェクトをアップロードすると、/a/b オブジェクトまたは /a/c オブジェクトを見つけることができますが、/a/ パスオブジェクトは存在しません。

• 原因 2: サービスアカウントのアクセスキーまたは RAM ロール (RRSA) が誤ったロール情報を使用しているか、権限が不足しているためにマウントに失敗しました。

• 原因 3：CSI V1.30.4 以降では、ossfs を実行するポッドは ack-csi-fuse 名前空間にあります。マウントプロセス中に、CSI は最初に ossfs を実行するポッドを起動し、次にリモートプロシージャコール（ RPC ）リクエストを介してそのポッド内の ossfs プロセスを初期化します。イベントログにFailedMount /run/fuse.ossfs/xxxxxx/mounter.sock: connect: no such file or directory というメッセージが含まれている場合、これは ossfs を実行するポッドが適切に開始されなかったか、予期せず削除されたためにマウントが失敗したことを示します。

• 原因 4: イベントに Failed to find executable /usr/local/bin/ossfs: No such file or directory メッセージが含まれている場合は、ノードへの OSSFS のインストールに失敗したため、マウントに失敗しました。

• 原因 5: イベントに error while loading shared libraries: xxxxx: cannot open shared object file: No such file or directory というメッセージが含まれている場合、マウントは失敗しました。これは、ossfs が現在の CSI バージョンでノード上で実行されていますが、ossfs に必要な一部のダイナミックライブラリがオペレーティングシステムに存在しないことが原因です。考えられる原因:

  • 別の ossfs バージョンがノードに手動でインストールされており、必要なオペレーティングシステムがノードのオペレーティングシステムと異なります。

  • Alibaba Cloud Linux 2 から Alibaba Cloud Linux 3 への更新など、ノードのオペレーティングシステムの更新後にデフォルトの OpenSSL バージョンが変更されています。

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

  • 必要なオペレーティングシステムを実行しているノードから、FUSE、cURL、xml2 などの ossfs に必要なダイナミックライブラリが削除されているか、デフォルトの OpenSSL バージョンが変更されています。

• 原因 6：AccessKey または RRSA で使用されるロールが subPath 範囲の権限のみで承認されている場合、OSS バケットの subPath のマウントに失敗します。 ossfs ポッドログには、403 AccessDenied エラーと 404 NoSuchKey エラーの両方が表示されます。

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

  そのため、AccessKey または RRSA で使用されるロールが subPath 範囲の権限のみで承認されている場合、初期検証中に 403 AccessDenied エラーが発生します。 subPath が存在しない場合は、404 NoSuchKey エラーが発生し、ossfs が異常終了してマウントが失敗します。

• 原因 7：バケットにミラーリングベースの原点復帰ルールが設定されていますが、マウント パスがオリジンから同期されていません。

• 原因 8：バケットに対して静的 Web サイトホスティングが構成されています。 ossfs が OSS サーバー上のマウントポイントを確認すると、index.html ファイルが返されます。

ソリューション

• 原因 1 の解決策:

  OSS サーバー上に subPath が存在するかどうかを確認します。

  PV のマウントポイントが sub/path/ であるとします。stat（バケットとオブジェクト情報のクエリ） を実行して、objectname が sub/path/ であるオブジェクトをクエリするか、openapi HeadObject を実行して、key が sub/path/ であるオブジェクトをクエリできます。 404 が返された場合、subPath は OSS サーバー上に存在しません。

  1. ossutil、OSS SDK、または OSS コンソールを使用して、不足しているバケットまたは subPath を作成し、バケットを再度マウントできます。

  2. 1.91 以降の ossfs バージョンでは、存在しないマウントポイントを指定できます。そのため、ossfs を更新してこの問題を解決することもできます。詳細については、「ossfs 1.91 以降の新機能とストレステスト」をご参照ください。 ossfs を更新した後もこの問題が解決しない場合は、この質問の原因 6 を参照してください。

• 原因 2 の解決策:

  • 手順 2: demo-role-for-rrsa ロールに権限を付与するにリストされている権限が、マウントに使用される Resource Access Management (RAM) ユーザーまたは RAM ロールに付与されていることを確認します。

  • マウントポイントのルートディレクトリと subPath のファイルシステム権限を確認します。詳細については、OSS ボリュームのマウントに関連する権限を管理するにはどうすればよいですか?のシナリオ 1 とシナリオ 6 を参照してください。

  • RAM ユーザーとして AccessKey 認証を使用してマウントされたボリュームの場合、マウント中に使用された AccessKey が無効化またはローテーションされていないことを確認します。詳細については、OSS ボリュームのマウントに関連する権限を管理するにはどうすればよいですか?のシナリオ 4 を参照してください。

  • RRSA 認証を使用してマウントされたボリュームの場合、RAM ロールに正しい信頼ポリシーが構成されていることを確認します。信頼ポリシーの構成方法の詳細については、「手順 1: RAM ロールの作成」をご参照ください。 デフォルトでは、信頼できるサービスアカウントは、サービスで使用されるサービスアカウントではなく、ack-csi-fuse 名前空間の csi-fuse-ossfs です。

  • 重要

    このマウント方法は、Kubernetes 1.26 以降を実行し、CSI V1.30.4 以降がインストールされている ACK マネージドクラスター と ACK Serverless クラスター のみサポートしています。クラスターで RRSA が有効になっており、クラスターに 1.30.4 より前の CSI バージョンがインストールされている場合は、[製品の変更] CSI での ossfs のバージョンアップグレードとマウントプロセスの最適化 を参照して、クラスターで使用される RAM ロールに権限を付与してください。

• 原因 3 の解決策:

  1. 次のコマンドを実行して、ossfs を実行しているポッドが存在することを確認します。 PV_NAME をマウントする OSS PV の名前に置き換え、NODE_NAME をボリュームをマウントする必要があるポッドが存在するノードの名前に置き換えます。

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

     ポッドが存在するが異常な状態にある場合は、トラブルシューティングを行い、ポッドが Running 状態にあることを確認してから再起動して再マウントをトリガーします。ポッドが存在しない場合は、以下の手順に従ってトラブルシューティングを行います。

  2. (オプション) 監査ログやその他の関連ソースを確認して、ポッドが誤って削除されたかどうかを確認します。誤って削除される一般的な原因には、スクリプトのクリーンアップ、ノードのドレイニング、ノードの自動修復などがあります。この問題が再発しないように、適切な調整を行うことをお勧めします。

  3. csi-provisioner と csi-plugin の両方がバージョン 1.30.4 以降に更新されていることを確認した後:

     1. 次のコマンドを実行して、VolumeAttachment リソースが残っているかどうかを確認します。

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

        見つかった場合は、それらの VolumeAttachment リソースを削除します。

     2. ポッドを再起動して再マウントをトリガーし、ossfs を実行しているポッドが適切なプロセスで作成されていることを確認します。

• 原因 4 の解決策:

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

  2. 次のコマンドを実行して、ノード上の csi-plugin を再起動し、csi-plugin ポッドが正常に実行されているかどうかを確認します。次のコードでは、csi-plugin-**** は csi-plugin のポッドを指定します。

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

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

     ls /etc/csi-tool

     予期される出力:

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

     • 出力に次の ossfs RPM パッケージが表示されている場合は、次のコマンドを実行して、csi-plugin ポッドが正常に実行されているかどうかを確認します。

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

     • 出力に ossfs RPM パッケージが含まれていない場合は、チケットを送信してください。

• 原因 5 の解決策:

  • ossfs を手動でインストールした場合、必要なオペレーティングシステムがノードのオペレーティングシステムと同じであることを確認します。

  • ノードのオペレーティングシステムを更新した場合は、次のコマンドを実行して csi-plugin を再起動し、ossfs を更新し、OSS ボリュームを再マウントします。

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

  • CSI を 1.28 以降に更新することをお勧めします。これらのバージョンでは、ossfs はコンテナー内で実行されます。そのため、ノードのオペレーティングシステムに関する要件はありません。

  • CSI を更新できない場合は、必要なオペレーティングシステムをインストールするか、不足している動的ライブラリを手動でインストールします。次の例では、ノードは 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

• 原因 6 の解決策:

  • 推奨: CSI プラグインを 1.32.1-35c87ee-aliyun 以降に更新します。

  • 代替案 1: この質問の原因 1 の解決策を参照して、指定された subPath がバケットに存在するかどうかを確認します。

  • 代替案 2: 長期にわたって subPath をマウントする必要がある場合は、権限の範囲をバケット全体に拡張することをお勧めします。

• 原因 7 の解決策:

  OSS ボリュームをマウントする前に、オリジンからデータを同期します。詳細については、「オリジンへの復帰」をご参照ください。

• 原因 8 の解決策:

  静的 Web サイトホスティングを無効にするか、構成を変更して、再試行してください。詳細については、「概要」をご参照ください。

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

OSS ボリュームは、ossfs ツールを使用して、OSS から ポッド に特定のパスをファイルシステムとしてマウントします。ただし、ossfs 自体は個々のファイルのマウントをサポートしていません。ポッド に OSS から特定のファイルのみを読み取らせたい場合は、subPath メソッドを使用してこれを実現できます。

たとえば、OSS の bucket:/subpath にある a.txt ファイルと b.txt ファイルを 2 つの異なる ポッド にマウントするとします。それぞれの ポッド 内の両方のファイルのストレージパスは /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 # subpath の値は、a.txt と b.txt の親パスです。
      url: "oss-cn-hangzhou.aliyuncs.com"

対応する PVC を作成した後、次の YAML テンプレートを使用して、ポッド にマウントされた PVC の volumeMounts を構成します。

  volumeMounts:
    - mountPath: /path/to/file/a.txt # OSS からの特定のファイルがマウントされるパス。 OSS パス bucket:/subpath は、ポッド の内部マウントパス /path/to/file にマッピングされています。
      name: oss-pvc # volume の名前と同じです。
      subPath: a.txt # もう一方のファイルには b.txt を使用することもできます。このパラメーターは、bucket:/subpath 内のファイルへの相対パスです。

基本的に、マウント後、ポッド 内の /path/to/file/a.txt にアクセスすると、bucket:/subpath/a.txt にある外部 OSS ファイルを参照します。

OSS ボリュームのマウント方法の詳細については、「静的にプロビジョニングされた ossfs 1.0 ボリュームをマウントする」をご参照ください。

OSS ボリュームの読み取り速度が遅い場合はどうすればよいですか?

問題

OSS ボリュームの読み取り速度が遅いです。

原因

• 原因 1: OSS はオブジェクトの数を制限していません。ただし、オブジェクトの数が 1000 を超えると、FUSE が過剰な量のメタデータにアクセスする可能性があります。その結果、OSS バケットへのアクセスが遅くなります。

• 原因 2: OSS でバージョン管理が有効になっていると、バケットに大量の削除タグが生成され、listObjectsV1 のパフォーマンスが低下します。

• 原因 3: OSS サーバーが ストレージクラス を標準以外に設定しています。これらのストレージクラスのバケットへのアクセスは遅くなります。

解決策

• 原因 1 の解決策: OSS ボリュームのアクセスモードを読み取り専用に設定することをお勧めします。 OSS バケットに大量のファイルを保存する場合は、ファイルシステムを使用してファイルにアクセスするのではなく、OSS SDK または CLI を使用してバケット内のファイルにアクセスすることをお勧めします。詳細については、「SDK デモの概要」をご参照ください。

• 原因 2 の解決策:

  1. CSI プラグインを v1.26.6 にアップグレードします。 ossfs を使用すると、listObjectsV2 を使用してバケットにアクセスできます。

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

• ストレージクラスを変更するか、オブジェクトをリストアします。

OSS コンソールでファイルにデータを書き込んだ後、ファイルのサイズが 0 と表示されるのはなぜですか?

問題

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

原因

OSS バケットは、ossfs を使用して FUSE ファイルシステムとしてマウントされます。この場合、ファイルに対して close コマンドまたは flush コマンドを実行した場合にのみ、ファイルが OSS サーバーにアップロードされます。

ソリューション

ファイルがプロセスによって使用されているかどうかを確認するには、lsof コマンドをファイル名と共に実行します。ファイルがプロセスによって使用されている場合は、プロセスを終了して、ファイルのファイル記述子（FD）を解放します。詳細については、「lsof」をご参照ください。

「トランスポートエンドポイントが接続されていません」エラーが返された場合はどうすればよいですか？

問題

コンテナーにマウントされた OSS ボリュームのマウントポイントがコンテナーから突然切断され、「Transport endpoint is not connected」（トランスポート エンドポイントは接続されていません）エラーが発生します。

原因

OSS ボリュームは ossfs を使用してマウントされており、ビジネスが OSS ボリューム内のデータにアクセスすると、ossfs プロセスが異常終了します。その結果、ボリュームのマウントポイントがコンテナーから切断されます。

考えられる原因は次のとおりです。

• 計算リソースが不足し、ossfs プロセスで OOMKilled エラーが発生します。

• OSS ボリューム内のデータにビジネスがアクセスする際に、ossfs でセグメンテーション エラーが発生します。

解決策

1. ossfs プロセスの異常終了の原因を特定します。

   重要

   マウントポイントの切断が原因でビジネスが中断された場合、ビジネスを再デプロイして OSS ボリュームを再マウントできます。

   OSS ボリュームの再マウントは、以下の手順で説明するように、特定の情報が失われる可能性があります。

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

      1. ポッドリソース不足: CSI V1.28 以降がインストールされている場合は、ossfs ポッドが再起動され、最新の終了が OOMKilled エラーによって発生したかどうかを確認します。 ossfs ポッドに関する情報のクエリ方法の詳細については、「ossfs 1.0 の例外のトラブルシューティング」をご参照ください。

      2. ノードリソース不足: 再マウントが原因で ossfs ポッドが削除された場合、またはインストールされている CSI バージョンが V1.28 より前の場合は、ACK または ECS コンソールの関連する監視ダッシュボードで、ボリュームがマウントされたときにノードのリソースウォーターマークが高かったかどうかを確認できます。

   2. セグメンテーションフォールトが発生したかどうかを確認します。

      1. インストールされている CSI バージョンが 1.28 より前の場合、ossfs はノードのプロセスで実行されます。ノードにログインし、OS ログを表示して、セグメンテーションフォールトが発生したかどうかを確認する必要があります。

         journalctl -u ossfs | grep segfault

      2. CSI V1.28 以降がインストールされている場合は、ossfs ポッドのログを表示して、"signal: segmentation fault" などのセグメンテーションフォールトに関する情報がログコンテンツに表示されるかどうかを確認できます。

         説明

         以下の場合、ossfs ポッドのログを取得できない場合があります。 ossfs の終了がリソース不足によって発生していないことを確認できる場合は、セグメンテーションフォールトのトラブルシューティング手順に進むことをお勧めします。

         • セグメンテーションフォールトがかなり前に発生した場合、ローテーションが原因でノードまたはポッドのログが失われている可能性があります。

         • OSS ボリュームがビジネスポッドに再マウントされた場合、ポッドの削除が原因でポッドログが失われます。

2. リソース不足が原因で ossfs ポッドが終了した場合は、ポッドのリソース制限を増やすか、十分なリソースを提供するノードに OSS ボリュームがマウントされているビジネスポッドをスケジュールします。

   ossfs ポッドが過剰なメモリを消費したために終了した場合、ビジネスまたはサードパーティ製のスキャナーソフトウェアがマウントポイントで readdir 操作を実行し、ossfs が OSS サーバー側に大量の HeadObject 呼び出しを送信することが原因である可能性があります。 この問題を解決するには、readdir 最適化機能を有効にすることができます。 詳細については、「ossfs 1.0 の新機能と ossfs パフォーマンスベンチマーク」をご参照ください。

3. ほとんどのセグメンテーションフォールトは、ossfs 1.91 以降で修正されています。 セグメンテーションフォールトが原因で ossfs が終了した場合は、ossfs を V1.91 以降にアップグレードし、CSI を V1.30.4 以降にアップグレードすることをお勧めします。 ossfs バージョンの詳細については、「ossfs 1.0 リリースノート」をご参照ください。

   インストールされている CSI バージョンが V1.30.4 以降の場合は、次の操作を実行してコアダンプを収集し、[チケットを送信]します。

   • ノード OS が Alibaba Cloud Linux 3 の場合、セグメンテーションフォールトが発生すると、ノードはコアダンプを生成できます。 ossfs でセグメンテーションフォールトが発生した後、ノードにログインし、/var/lib/systemd/coredump/ パスで生成されたコアダンプ core.ossfs.xxx.lz4 を見つけることができます。

   • ノード OS が Alibaba Cloud Linux 3 でない場合は、セグメンテーションフォールトが発生したときにノードがコアダンプを生成できるかどうかを確認します。 たとえば、ノード OS が Alibaba Cloud Linux 2 の場合は、ノードにログインし、次のコマンドを実行して、セグメンテーションフォールト時にコアダンプが生成されるように構成します。

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

     構成が完了すると、ossfs でセグメンテーションフォールトが発生したときに、システムは /var/lib/systemd/coredump/ ディレクトリにコアダンプ core.ossfs.xxx.xz を生成します。

コンテナーにパスをマウントした後、パスがオブジェクトとして表示されるのはなぜですか?

問題

コンテナーにパスをマウントすると、パスはオブジェクトとして表示されます。

原因

原因 1: OSS サーバー上のパスのコンテンツタイプが、デフォルトの application/octet-stream タイプ (text/html や image/jpeg など) ではなく、パスのオブジェクトサイズが 0 ではない。この場合、ossfs はパスのメタデータに基づいてパスをオブジェクトとして表示します。

原因 2：パスオブジェクトにメタデータ 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 です。

上記の条件が満たされていない場合は、次の手順を実行します。

1. GetObject または ossutil を使用してオブジェクトを取得し、メタデータを確認します。オブジェクトのメタデータが要件を満たしている場合、またはメタデータを確認できない場合は、オブジェクトをバックアップすることをお勧めします。たとえば、オブジェクトの名前を変更して OSS にアップロードします。xx/ パスのオブジェクトの場合、オブジェクト名として xx を使用しないでください。

2. DeleteObject または rm を使用して元のパスオブジェクトを削除し、ossfs がパスオブジェクトを正常に表示するかどうかを確認します。

原因 2 の解決策:

ソリューションの手順を実行した後も問題 1 が発生する場合は、OSS ボリュームをマウントするときに、静的にプロビジョニングされた OSS ボリュームに対応する PV の otherOpts フィールドに -o complement_stat を追加します。

OSS サーバーが予期せぬ大量のリクエストを識別した場合はどうすればよいですか？

問題

OSS ボリュームをコンテナーにマウントすると、OSS サーバーは予期しない大量の リクエスト を識別します。

原因

ossfs が OSS バケットをマウントすると、ノードにマウントターゲットが生成されます。 ECS ノード上の他のプロセスがマウントターゲットをスキャンすると、OSS サーバーにリクエストが送信されます。 リクエスト数が上限を超えると、料金が発生します。

ソリューション

ActionTrail を使用して、リクエストを生成するプロセスを追跡し、問題を修正します。ノードでは、次の操作を実行できます。

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=9a0=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 ボリューム内のオブジェクトのメタデータのコンテンツタイプが application/octet-stream の場合はどうすればよいですか?

問題

OSS ボリューム内のオブジェクトのメタデータのコンテンツタイプが application/octet-stream です。その結果、ブラウザまたは他のクライアントはオブジェクトを認識または処理できません。

原因

• ossfs 内のオブジェクトのデフォルトのコンテンツタイプはバイナリ ストリームです。

• /etc/mime.types ファイルを変更してコンテンツタイプを指定した後、変更が有効になりません。

解決策

1. CSI 1.26.6 および 1.28.1 には、コンテンツタイプの 設定 に互換性の問題があります。上記のバージョンを使用している場合は、CSI を最新バージョンに更新してください。詳細については、「[コンポーネントに関するお知らせ] csi-plugin 1.26.6 および 1.28.1、csi-provisioner 1.26.6 および 1.28.1 における非互換の構成」をご参照ください。

2. mailcap または mime-support を使用してノード上に /etc/mime.types ファイルを生成し、コンテンツタイプを指定した場合は、CSI を更新し、OSS ボリュームを再マウントします。

3. コンテンツタイプが指定されていない場合は、次の方法でコンテンツタイプを指定します。

   • ノードレベルの設定: ノード上に /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 を再起動します。再起動は、既にマウントされているボリュームには影響しません。

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

4. 目的の OSS ボリュームを再マウントします。

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

OSS ボリュームに RRSA 認証を使用する場合、サードパーティの OpenID Connect ID プロバイダー (OIDC IdP) の Amazon リソースネーム (ARN) またはデフォルト以外の ServiceAccount を使用することはできません。

CSI がデフォルトのロール ARN と OIDC IdP ARN を取得できるようにするには、PV の roleName パラメーターを目的の RAM ロールに設定します。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>" 

ハードリンクを作成するときに「Operation not supported」または「Operation not permitted」エラーが発生した場合はどうすればよいですか？

Adding a WordPress Plugin Adding a WordPress Plugin Adding plugins to your WordPress site is easy. There are two main ways to do it: through the WordPress admin dashboard, or by uploading the plugin files directly via FTP. Method 1: Installing Through the Dashboard This is the easiest way to install most plugins. Log in to your WordPress admin dashboard. Navigate to Plugins > Add New. Search for the plugin you want to install by name. For example, if you want to install the Yoast SEO plugin, search for "Yoast SEO". Once you've found the plugin, click Install Now. After installation, click Activate. Method 2: Uploading via FTP This method is useful for installing plugins manually, especially if you have a custom plugin or are having trouble installing through the dashboard. Download the plugin's ZIP file. Unzip the file. This will create a folder containing the plugin's files. Using an FTP client, upload the plugin folder to your website's /wp-content/plugins/ directory. Log in to your WordPress admin dashboard. Navigate to Plugins. Find the plugin you just uploaded and click Activate. For more information, see Managing Plugins. ``` ```html WordPress プラグインの追加 WordPress プラグインの追加 WordPress サイトにプラグインを追加するのは簡単です。主に 2 つの方法があります。WordPress 管理ダッシュボードを使用する方法と、FTP 経由でプラグインファイルを直接アップロードする方法です。 方法 1：ダッシュボードからインストールする これは、ほとんどのプラグインをインストールする最も簡単な方法です。 WordPress 管理ダッシュボードにログインします。 プラグイン > 新規追加 に移動します。 インストールするプラグインを名前で検索します。たとえば、Yoast SEO プラグインをインストールする場合は、「Yoast SEO」を検索します。 プラグインを見つけたら、今すぐインストール をクリックします。 インストール後、有効化 をクリックします。 方法 2：FTP 経由でアップロードする この方法は、プラグインを手動でインストールする場合、特にカスタムプラグインを使用している場合や、ダッシュボードからインストールできない場合に役立ちます。 プラグインの ZIP ファイルをダウンロードします。 ファイルを解凍します。これにより、プラグインのファイルを含むフォルダーが作成されます。 FTP クライアントを使用して、プラグインフォルダーをウェブサイトの /wp-content/plugins/ ディレクトリにアップロードします。 WordPress 管理ダッシュボードにログインします。 プラグイン に移動します。 アップロードしたプラグインを見つけて、有効化 をクリックします。 詳細については、「Managing Plugins」をご参照ください。 ```

操作がサポートされていません または 操作が許可されていません エラーは、ハードリンクを作成するときに発生します。

原因

操作がサポートされていません エラーは、OSS ボリュームがハードリンクをサポートしていないために発生します。以前の CSI バージョンでは、ハードリンクを作成すると 操作は許可されていません エラーが返されます。

ソリューション

アプリケーションで OSS ボリュームを使用している場合は、ハードリンクの使用を避けてください。ハードリンクが必須である場合は、ストレージ サービスの変更をお勧めします。

スタティックプロビジョニングされた OSS ボリュームをポッドからアンマウントできない場合、ポッドが Terminating 状態のままになる場合の対処方法

問題

スタティックプロビジョニングされた OSS ボリュームをポッドからアンマウントできず、ポッドが Terminating 状態のままになっています。

原因

システムがポッドを削除するときにポッドが Terminating 状態のままになる場合は、kubelet ログを確認してください。OSS ボリュームのアンマウントが失敗する原因として考えられるのは、次のとおりです。

• 原因 1: ノード上のマウントポイントが使用中です。CSI はマウントポイントをアンマウントできません。

• 原因 2: PV で指定された OSS バケットまたはパスが削除されています。マウントポイントのステータスは不明です。

解決策

原因 1 の解決策:

1. クラスタで次のコマンドを実行して、ポッド 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 状態のポッドをホストしているノードにログインします。

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

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

   占有している場合は、プロセスを確認して終了します。

原因 2 の解決策:

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

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

3. パスが削除されたためにアンマウントに失敗した場合は、次の手順を実行します。

   1. クラスタで次のコマンドを実行して、ポッド 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 状態のポッドをホストしているノードにログインし、次のコマンドを実行してポッドのマウントポイントをクエリします。

      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 を実行してポッドを削除します。

4. 問題が解決しない場合は、チケットを送信 してください。

ACK コンソールで検出タスクが長時間スタックした状態になる、検出タスクが失敗するがエラーメッセージが表示されない、またはシステムが「不明なエラー」と表示する場合はどうすればよいですか。

問題

検出タスクが長時間スタックする、検出タスクが失敗するがエラーメッセージが表示されない、またはシステムが「不明なエラー」をプロンプトします。

原因

検出タスクが長時間スタックする場合は、通常、ネットワークの問題が原因です。その他の不明な問題が原因である場合は、ログを出力するか、ossutil を使用して手動で原因を特定してください。

ソリューション

ログと ossutil を使用して原因を特定できます。

ossutil -e "<endpoint>" -i "<accessKeyID>" -k "<accessKeySecret>" stat oss://"<bucket><path>"

ossutil -e "oss-<region-id>-internal.aliyuncs.com" -i "<accessKeyID>" -k "<accessKeySecret>" stat oss://"cnfs-oss-xxx-xxx/xx/"

「接続タイムアウト」ネットワークエラーを処理するにはどうすればよいですか？

問題

接続タイムアウトエラーが発生します。

原因

OSS バケットへのアクセスがタイムアウトしました。考えられる原因:

• バケットとクラスタが異なるリージョンにあり、バケットの内部エンドポイントが使用されている場合、バケットへのアクセスは失敗します。

• バケットのパブリックエンドポイントが使用されているが、クラスタにインターネットアクセスがない場合、バケットへのアクセスは失敗します。

解決策

• PV を再作成し、バケットのパブリックエンドポイントを選択します。

• バケットとクラスタが同じリージョンにある場合は、PV を再作成して内部エンドポイントを使用できます。そうでない場合は、セキュリティグループとネットワーク構成を確認し、問題を修正して、PV を再作成します。

「StatusCode=403」権限エラーを処理するにはどうすればよいですか？

問題

service returned error: StatusCode=403 エラーが発生します。

原因

AccessKey ペアに、マウントする OSS バケットに対する読み取り権限がありません。

• StatusCode=403, ErrorCode=AccessDenied, ErrorMessage="You do not have read acl permission on this object." エラーは、AccessKey ペアに必要な権限がないことを示しています。

• StatusCode=403, ErrorCode=InvalidAccessKeyId, ErrorMessage="The OSS Access Key Id you provided does not exist in our records." エラーは、AccessKey ペアが存在しないことを示しています。

• StatusCode=403, ErrorCode=SignatureDoesNotMatch, ErrorMessage="The request signature we calculated does not match the signature you provided. Check your key and signing method." エラーは、AccessKey ペアにスペルミスがある可能性があることを示しています。

解決策

AccessKey ペアが存在し、スペルミスがなく、バケットに対する読み取り権限を持っていることを確認します。

バケットまたはパスが存在せず、StatusCode=404 状態コードが返された場合はどうすればよいですか？

問題

service returned error: StatusCode=404 エラーが発生します。

原因

静的にプロビジョニングされた OSS ボリュームを、存在しないバケットまたは subPath にマウントすることはできません。バケットまたは subPath を事前に作成する必要があります。

• StatusCode=404, ErrorCode=NoSuchBucket, ErrorMessage="The specified bucket does not exist." エラーは、バケットが存在しないことを示します。

• StatusCode=404, ErrorCode=NoSuchKey, ErrorMessage="The specified key does not exist." エラーは、subPath オブジェクトが存在しないことを示します。

  重要

  OSS コンソールに表示される subPaths は、OSS サーバー上に存在しない場合があります。 ossutil または OSS API を使用して subPaths を確認してください。たとえば、/a/b/c/ パスを作成した場合、/a/b/c/ パスオブジェクトは作成されますが、/a/ パスオブジェクトまたは /a/b/ パスオブジェクトは存在しません。 /a/* オブジェクトをアップロードすると、/a/b オブジェクトまたは /a/c オブジェクトを見つけることができますが、/a/ パスオブジェクトは存在しません。

ソリューション

ossutil、SDK、または OSS コンソールを使用して、不足しているバケットまたは subPath を作成してから、PV を再作成します。

他の OSS 状態コードまたはエラーコードが返された場合はどうすればよいですか？

問題

service returned error: StatusCode=xxx エラーが発生します。

原因

OSS へのアクセス時にエラーが発生した場合、OSS はトラブルシューティングのために状態コード、エラーコード、およびエラーメッセージを返します。

ソリューション

OSS が他の状態コードまたはエラーコードを返した場合、詳細については、「HTTP ステータスコード」をご参照ください。

ossfs をコンテナー化した後、排他モードで ossfs を起動するにはどうすればよいですか？

問題

同じノード上の同じ OSS ボリュームを使用する Pod は、マウントターゲットを共有します。

原因

ossfs をコンテナー化する前は、OSS ボリュームはデフォルトで排他モードでマウントされます。 OSS ボリュームを使用するポッドごとに ossfs プロセスが起動されます。 ossfs プロセスごとに異なるマウントポイントが割り当てられます。そのため、同じ OSS ボリュームを使用するポッドは、データの読み取りまたは書き込み時に相互に影響を与えません。

ossfs をコンテナー化した後、ossfs プロセスは csi-fuse-ossfs-* ポッド内の kube-system または ack-csi-fuse 名前空間で実行されます。OSS ボリュームが複数のポッドにマウントされているシナリオでは、排他モードでは大量の ossfs ポッドが起動されます。その結果、Elastic Network Interface（ENI）が不足します。そのため、ossfs をコンテナー化した後は、共有モードを使用して OSS ボリュームをマウントしてください。これにより、ノード上の同じ OSS ボリュームを使用するポッドが、同じマウントターゲットを共有できます。つまり、csi-fuse-ossfs-* ポッド内の ossfs プロセスは 1 つだけ起動されます。

ソリューション

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

OSS ボリュームが複数のポッドによって共有されている場合、 ossfs プロセスを再起動するにはどうすればよいですか？

問題

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

原因

• ossfs は認証構成を自動的に更新できません。変更された認証構成を更新するには、ossfs プロセス（ossfs のコンテナー化後、kube-system または ack-csi-fuse 名前空間の csi-fuse-ossfs-* ポッド）とアプリケーション ポッドを再起動する必要があります。これにより、ビジネスの中断が発生します。そのため、CSI はデフォルトでは、実行中の ossfs プロセスを再起動して構成を更新しません。 OSS ボリュームを再マウントするように ossfs を手動で構成する必要があります。

• 通常、ossfs のデプロイと削除は CSI によって処理されます。 ossfs プロセスを実行しているポッドを手動で削除しても、CSI デプロイプロセスはトリガーされません。

ソリューション

使用している CSI バージョンがコンテナ化されていない場合、または排他モードを使用して OSS ボリュームをマウントする場合は、アプリケーション ポッドを直接再起動できます。 コンテナ化された CSI バージョンでは、デフォルトで共有モードを使用して OSS ボリュームがマウントされます。 つまり、ノード上の同じ OSS ボリュームを使用するポッドは、同じ ossfs プロセスを共有します。

1. FUSE ポッドを使用するアプリケーション ポッドを確認します。

   1. 次のコマンドを実行して、csi-fuse-ossfs-* ポッドを確認します。

      <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 ボリュームを使用するすべてのポッドを確認します。

      <ns> を名前空間名に、<pvc-name> を PVC 名に置き換えます。

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

      予想される出力 (User 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 プロセスと同じノードで実行されているポッドをクエリします。

      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 を使用して、アプリケーション ポッド (前の例では oss-static-94849f647-4**** と oss-static-94849f647-6****) を削除します。 OSS ボリュームがアプリケーション ポッドにマウントされていない場合、csi-fuse-ossfs-xxxx ポッドは削除されます。 アプリケーション ポッドが再作成されると、csi-fuse-ossfs-yyyy ポッドで実行されている ossfs プロセスによって、新しい PV 構成に基づいて OSS ボリュームがマウントされます。

   Deployment、StatefulSet、または DaemonSet によって管理されるポッドを削除すると、すぐに再起動がトリガーされます。 すべてのアプリケーション ポッドを同時に削除できない場合、またはポッドが読み取りおよび書き込みエラーを許容できる場合は、次の手順を実行します。

   • CSI バージョンが 1.30.4 より前の場合は、csi-fuse-ossfs-xxxx ポッドを直接削除できます。 この場合、アプリケーション ポッドが 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 を直接削除すると、アプリケーション ポッドが OSS ボリュームの読み取りまたは書き込みを行うときに disconnected error が返されます。

   アプリケーション ポッドを 1 つずつ再起動します。 再起動されたアプリケーション ポッドは、CSI によって作成された csi-fuse-ossfs-yyyy ポッドを介して OSS ボリュームの読み取りと書き込みを行います。

OSS ボリュームのアクセスレコードをどのように表示しますか?

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

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

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

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

4. リアルタイムクエリ タブで、クエリ構文 と 分析構文 に基づいてクエリ文と分析文を入力し、ログフィールド を分析します。 user_agent フィールドと client_ip フィールドを使用して、ログが ACK によって生成されたかどうかを確認します。

   1. ACK によって送信された OSS リクエストを見つけるには、user_agent フィールドを選択します。 user_agent に ossfs が含まれているリクエストは、ACK によって送信された OSS リクエストです。

      重要

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

      • ossfs を使用して ECS インスタンスに OSS ボリュームをマウントした場合、関連するログデータも記録されます。

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

   次の図は、上記のフィールドに基づいてフィルタリングされたログデータを示しています。

クエリ対象のフィールド

subPath または subPathExpr を使用して OSS ボリュームをマウントするときに例外が発生した場合はどうすればよいですか？

問題

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

• マウントの失敗: マウントされる OSS ボリュームが関連付けられているポッドは、ポッドの作成後、CreateContainerConfigError 状態のままです。さらに、次のイベントが生成されます。

  Warning  Failed          10s (x8 over 97s)  kubelet            Error: failed to create subPath directory for volumeMount "pvc-oss" of container "nginx"  // エラー: コンテナー "nginx" の volumeMount "pvc-oss" の subPath ディレクトリの作成に失敗しました

• 読み取りおよび書き込みの例外: アプリケーション ポッドが OSS ボリュームを読み書きするときに、Operation not permitted または Permission denied エラーが返されます。

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

原因

以下を想定します。

PV 関連の構成:

...
    volumeAttributes:
      bucket: bucket-name  # バケット名
      path: /path # パス
      ...

Pod 関連の構成:

...
       volumeMounts:
      - mountPath: /path/in/container  # コンテナ内のパス
        name: oss-pvc
        subPath: subpath/in/oss # OSS 内のサブパス
      ...

この場合、OSS サーバー上の subPath は、バケット内の /path/subpath/in/oss/ パスに設定されます。

• 原因 1: マウントターゲット /path/subpath/in/oss/ が OSS サーバー上に存在せず、ユーザーまたはロールが OSS ボリュームに対する PutObject 権限を持っていない。たとえば、読み取り専用シナリオでは、OSS ReadOnly 権限のみが付与されます。

  kubelet は OSS サーバー上にマウントターゲット /path/subpath/in/oss/ を作成しようとしますが、権限が不十分なため失敗します。

• 原因 2: ルート以外のユーザーによって実行されるアプリケーションコンテナーは、/path/subpath/in/oss/ パスのファイルに必要な権限を持っていません。デフォルトの権限は 640 です。subPath を使用して OSS ボリュームをマウントする場合、OSS サーバー上のマウントターゲットは PV で定義されたパス（上記の例では /path）であり、/path/subpath/in/oss/ ではありません。 allow_other または mp_umask 設定は、/path パスにのみ有効です。/path/subpath/in/oss/ subPath のデフォルトの権限は 640 のままです。

• 原因 3: OSS サーバー上のマウントターゲット /path/subpath/in/oss/ が削除されます。その結果、kubelet は subPath のアンマウントに失敗します。

ソリューション

原因 1 の解決策:

• kubelet 用に OSS サーバー上に /path/subpath/in/oss/ subPath を作成します。

• 多数のパスを作成する必要があり、OSS ボリュームをマウントするときに一部のパスが存在しない場合は、ユーザーまたはロールに putObject 権限を付与できます。 このケースは、subPathExpr を使用して OSS ボリュームをマウントする場合に発生します。

原因 2 の解決策: umask パラメーターを使用して、subPath のデフォルト権限を変更します。たとえば、-o umask=000 を追加して、デフォルト権限を 777 に設定します。

原因 3 の解決策: スタティックプロビジョニングされた OSS ボリュームをポッドからアンマウントできない場合、ポッドが Terminating 状態のままになるのはなぜですか。 の原因 2 の解決策を参照してください。

ボリュームの実際の容量が容量設定を超えた場合、OSS ボリュームを拡張する必要がありますか？

OSS は、バケットまたは subPath のサイズを制限したり、容量制限を設けたりしません。そのため、PV の .spec.capacity 設定と、PVC の .spec.resources.requests.storage 設定は無視されます。 PV と PVC の容量値が同じであることを確認するだけで十分です。

ボリュームの実際の容量が容量設定を超えていても、ボリュームは通常どおり使用できます。ボリュームの拡張は必要ありません。