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

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

問題

OSSボリュームのマウントには長い時間がかかります。

発生原因

次の条件を満たす場合、ボリュームのマウント時にkubeletがchmodまたはchown操作を実行するため、時間の消費が増加します。

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

• securityContext.fsgroupパラメーターは、アプリケーションテンプレートで設定されます。

ソリューション

• アプリケーションテンプレートでsecurityContext.fsgroupパラメーターが設定されている場合、securityContextセクションのfsgroupパラメーターを削除します。

• マウントされたパスのファイルのユーザーID (UID) とモードを設定する場合は、OSSバケットをElastic Compute Service (ECS) インスタンスに手動でマウントできます。 その後、CLIを使用してchownおよびchmod操作を実行し、Container Storage Interface (CSI) プラグインを使用してOSSボリュームをプロビジョニングできます。 CSIプラグインを使用してOSSボリュームをプロビジョニングする方法の詳細については、「静的にプロビジョニングされたOSSボリュームのマウント」をご参照ください。

• 上記の方法とは別に、Kubernetes 1.20以降を実行するクラスターの場合、fsGroupChangePolicyパラメーターをOnRootMismatchに設定できます。 このように、chmodまたはchown操作は、システムが初めてポッドを起動したときにのみ実行されます。 その結果、最初の起動時にOSSボリュームをマウントするのに時間がかかります。 最初の起動が完了した後にOSSボリュームをマウントすると、問題は発生しません。 fsGroupChangePolicyの詳細については、「ポッドまたはコンテナーのセキュリティコンテキストの設定」をご参照ください。

• ossfsによってマウントされたOSSボリュームのPVCは記述しないことを推奨します。 これらのPVCはデフォルトで読み取り専用です。

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

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

シナリオ1: マウントターゲットにアクセスすると、権限拒否エラーが発生します。

発生原因

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

ソリューション

ルートパスの権限を変更する設定を追加します。

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

発生原因

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

ソリューション

chmodコマンドをrootユーザーとして実行し、目的のファイルのアクセス許可を変更します。 次の設定を追加して、マウント対象のサブパスおよびファイルに対する権限を変更することもできます。

umask: マウントターゲット内のsubPathとファイルのumask。 umaskパラメーターは、mp_umaskと同じ方法で設定できます。 umaskパラメーターはallow_otherパラメーターに依存しません。

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

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

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

シナリオ3: 他のコンテナプロセスがossfsで作成されたファイルの読み取りまたは書き込みを行う場合、システムは不十分な権限を要求します

発生原因

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

ソリューション

ファイルに対する権限を統計します。 システムが不十分な権限を要求した場合は、chmodコマンドを実行して、rootユーザーとしてファイルの権限を変更します。

シナリオ4: シークレットに格納されているAccessKeyペアは、nodePublishSecretRef元のAccessKeyペアは、AccessKeyペアのローテーションのために取り消されます。 シークレットの更新されたAccessKeyペアは有効になりません。

発生原因

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

ソリューション

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

シナリオ5: ハードリンクを作成すると操作が許可されないエラーが発生します

発生原因

OSSボリュームはハードリンクをサポートしていません。 以前のバージョンのCSIでは、ハードリンクを作成するとOperation not allowedエラーが返されます。

ソリューション

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

シナリオ6: subPathまたはsubPathExprを使用してOSSボリュームをマウントすると、システムが不十分な読み取りまたは書き込み権限を要求します

発生原因

