このトピックでは、NAS ボリュームに関する一般的な問題のトラブルシューティング方法について説明します。
NAS ボリュームのマウント時間の長さ
アプリケーションテンプレートで securityContext.fsgroup パラメーターを設定すると、kubelet はマウント後にマウントディレクトリ内のすべてのファイルに対して chmod または chown 操作を実行します。ディレクトリ内のファイル数が多いほど、これらの操作に時間がかかり、マウント時間が長くなります。
以下のいずれかのソリューションをニーズに応じて選択してください。
解決策 1 (Kubernetes 1.20 以降を推奨):
fsGroupChangePolicyをOnRootMismatchに設定します。この設定により、chmodおよびchown操作は、初期マウント時かつ権限が一致しない場合にのみ実行されます。後続のマウントではこれらの操作がトリガーされないため、通常のマウント時間が復元されます。fsGroupChangePolicyパラメーターの詳細については、「Pod またはコンテナの Security Context を設定する」をご参照ください。ソリューション 2（fsGroup が不要な場合）：
securityContextセクションからfsgroupパラメーターを削除します。securityContext.fsgroupが設定されていない場合、kubelet は権限を変更しないため、マウント時間に影響しません。ソリューション 3（ファイル所有者の指定が必要な場合）： 対象ディレクトリを ECS インスタンスに手動でマウントします。
chownコマンドおよびchmodコマンドを実行して、対象の UID とmodeを設定します。その後、FlexVolume を使用して NAS ボリュームを利用します。FlexVolume を使用した NAS ボリュームの利用方法の詳細については、「静的にプロビジョニングされた NAS ボリュームを使用する」および「動的にプロビジョニングされた NAS ボリュームを使用する」をご参照ください。
タイムアウト による NAS ボリュームのマウント失敗
これは通常、ネットワーク分離の問題です。NAS のマウントポイントとクラスターが同一 VPC に存在しないため、タイムアウト エラーが発生します。マウントポイントとクラスターが同一 VPC 内にあることを確認してから、再度お試しください。
NAS ボリュームを使用する際に、chown: オプションが許可されていません エラーが発生します
「chown: option not permitted」エラーは、コンテナに NAS ボリューム上のファイル所有者を変更する権限がないことを示しています。これを修正するには、root 権限でコンテナを起動してください。
NAS ボリュームのマウント失敗
NAS PV のマウントが次のエラーで失敗します。
Unable to mount volumes for pod "dp-earnings-pod_default(906172c6-3d68-11e8-86e0-00163e00****)": timeout expired waiting for volumes to attach/mount for pod "default"/"dp-earnings-pod". list of unattached/unmounted volumes=[vol1 vol2]このエラーは、クラスターに FlexVolume プラグインがインストールされていないために発生します。これを解決するには、「FlexVolume プラグインのインストールとアップグレード」の手順に従ってプラグインをインストールしてください。
コントローラーキューのフル状態による PV 作成のブロック
ご利用の StorageClass の reclaimPolicy が Delete に設定され、かつ archiveOnDelete が false に設定されている場合、コントローラーがサブディレクトリを削除する速度よりも速くサブディレクトリが作成されると、タスクキューがいっぱいになります。これにより、新しい PV の作成が妨げられます。
archiveOnDelete を true に設定してください。PV が削除されると、コントローラーは NAS ファイルシステム内のサブディレクトリを削除せずに名前を変更するだけになります。この操作はほぼ瞬時に完了し、タスクキューがブロックされるのを防ぎます。
archiveOnDelete を true に設定すると、名前が変更されたサブディレクトリは自動的に削除されません。ファイルの削除はご自身で管理する必要があります。一般的な方法としては、ノード上でスケジュールされた削除タスクを設定するか、特定の命名パターンに従うサブディレクトリを複数の Pod で同時に削除する方法があります。