このトピックでは、Object Storage Service (OSS) ボリュームに関するよくある質問に対する回答を提供します。
OSSボリュームのマウントに失敗するのはなぜですか?
現象：
OSSボリュームのマウントに失敗しました。
原因：
使用したAccessKeyペアが無効です。
マウントするOSSバケットのエンドポイントにアクセスできません。
ノードのオペレーティングシステムはCentOS 7でもAlibaba Cloud Linux 2でもありません。
解決策：
有効なAccessKeyペアを使用します。
マウントするOSSバケットのエンドポイントにアクセスできることを確認します。
一時的な解決策: ノード内の最新バージョンのossfsを手動でダウンロードし、ポッドをtragger Object Storage Service (OSS) ボリュームに削除して再マウントします。
重要FlexVolumeポッドが再起動するたびに、ossfsを元のバージョンに戻します。 既にマウントされているサービスには影響しません。 この問題を修正するには、最初にFlexVolumeからContainer Storage Interface (CSI) にアップグレードしてから、ノードのオペレーティングシステムをアップグレードすることをお勧めします。 詳細については、「FlexVolumeからCSIへのアップグレード」をご参照ください。
ポッドを実行するクラスターがアップグレードされた後、コンテナーにマウントされているOSSボリュームのディレクトリが使用できなくなるのはなぜですか。
現象：
コンテナーにマウントされているOSSボリュームのディレクトリは、ポッドを実行するクラスターがアップグレードされると使用できなくなります。
原因：
クラスターのアップグレード後、kubeletとコンテナーネットワークが再起動され、OSSFSプロセスが再起動されます。 その結果、ホストとコンテナディレクトリ間のマッピングが無効になります。
解決策：
コンテナーを再起動するか、OSSボリュームがマウントされているポッドを再作成します。 ヘルスチェック機能を設定して、コンテナーまたはポッドの再起動を自動化できます。
OSSの使用方法の詳細については、「OSSボリュームの概要」をご参照ください。
OSSボリュームのマウントに時間がかかるのはなぜですか?
現象：
OSSボリュームのマウントには長い時間がかかります。
原因：
アプリケーションテンプレートでsecurityContext.fsgroupパラメーターが設定されている場合、ボリュームのマウント後にkubeletがchmodまたはchown操作を実行するため、時間の消費が増加します。
解決策：
アプリケーションテンプレートでsecurityContext.fsgroupパラメーターが設定されている場合、securityContextセクションのfsgroupパラメーターを削除します。
マウントされたディレクトリ内のファイルのユーザーID (UID) とモードを設定する場合は、OSSバケットをElastic Compute Service (ECS) インスタンスに手動でマウントできます。 その後、CLIを使用して
chownおよびchmod操作を実行し、FlexVolumeプラグインを使用してOSSボリュームをプロビジョニングできます。 FlexVolumeを使用してOSSボリュームをプロビジョニングする方法の詳細については、「静的にプロビジョニングされたOSSボリュームのマウント」をご参照ください。Kubernetes 1.20以降のクラスターの場合、fsGroupChangePolicyパラメーターをOnRootMismatchに設定できます。 このように、
chmodまたはchown操作は、ボリュームを使用するポッドが最初に起動されたときにのみ実行されます。 詳細については、「コンテナーのセキュリティコンテキストの設定」をご参照ください。