非rootユーザーとして実行されるコンテナープロセスには、/path/subpath/in/oss/ path内のファイルに対する権限がありません。 パスに対するデフォルトの権限は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コンソールに表示されるサブパスは、OSSサーバーに存在しない場合があります。 ossutilまたはOSS APIを使用して、サブパスを確認します。 たとえば、/a/b/c/ パスを作成した場合、/a/b/c/ パスオブジェクトは作成されますが、/a/ または /a/b/ パスオブジェクトは存在しません。 /a/* オブジェクトをアップロードすると、/a/bまたは /a/cオブジェクトが見つかりますが、/a/ パスオブジェクトは存在しません。

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

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

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

• 原因5: イベントに共有ライブラリの読み込み中: xxxxx: cannot open shared object file: No such file or directoryというメッセージが含まれている場合、ossfsは現在のCSIバージョンのノードで実行されますが、ossfsに必要な一部の動的ライブラリがオペレーティングシステムにないため、マウントに失敗しました。 考えられる原因：

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

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

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

  • ossfsに必要なFUSE、cURL、xml2などの動的ライブラリは、必要なオペレーティングシステムを実行するノードから削除されるか、既定のOpenSSLバージョンが変更されます。

• 原因6: バケットにミラーリングベースのback-to-originルールが設定されていますが、マウントパスがオリジンから同期されていません。

• 原因7: 静的Webサイトホスティングがバケットに設定されています。 ossfsがOSSサーバー上のマウントターゲットをチェックすると、index.htmlファイルが返されます。

ソリューション

• 原因1:

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

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

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

  2. 1.91以降のバージョンのossfsでは、存在しないマウントターゲットを指定できます。 したがって、この問題を解決するためにossfsを更新することもできます。 詳細については、「ossfs 1.91以降の新機能およびストレステスト」をご参照ください。

• 原因2の解決策:

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

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

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

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

  • 説明

    RRSA機能は、Kubernetes 1.26を実行するACKクラスターのみをサポートします。 RRSA機能をサポートするACKクラスターには、ACK Basicクラスター、ACK Proクラスター、ACK Serverless Basicクラスター、およびACK Serverless Proクラスターがあります。 クラスターが使用するCSIコンポーネントのバージョンは1.30.4以降である必要があります。 バージョン1.30.4より前にRRSA機能を使用した場合は、RAMロールにポリシーをアタッチする必要があります。 詳細については、「 [製品の変更] ossfsバージョンのアップグレードとCSIのマウントプロセスの最適化」をご参照ください。

• 原因3:

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

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

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

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

  3. csi-provisionerとcsi-pluginの両方がバージョン1.30.4以降に更新されていることを確認してください。 次に、ポッドを再起動して再マウントをトリガーし、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を実行します。

    • ossfsのインストールパスを照会するコマンドを実行します。 デフォルトのパスは /usr/local/bin/ossfsです。

      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を引き起こす:

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

• 原因7:

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

静的にプロビジョニングされたOSSボリュームへのアクセスに失敗した場合はどうすればよいですか。

問題

静的にプロビジョニングされたOSSボリュームへのアクセスに失敗しました。

発生原因

静的にプロビジョニングされたOSSボリュームをマウントするときに、AccessKeyペアを指定しませんでした。

ソリューション

静的にプロビジョニングされたOSSボリュームの設定でAccessKeyペアを指定します。 詳細については、「静的にプロビジョニングされたOSSボリュームのマウント」をご参照ください。

静的にプロビジョニングされたOSSボリュームの読み取り速度が遅い場合はどうすればよいですか?

問題

静的にプロビジョニングされたOSSボリュームの読み取り速度は遅いです。

発生原因

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

• 原因2: OSSがバージョン管理を有効にすると、バケットに多数のdeleteタグが生成され、listObjectsV1のパフォーマンスが低下します。

• 原因3: OSSサーバーは、Storage ClassをStandard以外のクラスに設定します。 これらのストレージクラスのバケットへのアクセスは遅いです。

ソリューション

原因1:

OSSボリュームをコンテナーにマウントする場合、OSSボリュームのアクセスモードを読み取り専用に設定することを推奨します。 OSSバケットに多数のファイルが格納されている場合は、ファイルシステムを使用してファイルにアクセスするのではなく、OSS SDKまたはCLIを使用してバケット内のファイルにアクセスすることを推奨します。 詳細については、「SDKデモの概要」をご参照ください。

原因2の解決策:

1. CSIプラグインがv1.26.6に更新されると、ossfsではlistObjectsV2を使用してバケットにアクセスできます。

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

原因3:

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

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

問題

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

発生原因

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

ソリューション

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

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

問題

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

発生原因

原因1: OSSサーバー上のパスのコンテンツタイプが、text/htmlやimage/jpegなどのデフォルトのapplication/octet-streamタイプではないか、パスオブジェクトのサイズが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/ pathオブジェクトの場合、オブジェクト名として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ボリュームで有効になります。 詳細については、「FAQ」をご参照ください。

   • クラスターレベルの設定: コンテンツタイプは、クラスター内の新しくマウントされたすべての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" をConfigMapに追加します。

        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) またはデフォルト以外のServiceAccountsを使用することはできません。

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 # Specify the name of the 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>" #The roleName parameter becomes invalid after roleArn and oidcProviderArn are configured. 
      serviceAccountName: "csi-fuse-<service-account-name>" 

ハードリンクを作成するときに「操作がサポートされていません」または「操作が許可されていません」というエラーが発生した場合はどうすればよいですか?

問題

ハードリンクを作成すると、[Operation not supported] または [Operation not permitted] エラーが発生します。

発生原因

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

解決策

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

静的にプロビジョニングされたOSSボリュームをポッドからアンマウントできなかったときに、ポッドが終了状態のままである場合はどうすればよいですか。

発行

静的にプロビジョニングされたOSSボリュームをポッドからアンマウントできず、ポッドは終了状態のままです。

原因

システムがポッドを削除するときにポッドが [終了] 状態のままである場合は、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. 終了状態のポッドをホストするノードにログインします。

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. 終了状態のポッドをホストするノードにログインし、次のコマンドを実行してポッドのマウントターゲットを照会します。

      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/"

"connection timed out" ネットワークエラーを処理するにはどうすればよいですか?

問題

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

発生原因

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

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

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

ソリューション

• PVを再作成し、バケットの外部エンドポイントを選択します。

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

"StatusCode=403" アクセス許可エラーを処理するにはどうすればよいですか?

問題

サービスが返されたエラー: 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="指定したOSS Access Key Idはレコードに存在しません。" エラーは、AccessKeyペアが存在しないことを示しています。

• StatusCode=403、ErrorCode=SignatureDoesNotMatch、ErrorMessage="計算したリクエスト署名は、指定した署名と一致しません。 キーと署名方法を確認してください。エラーは、AccessKeyペアにスペルエラーが含まれている可能性があることを示します。

ソリューション

AccessKeyペアが存在し、スペルエラーが含まれておらず、バケットの読み取り権限があることを確認してください。

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

問題

サービスが返されたエラー: StatusCode=404エラーが発生します。

発生原因

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

• StatusCode=404、ErrorCode=NoSuchBucket、ErrorMessage="指定されたバケットは存在しません。" エラーは、バケットが存在しないことを示します。

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

  重要

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

ソリューション

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

他のOSSステータスコードまたはエラーコードが返された場合はどうすればよいですか?

問題

サービスが返されたエラー: StatusCode=xxxエラーが発生します。

発生原因

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

ソリューション

OSSが他のステータスコードまたはエラーコードを返す場合は、「HTTPステータスコード」をご参照ください。

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

発行

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

原因

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

ossfsがコンテナ化された後、ossfsプロセスは、kube-systemまたはack-csi-fuse名前空間のcsi-fuse-ossfs-* ポッドで実行されます。 OSSボリュームが複数のポッドにマウントされているシナリオでは、排他モードでは多数のossfsポッドが起動します。 その結果、elastic network Interface (ENI) が不十分になります。 したがって、ossfsをコンテナ化した後、共有モードを使用してOSSボリュームをマウントします。 これにより、ノード上で同じOSSボリュームを使用するポッドが同じマウントターゲットを共有できるようになります。 つまり、csi-fuse-ossfs-* ポッド内の1つのossfsプロセスのみが起動されます。

ソリューション

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

ossfsを再起動する方法プロセスOSSボリュームが複数のポッドで共有されている場合?

発行

認証情報または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 po d -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>

      期待される出力 (ユーザーバイを含む):

      使用される

      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ポッドは削除されます。 アプリケーションポッドが再作成された後、OSSボリュームは、csi-fuse-ossfs-yyyyポッドで実行されるossfsプロセスによって新しいPV構成に基づいてマウントされます。

   Deployment、StatefulSet、またはDaemonSetによって管理されているポッドを削除すると、すぐに再起動がトリガーされます。 すべてのアプリケーションポッドを同時に削除できない場合、またはポッドが読み書きの失敗を許容できる場合:

   • CSIバージョンが1.30.4より前の場合は、csi-fuse-ossfs-xxxxポッドを直接削除できます。 この場合、アプリケーションポッドがOSSボリュームを読み書きすると、切断エラーが返されます。

   • 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ボリュームを読み書きするときに切断エラーが返されます。

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

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

OSSコンソールでOSS操作のレコードを表示できます。 OSSでログクエリ機能が有効になっていることを確認します。 詳細については、「リアルタイムログクエリの有効化」をご参照ください。

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

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

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

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

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

      重要

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

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

   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"

• 読み書き例外: アプリケーションポッドがOSSボリュームを読み書きすると、操作が許可されていませんまたは許可が拒否されましたエラーが返されます。

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

発生原因

仮定：

PV関連の設定:

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

ポッド関連の設定:

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

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

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

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

• 原因2: 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です。

• 原因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ボリュームのマウント解除に失敗した場合、ポッドが終了状態のままである場合はどうすればよいですか。

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

OSSは、バケットまたはサブパスのサイズを制限しません。 したがって、pv.spec.ca pacityおよびpvc.spec.resources.requests.storageの設定は有効になりません。 PVとPVCの容量値が同じであることを確認するだけで済みます。

ボリュームの実際の容量が容量設定を超えた場合、ボリュームを通常どおり使用し続けることができます。 ボリューム拡張は必要ありません。