このトピックでは、Apsara File Storage NAS (NAS) ボリュームに関するよくある質問に対する回答を提供します。
NASボリュームをマウントするときにシステムがchown: 操作を許可されないのはなぜですか?
問題
NASファイルシステムをマウントすると、chown: 操作は許可されません。
原因
コンテナーの実行に使用されるロールには、NASファイルシステムを管理する権限がありません。
ソリューション
コンテナープロセスを起動するユーザーにはroot権限がありません。 chownおよびchgrp操作を実行するには、rootアカウントを使用する必要があります。 永続ボリューム (PV) の
accessModesがReadWriteOnceに設定されている場合、securityContext.fsGroupを使用して、ポッドのボリュームアクセス許可と所有権変更ポリシーを設定できます。 詳細については、「ポッドのボリューム権限と所有権変更ポリシーの設定」をご参照ください。ルートアカウントを使用した後も問題が解決しない場合は、NASマウントターゲットの権限グループがユーザー権限をNo Anonymity (no_squash) に設定しているかどうかを確認します。 詳細については、「権限グループの管理」をご参照ください。
動的にプロビジョニングされたnasボリュームを使用すると、alicloud-NAS-controllerのタスクキューがいっぱいになり、PVを作成できない場合はどうすればよいですか？
問題
動的にプロビジョニングされたNASボリュームを使用する場合、サブディレクトリの作成速度がサブディレクトリの削除速度よりも速い場合、alicloud-nas-controllerのタスクキューがいっぱいになり、PVを作成できない可能性があります。
原因
動的にプロビジョニングされたNASボリュームをマウントするStorageClassの設定で、reclaimPolicyパラメーターがDeleteに設定され、archiveOnDeleteパラメーターがfalseに設定されます。
ソリューション
archiveOnDeleteをtrueに設定します。 このようにして、PVが削除されると、NASファイルシステム内のマウントされたサブディレクトリの名前のみが変更されます。 サブディレクトリ内のファイルは削除されません。
これらのファイルは自分で削除する必要があります。 たとえば、ルートディレクトリ内のファイルをスケジュールごとに自動的に削除するようにノードを設定したり、複数のポッドを起動してサブディレクトリ内の特定の形式のファイルを同時に削除したりできます。
NASボリュームのマウントに時間がかかるのはなぜですか?
問題
NASボリュームのマウントには長い時間がかかります。
原因
次の条件を満たすと、ボリュームのマウント時にchmodまたはchown操作が実行され、時間の消費が増加します。
永続ボリューム (PV) および永続ボリューム要求 (PVC) テンプレートでは、AccessModesパラメーターがReadWriteOnceに設定されます。
securityContext.fsgroupパラメーターは、アプリケーションテンプレートで設定されます。
ソリューション
アプリケーションテンプレートでsecurityContext.fsgroupパラメーターが設定されている場合、securityContextセクションのfsgroupパラメーターを削除します。
マウントされたディレクトリ内のファイルのユーザーID (UID) とモードを設定する場合は、ディレクトリをElastic Compute Service (ECS) インスタンスに手動でマウントできます。 その後、CLIを介して
chownコマンドとchmodコマンドを実行し、CSIプラグインを介してNASボリュームをプロビジョニングできます。 CSIプラグインを使用してNASボリュームをマウントする方法の詳細については、「静的にプロビジョニングされたNASボリュームのマウント」または「動的にプロビジョニングされたNASボリュームのマウント」をご参照ください。上記の方法とは別に、Kubernetes 1.20以降のクラスターの場合、fsGroupChangePolicyパラメーターをOnRootMismatchに設定できます。 このように、
chmodまたはchown操作は、システムが初めてポッドを起動したときにのみ実行されます。 その結果、最初の起動時にOSSボリュームをマウントするのに時間がかかります。 最初の起動が完了した後にOSSボリュームをマウントすると、問題は発生しません。 fsGroupChangePolicyの詳細については、「ポッドまたはコンテナーのセキュリティコンテキストの設定」をご参照ください。
NASボリュームでディレクトリを作成または変更できない場合はどうすればよいですか？
問題
NASボリュームでディレクトリを作成または変更することはできません。
原因
root以外のユーザーには、PV内のディレクトリを作成または変更する権限がありません。
ソリューション
次のいずれかの方法を選択して、chmodまたはchownコマンドを実行し、マウントディレクトリのアクセス許可を変更できます。
root権限でinitコンテナを起動し、PVをマウントしてから、
chmodまたはchownコマンドを実行して、マウントディレクトリのアクセス許可を変更します。 次に、PV内のディレクトリを作成および変更できます。fsGroupChangePolicyパラメーターをOnRootMismatchに設定します。 これにより、システムが初めてポッドを起動するときに、
chmodまたはchownコマンドを実行して、マウントディレクトリのアクセス許可を変更します。 次に、PV内のディレクトリを作成および変更できます。
NASボリュームをマウントするときに、システムが不明なファイルシステムタイプ "xxx" を要求するのはなぜですか?
問題
NASボリュームをマウントすると、不明なファイルシステムタイプ "xxx" が表示されます。
原因
NASボリュームの依存関係は、アプリケーションがデプロイされているノードにはインストールされません。
ソリューション
NASボリュームが正しく設定されているかどうかを確認します。
NASボリュームについては、「CNFSを使用した共有NASボリュームの管理 (推奨) 」をご参照ください。
OSSボリュームについては、「静的にプロビジョニングされたOSSボリュームのマウント」をご参照ください。
クライアントがNASボリュームからデータを読み書きするときに、システムがNFS Stale File Handleを要求するのはなぜですか？
問題
クライアントがNASボリュームからデータを読み書きするとき、システムはNFS Stale File Handleを要求します。
原因
NASボリュームをコンテナにマウントした後、NASはデータの一貫性を保証しません。 NASボリュームが2つのクライアントにマウントされているとします。 クライアント1は、ファイルのファイル記述子 (FD) を取得するためにNASボリューム内のファイルを開きます。 クライアント2がファイルを削除すると、クライアント1はファイルを読み書きできず、システムはNFS Stale file Handleをプロンプトします。
ソリューション
ビジネスシナリオに基づいてデータ整合性の問題を解決する必要があります。
2つのPVCを使用して2つの異なるNASボリュームをマウントするポッドがContainerCreating状態のままである場合はどうすればよいですか？
問題
2つのPVCを使用してNASボリュームをマウントするポッドの起動に失敗し、ポッドはContainerCreating状態のままです。 1つのPVCのみを使用するようにポッドを構成すると、ポッドを起動できます。
原因
2つのPVCに関連付けられた2つのPVは、同じspec.csi.volumeHandle値を使用します。 その結果、kubeletは、PV実装ロジックを処理するときに2つのPVを区別できません。
ソリューション
各PVのspec.csi.volumeHandleパラメーターをPVの実際の名前に設定します。
CSIを使用して、TLSが有効になっているNASファイルシステムをマウントするにはどうすればよいですか？
NASはTLSを使用して、NASクライアントとNASサービス間のデータ伝送のセキュリティを確保し、データの盗難や改ざんを防止します。 CSIを使用すると、Alibaba CloudのNASクライアント (aliNAS) を使用してボリュームをマウントし、TLSを有効にできます。
注意事項
NASクライアントは、stunnelプロセスをTLS暗号化ラッパーとして使用します。 高スループットアプリケーションの場合、スタンネルプロセスは暗号化と復号化を実行するために大量のCPUリソースを消費します。 極端な場合、各マウント操作はコアを占有します。 詳細については、「NFSファイルシステムの転送中の暗号化」をご参照ください。
手順
NASクライアントをインストールします。
csi-pluginのConfigMapを変更して、csi-pluginを再起動します。
cat <<EOF | kubectl apply -f - apiVersion: v1 kind: ConfigMap metadata: name: csi-plugin namespace: kube-system data: cnfs-client-properties: | alinas-utils=true EOF kubectl rollout restart ds -n kube-system csi-plugin次のサンプルコードに基づいて、静的にプロビジョニングされたNASボリュームまたは動的にプロビジョニングされたNASボリュームをマウントします。
動的にプロビジョニングされたNASボリュームのマウント
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: alicloud-nas-tls mountOptions: - nolock,tcp,noresvport - vers=3 - tls # Add a TLS mount option. parameters: volumeAs: subpath server: "0cd8b4a576-g****.cn-hangzhou.nas.aliyuncs.com:/k8s/" mountProtocol: alinas # Declare to use the aliNAS client to mount the volume. provisioner: nasplugin.csi.alibabacloud.com reclaimPolicy: Retain --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: nas-tls spec: accessModes: - ReadWriteMany storageClassName: alicloud-nas-tls resources: requests: storage: 20Giパラメーター
説明
parameters.mo untProtocol
alinasクライアントを使用してボリュームをマウントするには、パラメーターをaliNASに設定します。 デフォルトでは、このパラメータは空のままで、NFSを使用してボリュームをマウントします。
mountOptions
tlsを有効にするには、TLSオプションを追加します。 mountProtocolがalinasに設定されている場合のみ、このオプションを追加します。 デフォルトでは、TLSは無効になっています。
静的にプロビジョニングされたNASボリュームのマウント
apiVersion: v1 kind: PersistentVolume metadata: name: pv-nas-tls labels: alicloud-pvname: pv-nas-tls spec: capacity: storage: 5Gi accessModes: - ReadWriteMany csi: driver: nasplugin.csi.alibabacloud.com volumeHandle: pv-nas # Enter the name of the PV. volumeAttributes: server: "2564f4****-ysu87.cn-shenzhen.nas.aliyuncs.com" path: "/csi" mountProtocol: alinas # Declare to use the aliNAS client to mount the volume. mountOptions: - nolock,tcp,noresvport - vers=3 - tls # Add a TLS mount option. --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: pvc-nas-tls spec: accessModes: - ReadWriteMany resources: requests: storage: 5Gi selector: matchLabels: alicloud-pvname: pv-nas-tlsパラメーター
説明
spec.csi.volumeAttributes.mo untProtocol
alinasクライアントを使用してボリュームをマウントするには、パラメーターをaliNASに設定します。 デフォルトでは、このパラメータは空のままで、NFSを使用してボリュームをマウントします。
spec.mo untOptions
tlsを有効にするには、TLSオプションを追加します。 mountProtocolがalinasに設定されている場合のみ、このオプションを追加します。 デフォルトでは、TLSは無効になっています。