このトピックでは、Object Storage Service (OSS) ボリュームに関するよくある質問に対する回答を提供します。
カテゴリ | 問題 |
OSSボリュームのマウントに関するFAQ | |
OSSボリュームの使用に関するFAQ | |
OSSボリュームのマウント解除に関するFAQ | 静的にプロビジョニングされたOSSボリュームをポッドからアンマウントできなかったときに、ポッドが終了状態のままである場合はどうすればよいですか。 |
ACKコンソールでの検出失敗に関するFAQ | |
その他 |
OSSボリュームのマウントに長い時間がかかるのはなぜですか?
問題
OSSボリュームのマウントには長い時間がかかります。
発生原因
次の条件を満たす場合、ボリュームのマウント時にkubeletがchmodまたはchown操作を実行するため、時間の消費が増加します。
永続ボリューム (PV) および永続ボリューム要求 (PVC) テンプレートでは、AccessModesパラメーターがReadWriteOnceに設定されます。
securityContext.fsgroupパラメーターは、アプリケーションテンプレートで設定されます。
ソリューション
ossfsを使用して、パラメーターを使用してマウントポイント下のファイルのユーザーID (UID) 、グループID (GID) 、およびファイルモードを変更できます。
パラメーター
説明
uid
サブパスの所有者とマウントターゲットのファイルのUID。
gid
サブパスの所有者とマウントターゲットのファイルのGID。
umask
マウントターゲット内のサブパスとファイルのumask。 umaskパラメーターは、mp_umaskと同じ方法で設定できます。 umaskパラメーターはallow_otherパラメーターに依存しません。
設定後、securityContextセクションのfsgroupパラメーターを削除します。
上記の方法とは別に、Kubernetes 1.20以降を実行するクラスターの場合、fsGroupChangePolicyパラメーターをOnRootMismatchに設定できます。 このように、
chmod
またはchown
操作は、システムが初めてポッドを起動したときにのみ実行されます。 その結果、最初の起動時にOSSボリュームをマウントするのに時間がかかります。 最初の起動が完了した後にOSSボリュームをマウントすると、問題は発生しません。 fsGroupChangePolicyの詳細については、「ポッドまたはコンテナーのセキュリティコンテキストの構成」をご参照ください。
OSSボリュームのマウントに関連する権限を管理するにはどうすればよいですか。
次のシナリオでは、[権限拒否] エラーが表示されます。
シナリオ1: マウントターゲットにアクセスすると、権限拒否エラーが発生します。
発生原因
デフォルトでは、LinuxのルートユーザーがOSSボリュームのマウントに使用されます。 rootユーザーに700権限があります。 コンテナープロセスがroot以外のユーザーとしてOSSボリュームにアクセスすると、権限が不足しているためにエラーが表示されます。
ソリューション
ルートパスの権限を変更する設定を追加します。
パラメーター | 説明 |
allow_other | マウントターゲットの777権限を設定します。 |
mp_umask | マウントターゲットのumaskを設定します。 このパラメーターは、
|
シナリオ2: ossutil、OSSコンソール、またはSDKを使用してファイルをアップロードすると、権限拒否エラーが発生します。
発生原因
デフォルトでは、ossfsはossfs以外のメソッドを使用してアップロードされたファイルに対する640権限を持ちます。 コンテナープロセスがroot以外のユーザーとしてOSSボリュームにアクセスすると、権限が不足しているためにエラーが表示されます。
ソリューション
chmodコマンドをrootユーザーとして実行し、目的のファイルのアクセス許可を変更します。 次の設定を追加して、マウント対象のサブパスおよびファイルに対する権限を変更することもできます。
パラメーター | 説明 |
umask | マウントターゲット内のサブパスとファイルの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ユーザーとしてファイルの権限を変更します。
上記のソリューションでは、現在のコンテナープロセスのユーザーにパスまたはファイルに対する十分な権限がないという問題が解決されます。 この問題を解決するために、subPathの所有者とossfsのマウントターゲットのファイルを変更することもできます。
コンテナイメージのビルド時にコンテナプロセスのユーザーを指定した場合、またはアプリケーションデプロイメントのsecurityContext.ru nAsUser
およびsecurityContext.ru nAsGroup
フィールドを空のままにした場合、コンテナプロセスはroot以外のユーザーとして実行されます。
ossfsのマウント対象のsubPathおよびファイルのUIDおよびGIDを、コンテナープロセスを実行するユーザーのUIDおよびGIDに変更するために、次の設定を追加します。
パラメーター | 説明 |
uid | サブパスの所有者とマウントターゲットのファイルのUID。 |
gid | サブパスの所有者とマウントターゲットのファイルのGID。 |
たとえば、コンテナプロセスの対応するIDがuid=1000(biodocker)
、gid=1001(biodocker)
、groups=1001(biodocker)
の場合、-o uid=1000
、-o gid=1001
と設定します。
シナリオ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: AccessKeyまたはRRSAで使用されるロールがsubPathスコープの権限でのみ許可されている場合、OSSバケットのsubPathのマウントが失敗します。 ossfsポッドログには、
403 AccessDenied
と404 NoSuchKey
の両方のエラーが表示されます。ossfsは起動時に、OSSバケットの権限検証と接続チェックを自動的に実行します。 OSSサブパスであるマウントターゲットの場合、ossfsバージョン1.91以降は、まずバケットのルートディレクトリへのアクセスを試みます。 この試行が失敗すると、サブパスへのアクセスが再試行されます。 バケット全体に対する読み取り専用権限で、ossfsの新しいバージョンでは、OSSバケットに存在しないサブパスのマウントが許可されます。
したがって、AccessKeyまたはRRSAによって使用されるロールがsubPathスコープの権限のみで許可されている場合、初期検証中に
403 AccessDenied
エラーが発生します。 subPathが存在しない場合、404 NoSuchKey
エラーが発生し、ossfsが異常終了し、マウントが失敗します。原因7: バケットにミラーリングベースのback-to-originルールが設定されていますが、マウントパスがオリジンから同期されていません。
原因8: 静的Webサイトホスティングがバケットに設定されています。 ossfsがOSSサーバー上のマウントターゲットをチェックすると、index.htmlファイルが返されます。
ソリューション
原因1:
OSSサーバーにsubPathが存在するかどうかを確認します。
PVのマウント先が
sub/path/
であるとします。 stat (クエリバケットとオブジェクト情報) を実行してobjectname
がsub/path/
のオブジェクトをクエリするか、openapi HeadObjectを実行してkey
がsub/path/
のオブジェクトをクエリします。 404が返された場合、サブパスはOSSサーバーに存在しません。ossutil、OSS SDK、またはOSSコンソールを使用して、欠落しているバケットまたはsubPathを作成し、バケットを再度マウントできます。
1.91以降のバージョンのossfsでは、存在しないマウントターゲットを指定できます。 したがって、この問題を解決するためにossfsを更新することもできます。 詳細については、「ossfs 1.91以降の新機能およびストレステスト」をご参照ください。 ossfsの更新後にこの問題が解決しない場合は、この質問の原因6をご参照ください。
原因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ロールにポリシーをアタッチする必要があります。 詳細については、「 [製品の変更] CSIのossfsバージョンのアップグレードとマウントプロセスの最適化」をご参照ください。
原因3:
次のコマンドを実行して、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>
ポッドが存在するが異常な状態にある場合は、トラブルシューティングを行い、再起動する前にポッドが実行中の状態であることを確認して、再マウントをトリガーしてください。 ポッドが存在しない場合は、次の手順に従ってトラブルシューティングを行います。
(オプション) 監査ログおよびその他の関連ソースを確認して、ポッドが誤って削除されたかどうかを確認します。 誤って削除する一般的な原因には、スクリプトのクリーンアップ、ノードのドレイン、ノードの自動修復などがあります。 この問題が再発しないように、適切な調整を行うことを推奨します。
csi-provisionerとcsi-pluginの両方がバージョン1.30.4以降に更新されていることを確認してください。 次に、ポッドを再起動して再マウントをトリガーし、ossfsを実行しているポッドが適切なプロセスで作成されていることを確認します。
原因4:
csi-pluginをv1.26.2以降に更新することを推奨します。 新しく追加されたノードの初期化中にossfsインストールが失敗する問題は、これらのバージョンで修正されています。
次のコマンドを実行して、ノードでcsi-pluginを再起動し、csi-pluginポッドが通常どおりに実行されるかどうかを確認します。 次のコードでは、
csi-plugin-****
はcsi-pluginのポッドを指定します。kubectl -n kube-system delete pod csi-plugin-****
コンポーネントを更新または再起動しても問題が解決しない場合は、ノードにログインして次のコマンドを実行します。
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
です。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を引き起こす:
この質問の [解決策の原因1] を参照し、指定されたサブパスがバケットに存在するかどうかを確認します。
長期間にわたってサブパスをマウントする操作が必要な場合は、バケット全体にアクセス許可の範囲を拡張することを推奨します。
原因7:
OSSボリュームをマウントする前に、オリジンからデータを同期します。 詳細については、「Back-to-Origin」をご参照ください。
原因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 # The subpath value is the parent path of the a.txt and b.txt.
url: "oss-cn-hangzhou.aliyuncs.com"
対応するPVCを作成した後、次のYAMLテンプレートを使用して、ポッドにマウントされるPVCのvolumeMounts
を設定します。
volumeMounts:
- mountPath: /path/to/file # The path to which the specific file from OSS is mounted. The OSS path bucket:/subpath is being mapped to the pod's internal mount path /path/to/file.
name: oss-pvc # The same as the name in the volume.
subPath: a.txt # You can also use b.txt for the other file. This parameter is the relative path to the file in bucket:/subpath.
基本的に、マウント後、ポッド内の /path/to/file/a.txt
にアクセスすると、bucket:/subpath/a.txt
にある外部OSSファイルが参照されます。
OSSボリュームをマウントする方法の詳細については、「静的にプロビジョニングされたOSSボリュームのマウント」をご参照ください。
上記の例では、ノード上のossfsのマウントポイントは、OSSパス
bucket:/subpath
に直接マップされます。 ファイルスキャンやsubPath
を使用せずにマウントされたポッドなどのノード上のプロセスは、bucket:/subpath
内のコンテンツへのフルアクセス権を保持します。root以外のユーザーが実行するコンテナーの場合は、
subPath
の権限設定に注意することをお勧めします。 詳細については、「」をご参照ください。subPathまたはsubPathExprを使用して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の解決策:
CSIプラグインがv1.26.6に更新されると、ossfsではlistObjectsV2を使用してバケットにアクセスできます。
静的にプロビジョニングされた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です。
上記の条件が満たされない場合は、次の手順を実行します。
GetObjectまたはossutilを使用してオブジェクトを取得し、メタデータを確認します。 オブジェクトのメタデータが要件を満たしている場合、またはメタデータを確認できない場合は、オブジェクトをバックアップすることを推奨します。 たとえば、オブジェクトの名前を変更してOSSにアップロードします。
xx/
pathオブジェクトの場合、オブジェクト名としてxx
を使用しないでください。DeleteObjectまたはrmを使用して元のパスオブジェクトを削除し、ossfsがパスオブジェクトを正常に表示するかどうかを確認します。
原因2の解決策:
ソリューションの手順を実行して1が発生した後も問題が解決しない場合は、OSSボリュームをマウントするときに、静的にプロビジョニングされたOSSボリュームに対応するPVのotherOpts
フィールドに -o complement_stat
を追加します。
CSIプラグインv1.26.6以降のバージョンでは、この機能はデフォルトで有効になっています。 CSIプラグインをv1.26.6以降に更新してから、アプリケーションポッドを再起動し、OSSボリュームを再マウントして問題を解決できます。
OSSサーバーが予期しない多数のリクエストを識別した場合はどうすればよいですか。
問題
OSSボリュームをコンテナにマウントすると、OSSサーバーは予期しない多数のリクエストを識別します。
発生原因
ossfsがOSSバケットをマウントすると、マウントターゲットがノードに生成されます。 ECSノード上の他のプロセスがマウントターゲットをスキャンすると、リクエストがOSSサーバーに送信されます。 リクエスト数が上限を超えると料金が発生します。
ソリューション
ActionTrailを使用して、リクエストを生成するプロセスを追跡し、問題を修正します。 ノードで次の操作を実行できます。
次のコマンドを実行してauditdをインストールして起動します。
sudo yum install auditd sudo service auditd start
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
次のコマンドを実行して監査ログを印刷し、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) ---
リクエストが非ビジネスプロセスから送信されているかどうかを確認し、問題を修正します。
たとえば、監査ログは、updatedbがすべてのマウントターゲットをスキャンすることを示します。 この場合、
/etc/updatedb.conf
を変更してスキップします。 これを行うには、次の手順を実行します。RUNEFS=
をfuse.ossfs
に設定します。PRUNEPATHS=
をマウントターゲットに設定します。
OSSボリューム内のオブジェクトのメタデータのコンテンツタイプがapplication/octet-streamの場合はどうすればよいですか?
発行
OSSボリューム内のオブジェクトのメタデータのコンテンツタイプは、application/octet-streamです。 したがって、ブラウザまたは他のクライアントは、オブジェクトを認識または処理することができない。
原因
ossfsのオブジェクトのデフォルトのコンテンツタイプはバイナリストリームです。
/etc/mime.typesファイルを変更してコンテンツタイプを指定した後、変更は有効になりません。
ソリューション
CSI 1.26.6および1.28.1には、コンテンツタイプ設定で互換性の問題があります。 上記のバージョンを使用する場合は、CSIを最新バージョンに更新します。 詳細については、「 [コンポーネント通知] csi-plugin 1.26.6および1.28.1、およびcsi-provisioner 1.26.6および1.28.1の互換性のない構成」をご参照ください。
mailcap
またはmime-support
を使用してノードで/etc/mime.types
ファイルを生成し、コンテンツタイプを指定した場合は、CSIを更新し、OSSボリュームを再マウントします。コンテンツタイプを指定しない場合は、次の方法でコンテンツタイプを指定します。
ノードレベル設定: ノード上に
/etc/mime.types
ファイルを生成します。 コンテンツタイプは、ノードにマウントされているすべてのOSSボリュームで有効になります。 詳細については、「FAQ」をご参照ください。クラスターレベルの設定: コンテンツタイプは、クラスター内の新しくマウントされたすべてのOSSボリュームに適用されます。
/etc/mime.types
ファイルの内容が、mailcap
によって生成されたデフォルトの内容と同じであることを確認します。次のコマンドを実行して、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
変更を有効にするためにcsi-pluginを再起動します。 再起動は、すでにマウントされているボリュームには影響しません。
kubectl -n kube-system delete pod -l app=csi-plugin
目的のOSSボリュームを再マウントします。
RRSA認証で指定されたARNまたはServiceAccountを使用するにはどうすればよいですか。
OSSボリュームにRRSA認証を使用する場合、サードパーティのOpenID Connect IDプロバイダー (OIDC IdP) のAmazonリソース名 (ARN) またはデフォルト以外のServiceAccountsを使用することはできません。
CSIがデフォルトのロールARNとOIDC IdP ARNを取得できるようにするには、PVのroleNameパラメーターを目的のRAMロールに設定します。 RRSA認証をカスタマイズするには、次のようにPV設定を変更します。
roleArn
とoidcProviderArn
の両方を設定します。 上記のパラメーターを設定した後は、roleName
を設定する必要はありません。
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>"
パラメーター | 説明 |
oidcProviderArn | OIDC IdPの作成後にOIDC IdP ARNを取得します。 詳細については、「OIDC IdPの管理」をご参照ください。 |
roleArn | 前のOIDC IdPを信頼済みエンティティとするRAMロールが作成された後、ロールARNを取得します。 詳細については、「手順2: Alibaba CloudでのOIDC IdPのRAMロールの作成」をご参照ください。 |
serviceAccountName | 必要に応じて、 ossfsポッドで使用するServiceAccountを指定します。 ポッドが作成されていることを確認します。 このパラメーターを空のままにすると、CSIが管理するデフォルトのServiceAccountが使用されます。 重要 ServiceAccountの名前はcsi-fuse-で始まる必要があります。 |
ハードリンクを作成するときに「操作がサポートされていません」または「操作が許可されていません」というエラーが発生した場合はどうすればよいですか?
問題
ハードリンクを作成すると、[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:
クラスターで次のコマンドを実行して、ポッドUIDを照会します。
<ns-name> と <pod-name> を実際の値に置き換えます。
kubectl -n <ns-name> get pod <pod-name> -ogo-template --template='{{.metadata.uid}}'
期待される出力:
5fe0408b-e34a-497f-a302-f77049****
終了状態のポッドをホストするノードにログインします。
次のコマンドを実行して、プロセスがマウントターゲットを占有しているかどうかを確認します。
lsof /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount/
はいの場合、プロセスを確認して終了します。
原因2の解決策:
OSSコンソールにログインします。
OSSバケットまたはパスが削除されているかどうかを確認します。 subPathを使用してOSSボリュームをマウントする場合は、subPathが削除されているかどうかも確認する必要があります。
パスが削除されたためにマウント解除に失敗した場合は、次の手順を実行します。
クラスターで次のコマンドを実行して、ポッドUIDを照会します。
<ns-name> と <pod-name> を実際の値に置き換えます。
kubectl -n <ns-name> get pod <pod-name> -ogo-template --template='{{.metadata.uid}}'
期待される出力:
5fe0408b-e34a-497f-a302-f77049****
終了状態のポッドをホストするノードにログインし、次のコマンドを実行してポッドのマウントターゲットを照会します。
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
の間のパスは、ノード上の実際のマウントターゲットです。マウントターゲットを手動でアンマウントします。
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
kubeletが再試行するのを待つか、
-- force
を実行してポッドを削除します。
問題が解決しない場合は、
チケットを起票してサポートセンターにお問い合わせくださいしてサポートセンターにお問い合わせください。
ACKコンソールの検出タスクが長時間停止した場合、検出タスクが失敗してもエラーメッセージが表示されない場合、またはシステムに「不明なエラー」が表示された場合はどうすればよいですか?
問題
検出タスクが長時間スタックしたり、検出タスクが失敗したり、エラーメッセージが表示されたり、システムが「不明なエラー」を表示したりしますか?
発生原因
検出タスクが長時間停止した場合、通常はネットワークの問題が原因です。 他の不明な問題が原因である場合は、ログを印刷するか、ossutilを使用して原因を手動で特定します。
ソリューション
ログとossutilを使用して原因を特定できます。
ログを使用して原因を特定する
次のコマンドを実行して、検出タスクを実行するポッドを見つけます。
osssecret-namespace
: シークレットの名前空間。pv-name
: PVの名前。
kubectl -n <osssecret-namespace> get pod | grep <pv-name>-check
期待される出力:
<pv-name>-check-xxxxx
次のコマンドを実行して原因を特定します。
kubectl -n <osssecret-namespace> logs -f <pv-name>-check-xxxxx
期待される出力:
check ossutil endpoint: oss-<region-id>-internal.aliyuncs.com bucket: <bucket-name> path: <path> Error: oss: service returned error: StatusCode=403, ErrorCode=InvalidAccessKeyId, ErrorMessage="The OSS Access Key Id you provided does not exist in our records.", RequestId=65267325110A0C3130B7071C, Ec=0002-00000901, Bucket=<bucket-name>, Object=<path>
ossutilを使用して原因を特定
検出タスクを実行するポッドが既に削除されている場合は、ossutilを使用して検出タスクを再作成し、原因を特定します。
stat (クエリバケットとオブジェクト情報) は、OSSアクセスを検出するために使用されます。 任意のノードにossutilをインストールし、次のコマンドを実行します。
ossutil -e "<endpoint>" -i "<accessKeyID>" -k "<accessKeySecret>" stat oss://"<bucket><path>"
パラメーター | 説明 |
endpoint |
|
accessKeyID | シークレット内のAccessKey ID。 |
accessKeySecret | シークレット内のAccessKeyシークレット。 |
バケット | バケットID。 |
パス | パス。 パスはスラッシュ |
次の図のボリュームを使用する場合は、次のコマンドを実行します。
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プロセスのみが起動されます。
ソリューション
CSI 1.30.4以降では、排他モードはサポートされなくなりました。 ossfsの設定を再起動または変更する必要がある場合は、OSSボリュームが複数のポッドで共有されている場合、ossfsプロセスを再起動するにはどうすればよいですか? 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展開プロセスはトリガーされません。
解決策
ossfsプロセスを再起動するには、対応するOSSボリュームをマウントするアプリケーションポッドを再起動する必要があります。 作業は慎重に行ってください。
使用するCSIバージョンがコンテナ化されていない場合、またはOSSボリュームのマウントに排他モードが使用されている場合は、アプリケーションポッドを直接再起動できます。 コンテナー化されたCSIバージョンでは、共有モードを使用してOSSボリュームをデフォルトでマウントします。 これは、ノードで同じOSSボリュームを使用するポッドが同じossfsプロセスを共有することを意味します。
FUSEポッドを使用するアプリケーションポッドを確認します。
次のコマンドを実行して、
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>
次のコマンドを実行して、OSSボリュームを使用するすべてのポッドを確認します。
<ns>
を名前空間名に、<pvc-name>
をPVC名に置き換えます。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****
次のコマンドを実行して、
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>
アプリケーションと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でログクエリ機能が有効になっていることを確認します。 詳細については、「リアルタイムログクエリの有効化」をご参照ください。
OSSコンソールにログインします。
左側のナビゲーションウィンドウで、バケットリスト をクリックします。 [バケット] ページで、目的のバケットを見つけてクリックします。
左側のナビゲーションツリーで、
を選択します。リアルタイムクエリ タブで、クエリ構文と分析構文に基づいてクエリ文と分析文を入力し、ログフィールドを分析します。 ログがACKによって生成されたかどうかを確認するには、user_agentフィールドとclient_ipフィールドを使用します。
ACKで送信されたOSSリクエストを見つけるには、user_agentフィールドを選択します。 user_agentにossfsが含まれるリクエストは、ACKによって送信されたOSSリクエストです。
重要user-agentフィールドの値はossfsのバージョンによって異なりますが、値はすべて
aliyun-sdk-http/1.0()/ossfs
で始まります。ossfsを使用してOSSボリュームをECSインスタンスにマウントした場合、関連するログデータも記録されます。
ECSインスタンスまたはクラスターを見つけるには、client_ipフィールドを選択し、ECSインスタンスまたはクラスターのIPアドレスを見つけます。
次の図は、上記のフィールドに基づいてフィルタリングされたログデータを表示します。
照会されるフィールド
項目 | 説明 |
操作 | OSS操作のタイプ。 例: GetObjectとGetBucketStat。 詳細については、「機能別操作一覧」をご参照ください。 |
オブジェクト | OSSオブジェクトの名前 (パスまたはファイル) 。 |
request_id | リクエストを見つけるのに役立つリクエストID。 |
http_statusとエラー_コード | 返されたステータスコードまたはエラーコード。 詳細は、「HTTPステータスコード」をご参照ください。 |
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の容量値が同じであることを確認するだけで済みます。
ボリュームの実際の容量が容量設定を超えた場合、ボリュームを通常どおり使用し続けることができます。 ボリューム拡張は必要ありません。