このトピックでは、ネットワークアタッチトストレージ (NAS) ボリュームに関するよくある質問 (FAQ) と一般的な問題のソリューションについて説明します。
クイックナビゲーション
カテゴリ | 問題 |
マウント | |
使用 | |
アンマウント |
マウント
マウント時のエラー：chown: Operation not permitted
現象
NAS ボリュームをマウントすると、エラーメッセージ chown: Operation not permitted が表示されます。
原因
ホスト上でコンテナーを起動するために使用されるロールに、NAS ボリュームを変更する権限がありません。
ソリューション
コンテナープロセスを起動するユーザーが root 権限を持っていない場合は、root ユーザーを使用して `chown` および `chgrp` 操作を実行します。Persistent Volume (PV) の
accessModesがReadWriteOnceの場合は、securityContext.fsGroupを使用して、Pod のボリュームアクセス権限と所有権変更ポリシーを構成することもできます。詳細については、「Pod またはコンテナーのセキュリティコンテキストの設定」をご参照ください。root ユーザーとして実行している場合でもエラーが解決しない場合は、NAS マウントポイントの権限グループを確認し、root ユーザーがファイルシステムにアクセスできることを確認してください。ユーザー権限は No_squash に設定する必要があります。詳細については、「権限グループの管理」をご参照ください。
動的にプロビジョニングされた NAS ボリュームのマウント時にコントローラーのタスクキューが一杯になる
現象
動的にプロビジョニングされた NAS ボリュームを使用する場合、サブディレクトリが削除されるよりも速く作成されると、コントローラーのタスクキューがブロックされる可能性があります。これにより、新しい PV の作成が妨げられます。
原因
この問題は、クラスターが動的にプロビジョニングされた NAS ボリュームを使用し、StorageClass の reclaimPolicy が Delete に設定され、archiveOnDelete が false に設定されている場合に発生します。
ソリューション
archiveOnDelete を true に設定します。PV が削除されると、NAS ファイルシステム上の対応するサブディレクトリは、その内容が完全に削除されるのではなく、名前が変更されます。その後のファイル削除は、ユーザーの責任で行う必要があります。たとえば、過負荷のノードのルートディレクトリにスケジュールされた削除ジョブを構成したり、複数の Pod を使用して特定のフォーマットに一致するサブディレクトリを同時に削除したりできます。
NAS ボリュームのマウント時間の増加
現象
NAS ボリュームのマウントに時間がかかります。
原因
マウントされた PV および Persistent Volume Claim (PVC) に chmod または chown 操作が再帰的に適用されると、マウント時間が増加する可能性があります。これは、次の両方の条件が満たされた場合に発生します：
PV および PVC テンプレートで
AccessModesパラメーターがReadWriteOnceに設定されている。アプリケーションテンプレートで
securityContext.fsGroupパラメーターが構成されている。
ソリューション
アプリケーションテンプレートで
securityContext.fsGroupパラメーターが構成されている場合は、securityContextブロックからfsGroupパラメーターを削除します。マウントディレクトリ内のファイルをターゲットの UID と
modeに変更するには、ターゲットディレクトリを ECS インスタンスに手動でマウントします。その後、chownおよびchmodコマンドを実行します。コマンドが実行された後、Container Storage Interface (CSI) を介して NAS ボリュームを使用します。CSI を介して NAS ボリュームを使用する方法の詳細については、「静的にプロビジョニングされた NAS ボリュームの使用」または「動的にプロビジョニングされた NAS ボリュームの使用」をご参照ください。Kubernetes クラスターのバージョン 1.20 以降では、
fsGroupChangePolicyをOnRootMismatchに設定することもできます。これにより、chmodおよびchown操作は、ボリュームが初めてマウントされるときにのみ実行されます。その後のマウントはより高速になります。fsGroupChangePolicyパラメーターの詳細については、「Pod またはコンテナーのセキュリティコンテキストを設定する」をご参照ください。
マウント時のエラー：unknown filesystem type "xxx"
現象
NAS ボリュームをマウントすると、エラーメッセージ unknown filesystem type "xxx" が表示されます。
原因
Pod がスケジュールされているノードに、必要なストレージの依存関係がインストールされていません。
ソリューション
ボリュームの構成が正しいことを確認してください。
2 つの NAS PVC のマウント時に Pod が ContainerCreating 状態でスタックする
現象
Pod が 2 つの PVC を使用して NAS ボリュームをマウントしようとすると、Pod の起動に失敗し、ContainerCreating 状態のままになります。ただし、PVC のいずれか 1 つだけを使用すると、ボリュームは正常にマウントできます。
原因
2 つの PVC に関連付けられている PV の spec.csi.volumeHandle が同じです。これにより、kubelet はマウントプロセス中に 2 つの PV を単一のボリュームとして扱います。
ソリューション
spec.csi.volumeHandle フィールドの値を PV 名と一致するように変更します。
CSI を使用して TLS で NAS ファイルシステムをマウントする方法
NAS では、TLS プロトコルを使用して、クライアントと NAS サービス間の転送中のデータを保護できます。これにより、送信中にデータが盗まれたり改ざんされたりするのを防ぎます。CSI では、Alibaba Cloud NAS クライアントを使用してボリュームをマウントし、マウントプロトコルを alinas に設定することで TLS マウントオプションを有効にできます。
NAS クライアントツールは、Stunnel リスナープロセスを TLS 暗号化プロキシとして使用します。高スループットのアプリケーションの場合、Stunnel リスナープロセスは暗号化と復号を実行するために大量の CPU リソースを消費します。極端な場合、各マウントで CPU コア全体を消費する可能性があります。詳細については、「NFS ファイルシステムの転送中の暗号化」をご参照ください。
cnfs-nas-daemon コンポーネントをインストールします。詳細については、「cnfs-nas-daemon コンポーネントの管理」をご参照ください。
[アドオン] ページで、csi-plugin コンポーネントを見つけ、
AlinasMountProxy=trueFeatureGate を有効にするように設定します。次の例を使用して、動的にプロビジョニングされた NAS ボリュームまたは静的にプロビジョニングされた NAS ボリュームをマウントします。
動的にプロビジョニングされた NAS ボリュームを使用する例
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: alicloud-nas-tls mountOptions: - nolock,tcp,noresvport - vers=3 - tls # tls マウントオプションを追加します。 parameters: volumeAs: subpath server: "0cd8b4a576-g****.cn-hangzhou.nas.aliyuncs.com:/k8s/" mountProtocol: alinas # alinas クライアントをマウントに使用することを指定します。 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.mountProtocolこのパラメーターを
alinasに設定して、Alibaba Cloud NAS クライアントを使用します。このパラメーターを空のままにすると、デフォルトで NFS プロトコルが使用されます。mountOptionstlsパラメーターを追加して 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 # PV 名と同じにする必要があります。 volumeAttributes: server: "2564f4****-ysu87.cn-shenzhen.nas.aliyuncs.com" path: "/csi" mountProtocol: alinas # alinas クライアントをマウントに使用することを指定します。 mountOptions: - nolock,tcp,noresvport - vers=3 - tls # tls マウントオプションを追加します。 --- 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.mountProtocol
このパラメーターを
alinasに設定して、Alibaba Cloud NAS クライアントを使用します。このパラメーターを空のままにすると、デフォルトで NFS プロトコルが使用されます。spec.mountOptions
tlsパラメーターを追加して TLS を有効にします。このパラメーターは、mountProtocolがalinasに設定されている場合にのみ有効です。デフォルトでは、TLS は無効になっています。
NAS でユーザーまたはグループの分離を実装する方法
異なるユーザーとグループ間のデータセキュリティを確保するために、次の手順を実行して NAS のユーザーまたはグループを分離できます。
次の YAML テンプレートを使用して、Pod 内で nobody ユーザーとしてプロセスを開始します。作成されたディレクトリの UID と GID は 65534 です。
apiVersion: apps/v1 kind: StatefulSet metadata: name: nas-sts spec: selector: matchLabels: app: nginx serviceName: "nginx" replicas: 1 template: metadata: labels: app: nginx spec: securityContext: fsGroup: 65534 # ディレクトリまたはファイルが作成されると、UID と GID は 65534 (nobody ユーザー) になります。 fsGroupChangePolicy: "OnRootMismatch" # ボリューム内のコンテンツのオーナーと権限は、ルートディレクトリのオーナーと権限がボリュームの期待される権限と異なる場合にのみ変更されます。 containers: - name: nginx image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6 securityContext: runAsUser: 65534 # コンテナー内のすべてのプロセスは、ユーザー ID 65534 (nobody ユーザー) で実行されます。 runAsGroup: 65534 # コンテナー内のすべてのプロセスは、プライマリグループ ID 65534 (nobody ユーザー) で実行されます。 allowPrivilegeEscalation: false volumeMounts: - name: nas-pvc mountPath: /data volumeClaimTemplates: - metadata: name: nas-pvc spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "alicloud-nas-subpath" resources: requests: storage: 100Giコンテナーで
topコマンドを実行して、USER が nobody であることを確認します。kubectl exec nas-sts-0 -- "top"期待される出力：
Mem: 11538180K used, 52037796K free, 5052K shrd, 253696K buff, 8865272K cached CPU: 0.1% usr 0.1% sys 0.0% nic 99.7% idle 0.0% io 0.0% irq 0.0% sirq Load average: 0.76 0.60 0.58 1/1458 54 PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND 49 0 nobody R 1328 0.0 9 0.0 top 1 0 nobody S 1316 0.0 10 0.0 sleep 3600期待される出力は、
nobodyユーザーがtopコマンドを実行していることを示しています。NAS マウントディレクトリに作成されたディレクトリとファイルが
nobodyによって所有されていることを確認します。kubectl exec nas-sts-0 -- sh -c "touch /data/test; mkdir /data/test-dir; ls -arlth /data/"期待される出力：
total 5K drwxr-xr-x 1 root root 4.0K Aug 30 10:14 .. drwxr-sr-x 2 nobody nobody 4.0K Aug 30 10:14 test-dir -rw-r--r-- 1 nobody nobody 0 Aug 30 10:14 test drwxrwsrwx 3 root nobody 4.0K Aug 30 10:14 .期待される出力は、
/dataに作成された test ファイルと test-dir ディレクトリの対応する UID と GID が nobody ユーザーに属していることを示しています。
複数のコンテナー化されたアプリケーションで同じ NAS ボリュームを使用できますか？
はい。NAS は共有ストレージを提供します。これは、単一の PVC を複数のアプリケーションで同時に使用できることを意味します。
NAS への同時書き込みの条件については、「複数のプロセスまたはクライアントが同時にログファイルにデータを書き込むときに発生する可能性のある例外を防ぐにはどうすればよいですか？」および「NFS ファイルシステムへのデータ書き込みの遅延を解決するにはどうすればよいですか？」をご参照ください。
NAS ボリュームのマウント方法の詳細については、「CNFS を使用した NAS ファイルシステムの管理 (推奨)」、「静的にプロビジョニングされた NAS ボリュームの使用」、および「動的にプロビジョニングされた NAS ボリュームの使用」をご参照ください。
ACK での NAS ボリュームのマウント失敗と「failed to do setup volume」エラー
Container Service for Kubernetes (ACK) で NAS ボリュームを使用すると、マウント操作が失敗し、failed to do setup volume エラーでタイムアウトすることがあります。この問題は、NAS の構成が正しくないことが原因である可能性があります。正しい手順については、「Container Service for Kubernetes (ACK) で NAS ボリュームをマウントする」をご参照ください。
最も一般的な原因は、VPC 構成の不一致です。StorageClass で指定されたマウントポイントアドレス (server) は、クラスターと同じ VPC 内にある必要があります。
クラスターの VPC ID を見つけます。
Container Service for Kubernetes (ACK) コンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。 [クラスター] ページで、対象のクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、[設定 > ConfigMaps] をクリックします。
[名前空間]を kube-system に設定して acs-profile を見つけてクリックし、表示されたページで
vpcId(vpc-gw87c9kdqs25al2z**** など) を見つけて記録します。
NAS コンソールで対応するマウントポイントアドレスを見つけます。
NAS コンソールにログインします。 左側のナビゲーションウィンドウで、[ファイルシステム] > [ファイルシステム] を選択します。 目的の NAS ファイルシステムの名前をクリックします。
[マウントポイント] をクリックします。[マウントポイント] セクションで、VPC ID に対応するマウントポイントアドレスを探します。
クラスターの VPC ID がマウントポイントの VPC と一致することを確認します。
一致しない場合は、設定を再構成します。詳細については、「Container Service for Kubernetes (ACK) で NAS ボリュームをマウントする」をご参照ください。
NAS ボリューム上のディレクトリの作成または変更ができない
現象
NAS ボリューム上のディレクトリを作成または変更できません。
原因
root 以外のユーザーには PV への書き込みに必要な権限がないため、ディレクトリの作成または変更が許可されていません。
ソリューション
次のいずれかの方法を使用して chmod または chown コマンドを実行し、マウントディレクトリの権限を変更できます。これにより、ディレクトリに対する操作を実行できるようになります。
root 権限を持つ Init コンテナーを起動して PV をマウントします。次に、
chmodまたはchownコマンドを実行して、マウントディレクトリの権限を変更します。fsGroupChangePolicyをOnRootMismatchに設定します。これにより、ボリュームが初めてマウントされるときにchmodまたはchownコマンドが自動的に実行されます。
読み書き操作中の NFS Stale File Handle エラー
現象
クライアントがファイルへの読み取りまたは書き込みを行う際に、NFS Stale File Handle エラーを受け取ります。
原因
NAS はデータ整合性を保証しません。たとえば、2 つのクライアントが同じ NAS ボリュームをマウントし、クライアント 1 がファイルを開いてそのファイル記述子 (fd) を取得した場合、クライアント 2 がそのファイルを削除した後にクライアント 1 がファイルへの読み取りまたは書き込みを試みると、`NFS Stale File Handle` エラーを受け取ります。
ソリューション
NAS はデータ整合性を保証しません。ビジネスシナリオに基づいてデータ整合性の問題を処理する必要があります。
アンマウント
アンマウントがタイムアウトし、Pod が Terminating 状態でスタックする
症状
マウントされた NAS ボリュームを持つ Pod を削除すると、アンマウント操作が失敗し、Pod が Terminating 状態でスタックします。
原因
この問題は、csi-plugin が /var/run を直接マウントしていることが原因です。次のコマンドを実行して、/var/run が直接マウントされているかどうかを確認できます。出力が空でない場合、ディレクトリは直接マウントされています。
kubectl get ds -n kube-system csi-plugin -ojsonpath='{.spec.template.spec.volumes[?(@.hostPath.path=="/var/run/")]}'ソリューション
次のコマンドを実行して、csi-plugin の YAML ファイルに手動でパッチを適用します。パッチが適用されると、問題は解決します。
kubectl patch -n kube-system daemonset csi-plugin -p '
spec:
template:
spec:
containers:
- name: csi-plugin
volumeMounts:
- mountPath: /host/var/run/efc
name: efc-metrics-dir
- mountPath: /host/var/run/ossfs
name: ossfs-metrics-dir
- mountPath: /host/var/run/
$patch: delete
volumes:
- name: ossfs-metrics-dir
hostPath:
path: /var/run/ossfs
type: DirectoryOrCreate
- name: efc-metrics-dir
hostPath:
path: /var/run/efc
type: DirectoryOrCreate
- name: fuse-metrics-dir
$patch: delete'